Grouper Developers Forum

[Chris Hyzer <>]

Ok, let me argue with myself... so as for one per source, I don't think that 
will work, since we want to do one query and sort by sortColumn.  Lets say 
you have three views of your data:

1. public view
2. active affiliate view
3. administrative view

For groups, I would think the sort and search col would be the same for all 
three.  Originally I had thought the g:gsa source would only have one sort 
and search col, but I think if we want to do a search in one query, all three 
sort and search cols in g:gsa would be populated with the same data.  Of 
course for your person source the three cols could be the same or different 
depending on privacy settings and/or the individual's preferences.

However, I still think the user choosing the sort col or search col is a 
little complex for phase 1, what do other people think?

Thanks,
Chris

-----Original Message-----
From: Chris Hyzer 
Sent: Sunday, March 13, 2011 6:13 PM
To: 'Shilen Patel'; 

Subject: RE: additional columns on member table

Well, just remember it will a drop down per source, sounds like a kind of 
confusing UI.  If there is a hierarchy of privacy where the more private has 
the more info, then I think it would be rare that you would want to bump down 
to the less private = less information, right?  :)  (hopeful suggestion to 
simplify things?)

Thanks,
Chris

-----Original Message-----
From: Shilen Patel 
[mailto:]
 
Sent: Sunday, March 13, 2011 12:48 PM
To: Chris Hyzer; 

Subject: RE: additional columns on member table

Restricting based on groups sounds good to me.  Though I wonder if we should 
allow users to sort / search using multiple attributes.  For instance, the UI 
can have two drop down lists where the user can select what to sort and 
search on.

Then maybe have config options for the groups (default to wheel only).

jdbc.sortCol0.allowOnlyGroup = stem:all_employees
jdbc.sortCol1.allowOnlyGroup = stem:all_employees
jdbc.sortCol2.allowOnlyGroup = stem:all_employees
...

jdbc.searchCol0.allowOnlyGroup = stem:all_employees
jdbc.searchCol1.allowOnlyGroup = stem:all_employees
jdbc.searchCol2.allowOnlyGroup = stem:all_employees
...

Thanks!

-- Shilen

________________________________________
From: 

 
[]
 On Behalf Of Chris Hyzer 
[]
Sent: Saturday, March 12, 2011 10:57 PM
To: 

Subject: [grouper-dev] additional columns on member table

Just curious, Shilen / Jim, or anyone else, have we established how will 
these be used.

Ie. there are multiple sort cols, and multiple search cols.  5 of each.

When a user is using the UI, how do we know which one to use for each source? 
 i.e. do we check to see if the user is in a certain group, and if so, then 
use sortCol0/searchCol0.  If not, then if they are in a certain other group, 
then use sortCol1/searchCol1.  And if not, then the default is 
sortCol2/searchCol2 (the last one, most public one).  So basically each 
source will have N options, and N-1 ordered groups to check to see which one 
to use.

Just curious, do we have a wiki page yet?

Thoughts?
Thanks,
Chris