Grouper Developers Forum

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

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

Gary

--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 <http://portal.bris.ac.uk/GroupsManager/doc/search.html>?
>
> 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.

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

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 :)
> Gary
>
> ----------------------
> GW Brown, Information Systems and Computing



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