Uploaded image for project: 'Hippo CMS'
  1. Hippo CMS
  2. CMS-10862

Improve search in users and groups

Details

    • New Feature
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • None
    • 5.2.0
    • None
    • 5
    • Tiger
    • Tiger Sprint 164, Tiger Sprint 171, Tiger Sprint 173

    Description

      The current search functionality can be described as follows:

      • Doesn’t search across all relevant database properties, e.g. ‘’Group’’
      • Search is sometimes partial and sometimes non-partial; it depends on the database property (it is inconsistent)
      • For some database properties search is case-sensitive, for others it is not, e.g. it is case-sensitive for ‘’Username’’ but not for ‘’First name’’
      • There is no way to return to the original list (non search-results list) without clearing the search field and executing a search; this is not user friendly

       

      CHANGES REQUIRED

      The new search functionality uses the following mechanisms across 'users', 'groups' and 'edit group members':

      • it is not case sensitive (across any property included in the search)
      • it does not require an exact match; partial returns results where available (across any property included in the search)
      • it searches across all characters: numbers, letters and otherwise (e.g. @) (for all properties included in the search)
      • within ‘’Users’’ it searches across the following 2 additional properties:
        • group
        • type

      The search bar utilises the following interaction behaviour:

      • Pressing enter or clicking on the magnifying glass executes the search; the magnifying glass changes to an ‘’X’’, focus on the field is removed and the list updates with correct results
      • Placing focus on the field clears the placeholder text, or the previously-entered search term, and the magnifying glass is displayed
      • A user can exit and clear the search by doing any of the following:
        • Clicking the ‘’X’’ (magnifying glass, placeholder text and normal list are displayed)

      Attachments

        Activity

          mmetternich the search logic/backend behaviour in this ticket is to be implemented BUT the interaction design of the bar itself needs to be disregarded; please speak with cdekort to get the details- thanks!

          kmoore Kathryn Moore (Inactive) added a comment - mmetternich the search logic/backend behaviour in this ticket is to be implemented BUT the interaction design of the bar itself needs to be disregarded; please speak with cdekort to get the details- thanks!

          Pair reviewed with abogaart.

          bleunis Bert Leunis (Inactive) added a comment - Pair reviewed with abogaart .

          Branch merged with master.

          The choosen solution: implement the same logic for handling of search terms as is done in the content search (in the documents and images sections). This aligns the search very well accross the application.

          One requirement could not be implemented: there is no filtering on group in the user search. Although the group name is shown in the users list, the aspect of group membership is not maintained in the User nodes, but in the group nodes. If you want to work with the members of a certain group, you must access the group information.

          bleunis Bert Leunis (Inactive) added a comment - Branch merged with master. The choosen solution: implement the same logic for handling of search terms as is done in the content search (in the documents and images sections). This aligns the search very well accross the application. One requirement could not be implemented: there is no filtering on group in the user search. Although the group name is shown in the users list, the aspect of group membership is not maintained in the User nodes, but in the group nodes. If you want to work with the members of a certain group, you must access the group information.
          kmoore Kathryn Moore (Inactive) added a comment - - edited

          Tested the solution on master; from what I can tell, from the original acceptance criteria, the following was not completed:

          • cannot search on email address, e.g. searching on @ returns nothing
          • cannot search on group or type

          Despite this I am happy for the ticket to be closed; the solution implemented is a nice enough improvement

          If my understanding of what was not completed (above) is incorrect please just let me know

          Thank you!

          kmoore Kathryn Moore (Inactive) added a comment - - edited Tested the solution on master; from what I can tell, from the original acceptance criteria, the following was not completed: cannot search on email address, e.g. searching on @ returns nothing cannot search on group or type Despite this I am happy for the ticket to be closed; the solution implemented is a nice enough improvement If my understanding of what was not completed (above) is incorrect please just let me know Thank you!

          kmoore: about the the group or type info: as mentioned above, the group information is not part of the user nodes, and the applied search technique (the same as used in the Content perspective now) only searches for properties on nodes itself, not on information in "linked" nodes such as the group nodes.

          The type of user (Repository/External) is determined by primary node type (hipposys:externaluser or hipposys:user). So again this is not a property on the node. If we want users to give them some option here, I'd suggest that we could apply it as filter on the user list. The column heading could be come a dropdown with options such as "Type: all", "Repository" and "External". If you want that, please create a new issue for it.

          bleunis Bert Leunis (Inactive) added a comment - kmoore : about the the group or type info: as mentioned above, the group information is not part of the user nodes, and the applied search technique (the same as used in the Content perspective now) only searches for properties on nodes itself, not on information in "linked" nodes such as the group nodes. The type of user (Repository/External) is determined by primary node type (hipposys:externaluser or hipposys:user). So again this is not a property on the node. If we want users to give them some option here, I'd suggest that we could apply it as filter on the user list. The column heading could be come a dropdown with options such as "Type: all", "Repository" and "External". If you want that, please create a new issue for it.

          Forgot to mention: there is no prepending of wildcards on search terms. So with "@" you will not find "john@..." nor "mary@...". A search for "john@" will get you all users whose mail address starts with that string.

          bleunis Bert Leunis (Inactive) added a comment - Forgot to mention: there is no prepending of wildcards on search terms. So with "@" you will not find "john@..." nor "mary@...". A search for "john@" will get you all users whose mail address starts with that string.

          Test ok

          asolod Andrey Solod (Inactive) added a comment - Test ok

          People

            Unassigned Unassigned
            mmetternich Michael Metternich
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: