Grouper Developers Forum

[Tom Barton <>]

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
> > attributes?
>
> 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

Agreed.

> > 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?
>
> Probably.
>
> 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.

Tom