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 09:32:44 +0100

We didn't get beyond search screens on the call so we will discuss the remaining items offline on the list - I'll give my thoughts below as a starter


--On 19 April 2005 14:10 +0100 "GW Brown, Information Systems and Computing" <> wrote:

As we move towards a 0.6 release I think we could usefully discuss UI
features which are not currently present, or may change, in order to give
ourselves a fixed target.

1) Simple search / advanced search - what should be searched in Simple
search - in my workaround I simply search displayExtension with %query% -
possibly scoped to results below a particular stem.
We agreed that the simple group search would search name and displayName, possibly scoped from a stem. We may or may not allow boolean terms at the moment depending on how easy or difficult that is to include in the API.

The simple person search is down to the implementation of the subject interface - the UI will pass a string and it is down to the implementation what it chooses to do with the query term. That said, the default subject implementation that ships with Grouper must have a defined person search.

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

A while ago I came up with a document on searching but I don't think it
was ever really discussed - would the advanced search forms work as
represented here <>?

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.

Can you assign a group multiple types from the UI?
The Grouper schema allows a group to have multiple types. This would allow me to define types defining small sets of attributes for re-use e.g.

Group type Attributes
academic faculty_code
department department_code
teaching programme_code, unit_code
research funding_code,research_code
tutor tutor_id

From a UI point of view this would be very error prone - the more types you want to combine the more chance you'll not get the selection exactly right.

An alternative is to define more specific group types
Group type Attributes
academic teaching faculty_code,department_code,programme_code,unit_code
academic research faculty_code,department_code,funding_code,research_code

I don't really like this as maintaining group type defs becomes more laborious - but it is workable.

Ideally, the UI ought not to be the determining factor. I would suggest we allow sites to configure which types actually appear in the UI and whether it is possible to choose 1 or more of them.

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.

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

4) Currently if we list a group membership (or set of subjects with a
privilege) the name of the subject is a link to a privilege assignment
screen. Should we also have a link to show a 'subject/group' summary page.
Probably - with the same caveats as above.

5) Are we missing anything else that ought to be in the 0.6 release?

There are some areas of workflow I may try and tidy up - to reduce
unnecessary clicks, but 0.6 will largely be what the current demo is +
what we agree about the above - so speak up now ...
I'm not really looking for extra things at the moment :)


GW Brown, Information Systems and Computing

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page