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

I get feedback when assigning a task to a non-existing user in tasklist

    Details

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

      Description

      In the detail view of Tasklist, changing the assignee should only be possible under certain circumpstances.

      AT:

      • There is a visual indicator if a user that is referenced can not be assigned by the user.
      • It should not be possible to reference a nonexisting/nonassignable user

        Issue Links

          Activity

          Hide
          valentin.vago Valentin Vago added a comment -

          Daniel Meyer I think your input/feedback/opinion on that issue would be valuable.

          Show
          valentin.vago Valentin Vago added a comment - Daniel Meyer I think your input/feedback/opinion on that issue would be valuable.
          Hide
          valentin.vago Valentin Vago added a comment -

          IMVHO, in order to make something "semanticaly clean" the "task/

          {id}/assignee" should support the OPTIONS method
          https://docs.camunda.org/manual/latest/reference/rest/task/post-assignee/
          More precisely, OPTIONS task/{id}

          /assignee?userId=mary (sent on behalf of any other user) should return an HTTP code (either 202/4 or 403/4)

          Thorben Lindhauer Daniel Meyer any thoughts?

          Show
          valentin.vago Valentin Vago added a comment - IMVHO, in order to make something "semanticaly clean" the "task/ {id}/assignee" should support the OPTIONS method https://docs.camunda.org/manual/latest/reference/rest/task/post-assignee/ More precisely, OPTIONS task/{id} /assignee?userId=mary (sent on behalf of any other user) should return an HTTP code (either 202/4 or 403/4) Thorben Lindhauer Daniel Meyer any thoughts?
          Hide
          meyer Daniel Meyer added a comment -

          Valentin and I just talked about this: all clear.

          Show
          meyer Daniel Meyer added a comment - Valentin and I just talked about this: all clear.
          Hide
          valentin.vago Valentin Vago added a comment -

          In short, the state of the feature:

          • it makes a lookup on the user list endpoint, this prevents 404/401 HTTP errors and when a record is found, this assignee is _considered valid_
          • _valid_ is this ID of an other user who can be referenced by the current user
          • there is a visual indication that a server validation is made
          • there is a visual indication when the user ID for the new assignee is not considered valid
          • only _valid_ user IDs will be "saved" (browser side only! the REST API is more tolerant from my understanding)
          Show
          valentin.vago Valentin Vago added a comment - In short, the state of the feature: it makes a lookup on the user list endpoint, this prevents 404/401 HTTP errors and when a record is found, this assignee is _ considered valid _ _ valid _ is this ID of an other user who can be referenced by the current user there is a visual indication that a server validation is made there is a visual indication when the user ID for the new assignee is not considered valid only _ valid _ user IDs will be "saved" (browser side only! the REST API is more tolerant from my understanding)
          Hide
          sebastian.stamm Sebastian Stamm added a comment -

          The following review hints are still valid:

          Currently, the user can enter an invalid assignee and press enter or the confirm button. The assignee is not changed, but the user does not get feedback why. We should either:
          1. When the entered assignee is invalid, the conform button should be disabled and return should not apply changes OR
          2. When the user tries to assign to an invalid entry, an error message is shown

          If I copy an invalid username into the field using the mouse, there is no indication of invalidity.

          Additional hints:

          • There are some console.info statements left in the code
          • There are a lot of unnecessary requests, even if the value did not change (e.g. when using the keyboard to move the mouse cursor). There should only be requests when the value has been changed
          Show
          sebastian.stamm Sebastian Stamm added a comment - The following review hints are still valid: Currently, the user can enter an invalid assignee and press enter or the confirm button. The assignee is not changed, but the user does not get feedback why. We should either: 1. When the entered assignee is invalid, the conform button should be disabled and return should not apply changes OR 2. When the user tries to assign to an invalid entry, an error message is shown If I copy an invalid username into the field using the mouse, there is no indication of invalidity. Additional hints: There are some console.info statements left in the code There are a lot of unnecessary requests, even if the value did not change (e.g. when using the keyboard to move the mouse cursor). There should only be requests when the value has been changed

            People

            • Assignee:
              michael.schoettes Michael Schoettes
              Reporter:
              sebastian.stamm Sebastian Stamm
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: