COmanage Developers List

[Arlen Johnson <>]

I'm working through some of the search tickets, which leads to a couple of questions:


Search vs. Filter (small enhancements):

The search boxes on co_people and org_identities are truly filters, no?

I am updating these forms to maintain their form values (and to remain visible on large screens).   This helps make it clear what filters are being applied.  I will also add a "clear all" link to reset the form -- all as part of improving the search experience for the various listings.

The distinction between "search" and "filter" is a small one, but I believe it clarifies how these forms behave.  If you agree, I'm going to change the "Search" button text to "Filter".


Filtering for Groups (new feature):

There is a desire to do some searching (perhaps filtering, as above) across groups.  Do we want to add a sidebar similar to co_people for group searches?  Is the goal to search for groups themselves, groups containing specific people, or both?

Note: in my testing over the past few days, I noted that "Manage Group Memberships" (/registry/co_group_members/select/...) throws a fatal error:
[Tue Jul 07 12:08:26.288932 2015] [:error] [pid 7583] [client 192.168.1.9:56313] PHP Fatal error:  Call to a member function enabled() on a non-object in /home/arlen/devRoot/comanage-registry/app/Model/Behavior/ChangelogBehavior.php on line 198, referer: http://locallinux.dogenmediadev.com/registry/co_groups/edit/13/co:1



Simple / Advanced search (new feature):

I agree with Benn that these two tickets are really in reference to the same thing:
https://bugs.internet2.edu/jira/browse/CO-209 - Simple search
https://bugs.internet2.edu/jira/browse/CO-820 - Advanced search

This begins with a permanently displayed box to initiate a search - so the question is (as Benn notes in CO-209) what should be searched?

Is the goal here is to have a box that searches across different kinds of entities (e.g. groups and people) or just people?  I don't think the results for this search can land on co_people; pretty certain we'll have to have a search results page.  Groups will lead to group pages, co people to a canvas, and org identities to an org id.  Wrt groups, the question above also holds: if searching for a person, do we return groups that contain that person?

The advanced search, I'm guessing, would exist only on the search results page and allow one to apply sub-filters to the original query much as the co_people and org_identity boxes do.

The end result of a simple search is to get a user (particularly an administrative user) quickly to the entity they need to act on with as little as one search + one click (although one must pick one's CO first, so that's click+search+click).  At the moment, we have click (co) + click (my population) + click(n) (browse or filter) + click.  At worst we save one click.  At best we save several.

Arlen