• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • None
    • 19
    • 4
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      In certain user cases, the JIRA user would need to select an inactive user in an user picker field.
      Currently the user picker will only list Active users in the JIRA instance.

      It would be nice if we had the option to choose between show or don't show inactive users.

            [JRASERVER-59132] Ability to select inactive users in an User Picker

            I think this would be great as we like to identify other company users who aren't licensed with a product as a business stakeholder in issues for contact purposes. Whats weird is that the service management field "Approvers" seems to allow you to lookup any Jira user regardless of if a product is assigned or not or if they are active or not but the other user pick fields don't behave this way. Maybe its not allowing inactive users with the user pick field maybe we need to make a new customer Field Type called "Account Picker". User implies a license is assigned and active, Account implies they are more or less a "contact". 

            Nicholas Schmitz added a comment - I think this would be great as we like to identify other company users who aren't licensed with a product as a business stakeholder in issues for contact purposes. Whats weird is that the service management field "Approvers" seems to allow you to lookup any Jira user regardless of if a product is assigned or not or if they are active or not but the other user pick fields don't behave this way. Maybe its not allowing inactive users with the user pick field maybe we need to make a new customer Field Type called "Account Picker". User implies a license is assigned and active, Account implies they are more or less a "contact". 

            6dccf8d12880 The issue that you described gets in the way of the workaround to JRASERVER-5982, too. (Tl;dr: you can't add Watchers to an issue security level, so you need to create a custom multiuser picker as a workaround, then either put it in the notification scheme or write an automaton for syncing it with the Watchers widget).

            Piotr Janik added a comment - 6dccf8d12880 The issue that you described gets in the way of the workaround to JRASERVER-5982 , too. (Tl;dr: you can't add Watchers to an issue security level, so you need to create a custom multiuser picker as a workaround, then either put it in the notification scheme or write an automaton for syncing it with the Watchers widget).

            @Alexander Garanin - Actually, there are methods which can extend the multiuser picker without checking for active / inactive users. But if you are using native connection, you are probably screwed. I was facing same issues so I wrote custom scripts to do that, but not sure, if its still valid in 9x versions. But still, should be possible to handle it even natively. 

            Tomáš Vrabec added a comment - @Alexander Garanin - Actually, there are methods which can extend the multiuser picker without checking for active / inactive users. But if you are using native connection, you are probably screwed. I was facing same issues so I wrote custom scripts to do that, but not sure, if its still valid in 9x versions. But still, should be possible to handle it even natively. 

            This behaviour has another implication. We have a "Contributors" custom field, which is multi-user. It basically tracks people who contributed to work on this issue at some point

            When this field has inactive user in it, we cannot add new users to the field (even active ones) without removing the inactive user.

            We have other tools integrated with Jira, which auto-promote issues based on certain events (changes merged, builds completed, etc.) adding contributing users to, well, Contributors field. Those integrations fail when one of the former contributors happened to have left the company, for example.

            So, this "feature" has very real business impact.

            Alexander Garanin added a comment - This behaviour has another implication. We have a "Contributors" custom field, which is multi -user. It basically tracks people who contributed to work on this issue at some point When this field has inactive user in it, we cannot add new users to the field (even active ones) without removing the inactive user. We have other tools integrated with Jira, which auto-promote issues based on certain events (changes merged, builds completed, etc.) adding contributing users to, well, Contributors field. Those integrations fail when one of the former contributors happened to have left the company, for example. So, this "feature" has very real business impact.

            Fabien [Elements] added a comment - - edited

            Hi,

            We have an application that allows you to create a ticket from another (like clone) by retrieving only a few fields defined by the user. If the user selects the reporter but in some tickets the selected user is inactive, the operation will not result in a creation.

            We can't use clone Jira action, because this action clone all system fields, and we need to copy only user-defined fields.

            This limitation impacts some of our customers.

            Best regards,
            Fabien

            Fabien [Elements] added a comment - - edited Hi, We have an application that allows you to create a ticket from another (like clone) by retrieving only a few fields defined by the user. If the user selects the reporter but in some tickets the selected user is inactive, the operation will not result in a creation. We can't use clone Jira action, because this action clone all system fields, and we need to copy only user-defined fields. This limitation impacts some of our customers. Best regards, Fabien

            We have the same issues for termination tickets where a users is disabled in AD. Wish we could pick inactive users. 

            Mia Paahlman added a comment - We have the same issues for termination tickets where a users is disabled in AD. Wish we could pick inactive users. 

            We use tickets to terminate users as they leave company on other internal applications, sometimes users create ticket after the departure and guess what jira does, it doesn't show inactive users.

            Another example of Jira lacking in customization, no wonder there are tons of third party addons which breaks in compatibility after every minor release of Jira. I wouldn't be surprised if this even gets their attention after 5 years. 

            Janardhan, Jaiganesh (NIH/NHLBI) [C] added a comment - - edited We use tickets to terminate users as they leave company on other internal applications, sometimes users create ticket after the departure and guess what jira does, it doesn't show inactive users. Another example of Jira lacking in customization, no wonder there are tons of third party addons which breaks in compatibility after every minor release of Jira. I wouldn't be surprised if this even gets their attention after 5 years. 

            Adi Sorek added a comment -

            I'm deployed process for transferring ownership of all Jira assets from a user to another (for example: leaving employee , role change etc) and in that case, it make sense inactive user will be an option for the Source user field.

            Adi Sorek added a comment - I'm deployed process for transferring ownership of all Jira assets from a user to another (for example: leaving employee , role change etc) and in that case, it make sense inactive user will be an option for the Source user field.

            This is weird that this functionality is not present from the start. One may still have issues created, updated, closed by, people who are not active any more. But the issues are not disappearing - the issues form a valid and needed part of the work, but somehow become unsearchable.
            Weird, so here's my vote.

             

            michal.czapski added a comment - This is weird that this functionality is not present from the start. One may still have issues created, updated, closed by, people who are not active any more. But the issues are not disappearing - the issues form a valid and needed part of the work, but somehow become unsearchable . Weird, so here's my vote.  

            We have a Jira request for Gmail inbox delegation.  Often, delegation is requested for an employee's inbox who recently left the company to ensure no data is lost.  We use user picker fields for selecting the accounts to delegate (we could use a text field, but that opens the door for user error), and because the account is now disabled, it no longer shows in the user picker field.  It would be nice if we could enable look-up for inactive accounts on individual custom user-picker fields.

            Eric R Hartway added a comment - We have a Jira request for Gmail inbox delegation.  Often, delegation is requested for an employee's inbox who recently left the company to ensure no data is lost.  We use user picker fields for selecting the accounts to delegate (we could use a text field, but that opens the door for user error), and because the account is now disabled, it no longer shows in the user picker field.  It would be nice if we could enable look-up for inactive accounts on individual custom user-picker fields.

              Unassigned Unassigned
              psouza Pedro Souza
              Votes:
              228 Vote for this issue
              Watchers:
              113 Start watching this issue

                Created:
                Updated: