Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] UI features to discuss at tomorrow's conference call

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] UI features to discuss at tomorrow's conference call

Chronological Thread 
  • From: Tom Barton <>
  • To: "GW Brown, Information Systems and Computing" <>
  • Cc:
  • Subject: Re: [grouper-dev] UI features to discuss at tomorrow's conference call
  • Date: Thu, 21 Apr 2005 07:18:01 -0500

GW Brown, Information Systems and Computing wrote:
An advanced search link could reload the page with a new search form - or
could load a dedicated search page.

We will not include an advanced search in 0.6

Did we leave open a caveat? That if your current group search, the one with the checkboxes for all of a base group's fields, can be carried forward and displayed as an advanced group search without any additional hassle on your end, then it would be worthwhile to do so. We might get some feedback to better inform what post-v0.6 simple and advanced search capabilities should be like.

2) How much support will the UI have for custom group types and their

Single value attributes are relatively straightforward - we would simply iterate over the custom attribute names and provide a text input box. I would expect any implementing site to heavily customize attribute entry screens through the use of dynamically selected custom templates, so I don't intend to do anything fancy.

For list values the functionality is similar to that of managing membership - we simply go with a named list rather than the default. From that point of view it would be most straightforward to provide additional checkboxes for the custom lists alongside the one for members (and other privileges). This might prove confusing or not match expected workflow, however I would suggest we use this approach for 0.6 and see what feedback we get.

I think it's fine to place checkboxes for the 'members' and any other site-defined lists alongside each other as you describe. And I'll not make too much of a fuss, for 0.6, with putting privilege checkboxes alongside those. But, I am concerned that we not present privileges as further list memberships. I really do want grouper's privilege management to be abstracted and, ultimately (ie, probably around v0.8) subjects' privileges within grouper actually capable of being managed outside of grouper.

Can you change type / add a type to an existing group?

I would suggest we don't do this in 0.6


3) Given a subject (of any type) display groups it is a member of (for a
group we can add this to the Group Summary page)

In principle this is straightforward to do. The only issue is navigation / usability. A user could start exploring any number of groups - may be even modifying those groups in the middle of another task. This would make it tricky for the UI code to keep track of what is going on e.g. I currently store the group / stem id that you want to assign privileges to in the session. If in the middle of finding members for group A, I come across group B, explore its membership and then decide to add more members to group B, I would lose track of group A.

For 0.6 I would suggest that if we are assigning membership / privileges for a group, that we limit the ability to modify other groups we come across.

If we take this approach, will it be clear to a user when they can and when they cannot modify a group that's in front of them?

The other potentially simple approach is to replace the "current" group stored in the session with whatever group has been clicked-into or "opened" in this fashion. That would mean leaving the previous task. Is that as simple as updating the group stored with the session, or are there other things that would need to be cleaned up? And is that amount of cleanup work greater or less than whatever you'll need to do to limit ability to modify other groups the user comes across?

- do we need a subject

summary page similar to the Group summary page?


As this is 'new' work should we leave it until after 0.6?

Yes. Are you already keeping a list of future UI enhancements? I'd like us to keep a list of UI enhancements and periodically discuss how they should be slotted into our anticipated release schedule, as we've been doing for the API.


Archive powered by MHonArc 2.6.16.

Top of Page