Grouper Developers Forum

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

Hi James,

Comments below.

Gary

--On 30 August 2007 12:35 -0400 "Cramton, James" <> 
wrote:

> Our user base is limited to about half a dozen instructional technology
> consultants, so the UI is in limited release for this term.
>
>
> What we've seen now that we're starting to get some real data is that
> any future interface design for MACE Grouper needs to take common use
> cases, configurability, and ACLs very seriously. For example, we
> disabled the GrouperAll default permission for policy reasons. So this
> is what users tend to see on the My Memberships page when they log into
> MACE grouper:
>
> []
> []
> []
> []
> []
> []
> [COURSE:TEST:0001:2007-Fall:S01: All ]
> [COURSE:TEST:0001:2007-Fall:S01: Learner ]
> [COURSE:TEST:0001:2007-Fall:S01: Student ]
> [SERVICE:MYCONNECTION]
>
> We have not allowed users to list the group name in the provisioned
> groups to which they belong, but the UI presents them as empty strings,
> rather than hiding them. For now, we're just having our course
> administrators ignore My Memberships, but in time, we want students to
> be able to review their memberships, and this kind of display won't work
> for that purpose. Maybe there are ACL settings we can use to get these
> to display better, but we're afraid of the overhead cost of applying
> read ACLs to a lot of users and groups.
The UI separates the 'fetching' of objects to display from the 'rendering' 
of objects. MyMembership retrieves any group where the user is a member and 
for which the user has VIEW privilege. The list of groups is handed off to 
the rendering code (the View in MVC). At this point it is too late to start 
adding additional logic as to whether a group should be in that list.

Currently, creating a subclass of MyMembershipsRepositoryBrowser, 
overriding 'isValidChild' to take account of your business logic, and 
updating media.properties to refer to your implementation, would let you 
check attribute values before deciding to 'keep' a group, however, it looks 
like VIEW privilege should simply be removed for the subjects in question.

The UI allows a lot of flexibility in how groups are displayed. At the 
point where the Strut's action exercises the Grouper API to retrieve 
results it isn't practical to generically determine if a Group will render 
in a meaningful way.

> We continue to find ways to
> improve the display while maintaining the security model we have. An
> additional concern is that once we introduce both course groups and
> community, department, and ad-hoc groups, students may belong to 40 or
> 50 groups. This presents some real challenges in the UI.
Would you elaborate? Does this go beyond the problem of 'empty' groups.
> We're also getting feedback that without membership in the wheel group,
> our course administrators are only able to remove users from a group by
> removing the Member privilege, which is not very intuitive.
This should not be dependant on Wheel group membership. If a user is 
looking at a list of direct memberships and they have update/admin 
privilege for the group, there should be a checkbox by each member and 
buttons to remove selected / all members. If you show indirect memberships 
you don't get the checkboxes / buttons because you can't directly remove an 
indirect membership.

> Also, there
> are several dead ends in the UI that are confusing our users by
> preventing them from easily finding their way back to the group they
> were using.
I'm not entirely surprised by this, but having a specific sequence of steps 
where things go wrong would be a big help. Do you think a drop down list of 
'Recent' groups would be useful?
> The new import/export functionality will need some work
> before it's flexible enough to be used by our end users.
Again, specifics would be helpful.
> I  know there
> is talk of a project to review the UI requirements. Where does that
> stand these days?
Michael Gettes is coordinating this. I think we are probably a few weeks 
off getting feedback.
> Over the next week, I will be documenting the issues we're having in
> JIRA, complete with screen shots and analysis.
I look forward to seeing them.



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