Grouper Developers Forum

[Shilen Patel <>]

Hi Chris,

I had assumed that the values in the sort and search columns would be 
attributes, but it would be flexible since you can make virtual 
attributes in the sources.xml file.  Is there a reason not to make them 
all attributes?  Do they need to be marked as "internal" somehow so they 
don't get seen anywhere else?  So this would work for g:gsa for instance:

<init-param>
<param-name>subjectVirtualAttribute_0_attr0</param-name>
<param-value>${subject.getAttributeValue('name')},${subject.getAttributeValue('id')},${subject.getAttributeValue('displayName')},${subject.getAttributeValue('description')}</param-value>
</init-param>
<init-param>
<param-name>searchAttribute0</param-name>
<param-value>attr0</param-value>
</init-param>

That way, each of the search columns (for both people and groups) can be 
either a single attribute or multiple attributes delimited by 
something.  For your case with a single search box that maintains 
security, there could be an API method with a boolean 
useDefaultSearchCol and a config option that lists the order.

search.defaultIndexOrder=2,1,0

So if you have access to the first one (searchString2), then that would 
be used.  Otherwise, try the next and so forth.  searchString0 would be 
the most public.

Maybe a config option for default sorting as well..

sort.defaultIndex=0

And yes, sorting using a sort column should exclude results that have a 
null value for that column.

Thanks!

-- Shilen


On 3/24/11 11:02 PM, Chris Hyzer wrote:
> I wonder if there should be a method in the Source interface which customizes 
> things.  For example, for groups, it isn't really configured in the 
> sources.xml which attributes there are, and for the search string, maybe 
> someone wants in one col: group.name, group.id, group.displayName, 
> group.description.  for the jdbc2 source, there is no attribute for 
> lowerSearchCol, but there is a column for it, maybe it can be used somehow 
> without being a subject attribute with some Java magic in the Source class.
>
> Also, I would think the first sort/search slot should have something for 
> every source as a requirement, so when you do a normal search and sort where 
> the user didn't select a special sort, the results will be sorted.  i.e. for 
> groups maybe ththe sort should be displayExtension or displayName.  Also the 
> first slot should be public (note groups are also filtered for view 
> privileges somewhere along the line).
>
> In the case you outline, if the default sort is on the screen, and someone 
> clicks to sort by last name, would group source members not show up since 
> they do not have a sort value, or would they be last and unsorted a the end 
> of the list?  I would think we would want them not to show up, right?
>
> Finally, for the search col, do we have multiple columns for security or for ease of 
> search.  As I mentioned on the call, I pictured it as being for security.  If you 
> look at the simple membership update screen (attached), there is a find member of 
> group combobox.  This is not a complex form where you search for attrX=val1&& 
>  attrY=val2...  Anyways, some admin users could search on everything about a person.  
> People affiliated in a certain way at Penn could be other attributes (i.e. in the 
> online directory is the name of a student displayed in the public view of the 
> directory the same way as it is to someone authenticated with the university).  Then 
> there is the public view which has a different list of attributes to search on.  Just 
> trying to keep the configuration, the UI, and usability simple here... :)
>
> Thanks,
> chris
>
>
>
> -----Original Message-----
> From: 
>
>  
> [mailto:]
>  On Behalf Of Shilen Patel
> Sent: Thursday, March 24, 2011 4:47 PM
> To: Grouper Dev
> Subject: [grouper-dev] search and sort columns on member table
>
> To follow up on an action item from the last call and continue the
> discussion on search/sort strings, here's a wiki page.
>
> https://spaces.internet2.edu/display/Grouper/Member+search+and+sort+columns
>
> Feel free to make edits or add comments.  Let me know if there's a use
> case that will not work with this design.
>
> Thanks!
>
> -- Shilen
>