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: "GW Brown, Information Systems and Computing" <>
  • To:
  • Subject: Re: [grouper-dev] UI features to discuss at tomorrow's conference call
  • Date: Thu, 21 Apr 2005 14:01:30 +0100

--On 21 April 2005 07:18 -0500 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.
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

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


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

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?


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

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.


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page