Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 21 April 2005 07:18 -0500 Tom Barton 
<>
 wrote:

> 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.
I can aim to do that. I wasn't quite sure what we had agreed on advanced 
search - so I thought I'd provoke a response...
> > > 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.
We can probably make it more explicit in the UI that membership lists are 
distinct from privileges - I think it is convenient to be able to assign 
both together, but they could be separated in the future if it proves 
confusing.
> > > 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?
We would remove the relevant controls from the UI. We would also indicate 
the 'primary' group in a message at the top of the page
> 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?
It would be straightforward - but potentially frustrating if simply 
clicking on a Group link out of curiosity caused you to abandon the task 
you started out doing.
> 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?
There probably isn't much in it, but from a usability point of view I would 
prefer to hide the 'modify' controls, but offer a 'Cancel and start working 
here' option. That way the user shouldn't be surprised.
> > - 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.
Does that apply to groups as well as subjects?

> 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.
Not at the moment - but I will from now on.
> Tom



----------------------
GW Brown, Information Systems and Computing