Grouper Developers Forum

[Chris Hyzer <>]

> This can work - the UI has a notion of paging in some areas - but should
> still only kick in when we are over the configured limit for sorting. I
> look forward to having sorting through the API in 1.5, but sorting is
> useful in most cases so we shouldn't lose it in 1.4.

Agreed.  If the display limit is 200, and the sort limit is 50, the easiest 
thing is probably just to get the first page of 200.  Then if less than 200, 
sort it, and show 50.  If greater than 200, just show 50.  Alternatively, we 
can get the full count, and based on that either get up to 200 and sort, or 
just 50.  They are probably the same performance, so whatever is easiest to 
code in 1.4


> 
> There is an issue with displaying membership lists which include effective
> memberships. The UI processes the list of memberships so it can figure out
> how many 'routes' for a membership there are -
> see<https://bugs.internet2.edu/jira/browse/GRP-55>

No problem.  I think once we get the members, we can get a list of counts for 
them in one, or we can get all memberships for only the 50 members we need in 
one query.  We can use an "in" clause in 1 query, will be easy and good 
performance.  Again, if you are already working with memberships, and that is 
easiest for 1.4, would be fine for performance.

> 
> Group.getAdmins etc could also be paged - in case anyone adds privs to a
> large group rather than GrouperAll

Sure.  And we can do the AccessAdapter thing where the implementor doesn't 
have to implement paging, but if they do, it would be better...  again, in 
1.5 if we put more info in the members table, it will be sorted.  In 1.4, it 
will be seemingly unordered (e.g. by subjectId)


> Depending on the browse mode the UI does different things:
> 
> MyMemberships: only groups you are a member of which you can VIEW
> Join groups:   only groups where you have OPTIN
> Manage groups: only groups where you have UPDATE or ADMIN
> Explore:       only groups where you have at least VIEW privilege
> 
> so you would have to join on grouper_fields - or get the ids for the fields
> and do an 'in' clause - does Hibernate have a way of passing a collection
> for that or do you have to build dynamic SQL - or have separate queries?

We can easily handle this is a well-coded way.  I actually picture a generic 
method that uses regex where you pass it an HQL, and the security you want on 
it (granted, this is the AccessAdapter doing this), and returns the HQL of 
the secured query.  It would just add some tables to the from clause, and 
some constraints on the where clause.  And it can do "in" to pick and choose 
the privileges.  Then that generic method would be used by a bunch of default 
implementations we need (e.g. like the ones above) so it is easy to do easy 
things.  Or it could be in the query options.  E.g. to get all groups of a 
member in a certain stem, paged, sorted (in 1.5+), and with only two 
privileges UPDATE and ADMIN:

List<Group> groups = member.getGroupsFromParentStem(stem, 
  new QueryOptions().paging(QueryPaging(1,3,true))
  .sorting(QuerySort.asc("name"))
  .groupSecurity(GrouperUtil.toSet(AccessPrivilege.UPDATE, 
AccessPrivilege.ADMIN));

This would under the covers use the AccessAdapter in a smart and generic way.


> >  ...composite stuff...
> Sounds reasonable.


Good

> (from tom)
> Assuming that users don't typically want to look into the reasons why an 
> effective membership is there, can we optimize 
> things so that that data is retrieved only when the user indicates they 
> want to know why?

Again, for 1.4 I think the least changes the better especially when I think 
we can easily do this efficiently (see above).  But if Gary wants to 
implement this suggestion, it sounds like a good idea.


> If we are paging I still think we need methods to return the membership 
> count so we can show text such as 'Showing 51-98 
> of 98 items ', otherwise a user has no idea how many pages there might be.

My HibernateSession paging API exposes all this information.  I have a paging 
custom tag I could put into Grouper which has a readonly mode and a button 
mode (both are shown in the attached image, one on top of the other... page 7 
is being displayed).  If Gary wants to setup the action(s) [if the paging 
bean is in session, I believe I just need to pass in the page number and 
action from custom tag, and it will work] I can make the custom tag work.  
Gary, is that something you want for 1.4 or 1.5?

Thanks!
Chris

Attachment: paging.gif
Description: paging.gif