Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-7980

I can use OR queries to search for tasks in Tasklist

    Details

    • Type: Feature Request
    • Status: Closed
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.8.0, 7.8.0-alpha2
    • Component/s: tasklist
    • Labels:
      None

      Description

      Extend widget-search by integrating OR queries.
      An user interface mock for a possible solution can be found attached:

        Issue Links

          Activity

          Hide
          sebastian.stamm Sebastian Stamm added a comment -

          I like the UI with the switch above the search pills

          Review Hints (Usability):

          • Right now it is confusing for the user if he enters multiple search pills with the same criterium and the ANY modifier. E.g. Task Name is A or Task Name is B. In that case, only the last criterium is used. We should somehow make clear that this is not supported, ideally by preventing the user to create a second search pill with the same criterium. Is there already a ticket for that?
          • The Cockpit Process Instance Search looks broken right now. I don't know whether this is because of the changes for this ticket or something unrelated. We should fix it or create tickets for it.
            • Problem 1: The controls for the search overflow the box and are outside the input field.
            • Problem 2: When performing a search that does not return any results, the search result number disappears instead of showing 0.

          Review Hints (Code):

          • Are we expecting more match types than any and all? If not, we can change the datatype to boolean. That would make some operations like switching the type easier.
          • The isMatchTypeActive function will not work correctly if there are multiple search widgets on the same page. The jQuery selector will only look at the first occurence of the element and return the attributes of that one. We should use the element argument instead.
          • The Code to read the queryMatchType from the location is duplicated in the search widget. We could have this as a re-usable function
          • Could we use the original variable instead of having the deeply nested structure here?
          • The translations for the match types should be done in commons-ui instead of the tasklist. Otherwise translations may be missing when we use the search widget with the OR functionality in Cockpit in the future.
          Show
          sebastian.stamm Sebastian Stamm added a comment - I like the UI with the switch above the search pills Review Hints (Usability): Right now it is confusing for the user if he enters multiple search pills with the same criterium and the ANY modifier. E.g. Task Name is A or Task Name is B. In that case, only the last criterium is used. We should somehow make clear that this is not supported, ideally by preventing the user to create a second search pill with the same criterium. Is there already a ticket for that? The Cockpit Process Instance Search looks broken right now. I don't know whether this is because of the changes for this ticket or something unrelated. We should fix it or create tickets for it. Problem 1: The controls for the search overflow the box and are outside the input field. Problem 2: When performing a search that does not return any results, the search result number disappears instead of showing 0. Review Hints (Code): Are we expecting more match types than any and all? If not, we can change the datatype to boolean. That would make some operations like switching the type easier. The isMatchTypeActive function will not work correctly if there are multiple search widgets on the same page. The jQuery selector will only look at the first occurence of the element and return the attributes of that one. We should use the element argument instead. The Code to read the queryMatchType from the location is duplicated in the search widget. We could have this as a re-usable function Could we use the original variable instead of having the deeply nested structure here ? The translations for the match types should be done in commons-ui instead of the tasklist. Otherwise translations may be missing when we use the search widget with the OR functionality in Cockpit in the future.
          Hide
          sebastian.stamm Sebastian Stamm added a comment -

          Review Hints:

          • The variable name matchType is not very explanatory, as it now is true and false. A better name for it would be matchAny
          • The variable name switchMatchType is not very explanatory, as it suggests that if it is false, the matchType is not switched. Instead, it sets the matchType to whatever value is provided. A better name for it would be newMatchType
          • instead of checking the argument length, I would check if the argument is not undefined.
          • The functionality does not work anymore. In tasklist, when I create a search for ANY: Assignee like jonny1, Name like task, I get only one task. It appears that it uses the ALL semantic.

          Out of scope for this ticket:

          • Comparison in Javascript should always be done type-safely with === or !==, otherwise some very obscure type coercion happens. Since we don't do it consistently in the webapps, it's nothing that needs to be done for this issue. I created CAM-8053 to fix it and add a rule to the linter.
          • I like that you added the locales functionality for cockpit. We should also do that for Admin. Then we can remove the defaultTranslation utility in commons-ui. I created CAM-8054 for that.
          Show
          sebastian.stamm Sebastian Stamm added a comment - Review Hints: The variable name matchType is not very explanatory, as it now is true and false. A better name for it would be matchAny The variable name switchMatchType is not very explanatory, as it suggests that if it is false, the matchType is not switched. Instead, it sets the matchType to whatever value is provided. A better name for it would be newMatchType instead of checking the argument length , I would check if the argument is not undefined. The functionality does not work anymore. In tasklist, when I create a search for ANY: Assignee like jonny1, Name like task, I get only one task. It appears that it uses the ALL semantic. Out of scope for this ticket: Comparison in Javascript should always be done type-safely with === or !== , otherwise some very obscure type coercion happens . Since we don't do it consistently in the webapps, it's nothing that needs to be done for this issue. I created CAM-8053 to fix it and add a rule to the linter. I like that you added the locales functionality for cockpit. We should also do that for Admin. Then we can remove the defaultTranslation utility in commons-ui. I created CAM-8054 for that.
          Hide
          sebastian.stamm Sebastian Stamm added a comment -

          Another note:

          Show
          sebastian.stamm Sebastian Stamm added a comment - Another note: The Gruntfile needs to be adjusted, that it always does the localescompile task for the auto-build. Right now it only works for tasklist or when no specific webapp is configured: https://github.com/camunda/camunda-bpm-webapp/blob/master/Gruntfile.js#L211-L213

            People

            • Assignee:
              svetlana.dorokhova Svetlana Dorokhova
              Reporter:
              tassilo.weidner Tassilo Weidner
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: