Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-42446

Restrict Reporter Field to only users with Create Issues Permission

    • 15
    • 31
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

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

      Problem

      Currently, the Reporter field can be changed from Current User to any browsable user in the system. If you start entering a user that does not have Create Issues permission on that project, it still shows them.

      Assignee already works like this; if you try to type a user that is not assignable, they do not show up.

      Resolution

      Only show users that can create issues in that project, as already exists for Assignee field.

            [JRACLOUD-42446] Restrict Reporter Field to only users with Create Issues Permission

            Hi 6b5adc8df6a2 this is now tracked here: ID-8128 – Limit User Picker to members of certain groups/roles in System Fields in Jira Software and Jira Work Management and JIRA Service Management

            Anusha Rutnam added a comment - Hi 6b5adc8df6a2 this is now tracked here: ID-8128 – Limit User Picker to members of certain groups/roles in System Fields in Jira Software and Jira Work Management and JIRA Service Management

            Please, this bug is really annoying... if it could be possible we need this fix, can you reopen?

            Miguel Dlmm added a comment - Please, this bug is really annoying... if it could be possible we need this fix, can you reopen?

            Atlassian Update - January 2023

            As per this comment I am closing this ticket.

            If you disagree with the closing of this ticket, please add a comment here saying why and we can reopen it.

            Anusha Rutnam added a comment - Atlassian Update - January 2023 As per this comment I am closing this ticket. If you disagree with the closing of this ticket, please add a comment here saying why and we can reopen it.

            As Rostislav Harazin (very helpfully!) identified above, I believe this issue is a duplicate of JRACLOUD-36896 – Limit User Picker to members of certain groups/roles in System Fields. Although this issue is older, the above one has more votes.

            I recommend that watchers of this issue vote on and watch the above issue. So that votes aren't split, I believe this ticket should be closed, but I will wait a week before taking any action in case anyone thinks both issues should continue to exist. Thank you!

            Anusha Rutnam added a comment - As Rostislav Harazin (very helpfully!) identified above, I believe this issue is a duplicate of JRACLOUD-36896 – Limit User Picker to members of certain groups/roles in System Fields . Although this issue is older, the above one has more votes. I recommend that watchers of this issue vote on and watch the above issue. So that votes aren't split, I believe this ticket should be closed, but I will wait a week before taking any action in case anyone thinks both issues should continue to exist. Thank you!

            Dear Atlassians,

            with all due respect to you and your amazing work, from our point of view this should not be a mere feature request. It should be reconsidered as a big bug.

            There are many similar reported issues (probably causing a fragmentation of votes) which proves in a way how big privacy concern it is.

              • It is creating panic among our teams that clients visible in the Reporter field and if selected may provide clients access to our internal discussions, work, etc.
              • The typical problem with the "Browse Users" permission is that we, and many others, invite external users (project partners, customers) to their JIRA projects, but cannot give them this permission, as that would disclose other customers/partners one is working with.
              • It is a big issue and seems like a problem for GDPR that even if you don't have access to another Jira project you can see that project's customer's personal information (name and email address).
              • Dangerous - it breaches privacy where issue content is shared in an email notification to the new "reporter"
              • Confusing - the new "reporter" doesn't understand the reference/relevance to their product support
              • Time wasting
                1. the "reporter" wastes their time in alerting us of the error in selecting the wrong reporter, and
                1. it wastes our time to understand what has happened and how to appropriately resolve the reporter used in error, and
                1. it delays the issue resolution if the SD Team member is trying to get further information from who they assume is the intended reporter to fix the issue. *Especially if the issue is a P1 or P2 these delays could be very bad.
              • Exposes customer contacts to any Jira user on the system.
              • External customers could be accidentally associated with others tickets not remotely related to theirs

            Maybe more.

            Rostislav Harazin added a comment - Dear Atlassians, with all due respect to you and your amazing work, from our point of view this should not be a mere feature request. It should be reconsidered as a big bug. There are many similar reported issues (probably causing a fragmentation of votes) which proves in a way how big privacy concern it is. Suggestion : Don't show users (or Portal Only Customer) who doesn't have Jira application access to appear on reporters and project roles list (59 votes) https://jira.atlassian.com/browse/JSDCLOUD-10055 Created 10/Mar/2011 2:03 PM It is creating panic among our teams that clients visible in the Reporter field and if selected may provide clients access to our internal discussions, work, etc. Suggestion : Limit User Picker to members of certain groups/roles in System Fields (312 votes) https://jira.atlassian.com/browse/JRACLOUD-36896 Created 07/Feb/2014 1:55 AM (related JRASERVER-7659 : 16/Aug/2005 4:13 PM) The typical problem with the "Browse Users" permission is that we, and many others, invite external users (project partners, customers) to their JIRA projects, but cannot give them this permission, as that would disclose other customers/partners one is working with. It is a big issue and seems like a problem for GDPR that even if you don't have access to another Jira project you can see that project's customer's personal information (name and email address). Suggestion : Restrict Reporter Field to only users with Create Issues Permission (51 votes) https://jira.atlassian.com/browse/JRACLOUD-42446 Created: 13/Mar/2015 1:38 PM Dangerous - it breaches privacy where issue content is shared in an email notification to the new "reporter" Confusing - the new "reporter" doesn't understand the reference/relevance to their product support Time wasting the "reporter" wastes their time in alerting us of the error in selecting the wrong reporter, and it wastes our time to understand what has happened and how to appropriately resolve the reporter used in error, and it delays the issue resolution if the SD Team member is trying to get further information from who they assume is the intended reporter to fix the issue. *Especially if the issue is a P1 or P2 these delays could be very bad. Bug : Customer without permission to project can be added as a reporter of a request (7 affected) https://jira.atlassian.com/browse/JSDCLOUD-8649 Created 28/Nov/2019 12:27 PM (probably much more earlier according to issuekey) Exposes customer contacts to any Jira user on the system. External customers could be accidentally associated with others tickets not remotely related to theirs Suggestion : Customers shouldn't be suggested on User Picker custom fields on non-Jira Service Management projects (19 votes) https://jira.atlassian.com/browse/JRACLOUD-76780 Created 07/Jun/2021 4:08 PM Maybe more.

            Please kindly add this suggestion to roadmap soon. Our customers are in financial industry and they are quite sensitive about the data security. They don't want to know their cases in the system could be shared to random parties by mistake by our agents. Thanks.

            Colin Huang added a comment - Please kindly add this suggestion to roadmap soon. Our customers are in financial industry and they are quite sensitive about the data security. They don't want to know their cases in the system could be shared to random parties by mistake by our agents. Thanks.

            Please pick this up soon!

            Matt Meissner added a comment - Please pick this up soon!

            I fully agree with Glen's comment : actual behaviour is dangerous / confusing and will lead to waste time.

            Hope this suggestion will be added to roadmap soon !

            Nicolas Choupin added a comment - I fully agree with Glen's comment : actual behaviour is dangerous / confusing and will lead to waste time. Hope this suggestion will be added to roadmap soon !

            If this is 'working as designed' it is totally flawed in basic logic and common sense. As others have said, this is not a feature request but a bug.

            We have multiple JSM projects, each set up with its own specific organizations and customers. This ability for a Service Desk Team member to select a customer from any JSM project is:

            1. dangerous - it breaches privacy where issue content is shared in an email notification to the new "reporter"
            2. confusing - the new "reporter" doesn't understand the reference/relevance to their product support
            3. time waste -
              1. the "reporter" wastes their time in alerting us of the error in selecting the wrong reporter, and
              2. it wastes our time to understand what has happened and how to appropriately resolve the reporter used in error, and
              3. it delays the issue resolution if the SD Team member is trying to get further information from who they assume is the intended reporter to fix the issue. *Especially if the issue is a P1 or P2 these delays could be very bad.

            The Organization and Customer within a JSM project should only be the listed options in Reporter or Request Participant. Period.

            Glen Cochrane added a comment - If this is 'working as designed' it is totally flawed in basic logic and common sense. As others have said, this is not a feature request but a bug. We have multiple JSM projects, each set up with its own specific organizations and customers. This ability for a Service Desk Team member to select a customer from any JSM project is: dangerous - it breaches privacy where issue content is shared in an email notification to the new "reporter" confusing - the new "reporter" doesn't understand the reference/relevance to their product support time waste - the "reporter" wastes their time in alerting us of the error in selecting the wrong reporter, and it wastes our time to understand what has happened and how to appropriately resolve the reporter used in error, and it delays the issue resolution if the SD Team member is trying to get further information from who they assume is the intended reporter to fix the issue. *Especially if the issue is a P1 or P2 these delays could be very bad. The Organization and Customer within a JSM project should only be the listed options in Reporter or Request Participant. Period.

            Milad S. added a comment - - edited

            Our JSM agents added a reporter who is not a customer of the specific project (as all customers are available in the reporter field) and as a result, several customers have not received the notification. And even worse, the agents thought they already responded to the customer and was waiting for a response.

            Given that the JSM main purpose is to communicate with the Customer, the system shall only display users in the reporter field who can raise tickets or at least display a warning/indication when an agent selects a user who cannot (i.e. does not have Create Issues Permission).

            As others mentioned, I think this is more than a feature request, it is common sense.

             

            Milad S. added a comment - - edited Our JSM agents added a reporter who is not a customer of the specific project (as all customers are available in the reporter field) and as a result, several customers have not received the notification. And even worse, the agents thought they already responded to the customer and was waiting for a response. Given that the JSM main purpose is to communicate with the Customer, the system shall only display users in the reporter field who can raise tickets or at least display a warning/indication when an agent selects a user who cannot (i.e. does not have Create Issues Permission). As others mentioned, I think this is more than a feature request, it is common sense.  

            This is a bug and a security flaw

            Benjamin Saberin added a comment - This is a bug and a security flaw

            As it stands, we can't deploy unique projects for customers because the reporter field exposes entries that have no ability to be reporters in that project in the first place.  This isn't a feature request, this is a bug.

            Paul Poteat added a comment - As it stands, we can't deploy unique projects for customers because the reporter field exposes entries that have no ability to be reporters in that project in the first place.  This isn't a feature request, this is a bug.

            I agree that this should be treated as a bug and not a feature. We really don't want our internal teams to tag portal users (our customers) on internal projects.

            Please prioritize fixing this bug.

             

            Mohammed Elyas Ahammad added a comment - I agree that this should be treated as a bug and not a feature. We really don't want our internal teams to tag portal users (our customers) on internal projects. Please prioritize fixing this bug.  

            this should be treated as bug and not a feature... you have the assignment of persons to a project because you dont want to mix the persons up between projects! 

            Daniel Cabaco added a comment - this should be treated as bug and not a feature... you have the assignment of persons to a project because you dont want to mix the persons up between projects! 

            Attention Jira:

             

            Why do all of our customers have to come up for internal only projects? We don't want to tag someone on internal projects just as I am sure you wouldn't want to tag us on your internal items at Atlassian. 

            David Barreras added a comment - Attention Jira:   Why do all of our customers have to come up for internal only projects? We don't want to tag someone on internal projects just as I am sure you wouldn't want to tag us on your internal items at Atlassian. 

            mdennis784526431 added a comment -
            ALL of the Customers (Portal Users) in JSD are ALSO showing up in the user pick list for the following in Jira:
            1. Assignee field
            2. Reporter field
            3. Watchers field
            4. The @Mention User Feature

            This "Suggestion" ONLY addresses the Reporter field and does not address the Watcher field or the @Mention User Feature. There is a work-around for Assignee, but I'd strongly argue that should be the default behavior vs. needing to find and implement the workaround.
             
            There is no way of restricting ALL Portal Users in JSD from being exposed in Jira for all of them.
             
            There should be a a Permission to enable/disable JSD Portal users from being seen in the lists. Or at a minimum that only certain Groups can be shown in these drop down lists of users.
             
            We simply can NOT risk our Customers getting an email from our internal Jira when someone inadvertently clicks on the wrong name. We have literally thousands of Customer emails in our JSD. They should never be able to be in these drop down lists.
            This is a SHOWSTOPPER issue for us, we will need to abandon our use of JSD without a quick solution in Jira/JSD Cloud.|

            mdennis784526431 added a comment - ALL of the Customers (Portal Users) in JSD are ALSO showing up in the user pick list for the following in Jira: Assignee field Reporter field Watchers field The @Mention User Feature This "Suggestion" ONLY addresses the Reporter field and does not address the Watcher field or the @Mention User Feature. There is a work-around for Assignee, but I'd strongly argue that should be the default behavior vs. needing to find and implement the workaround.   There is no way of restricting ALL Portal Users in JSD from being exposed in Jira for all of them.   There should be a a Permission to enable/disable JSD Portal users from being seen in the lists. Or at a minimum that only certain Groups can be shown in these drop down lists of users.   We simply can NOT risk our Customers getting an email from our internal Jira when someone inadvertently clicks on the wrong name. We have literally thousands of Customer emails in our JSD. They should never be able to be in these drop down lists. This is a SHOWSTOPPER issue for us, we will need to abandon our use of JSD without a quick solution in Jira/JSD Cloud. |

              Unassigned Unassigned
              smackie@atlassian.com Shannon S
              Votes:
              52 Vote for this issue
              Watchers:
              45 Start watching this issue

                Created:
                Updated:
                Resolved: