• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • None
    • 2,161
    • 1
    • 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.

      Problem Definition

      In some cases, JIRA Service Desk administrator does not want the customer to be able to add a participant.

      Suggested Solution

      Add an option to disable sharing feature under Customer Permission and remove the Share feature from the Customer Portal.

       

      Workaround

      Here are some of the workaround that will help reduce the impact

      • Disable notification for “Organization added” event from Project Settings > Customer notifications
      • Disable automatic sharing of request with organization unless the customer manually selects an org at https://<YourSite>.atlassian.net/jira/settings/products/jira-service-management-configuration 
        • Set "Should new requests automatically be shared with a customer's organization?" to "No, don't share email requests with the customer's organization. Requests sent from the portal will not be shared unless the customer selects otherwise" option.

            [JSDCLOUD-7057] Allow Service Desk administrator to disable the "Share" feature

            cea8b6bddbc3 Thank you for the update, however can JSDCLOUD-10908 at least be prioritized? We're not asking for much, just the option to hide the field at the very least. I imagine that would be much easier to implement at first.

            Then the ability to outright disable it (as requested in this ticket) could be a future enhancement and done at a later date. Would you be willing to forward this idea along?

            Thank you!

            Julian Snow added a comment - cea8b6bddbc3 Thank you for the update, however can  JSDCLOUD-10908 at least be prioritized? We're not asking for much, just the option to hide the field at the very least. I imagine that would be much easier to implement at first. Then the ability to outright disable it (as requested in this ticket) could be a future enhancement and done at a later date. Would you be willing to forward this idea along? Thank you!

            Thank you for sharing this feedback and following this ticket.

            We evaluated this ticket and we understand that there are valid scenarios where administrators would like to restrict customers from adding new participants and sharing the portal with others. However, we will not be able to prioritise this at the moment as there are other items in the short term roadmap which are of higher priority. We will update you when we decide to pick this up in our roadmap.

            Raafi Mohammed, Product Manager, Jira Service Management

            Raafi Mohammed added a comment - Thank you for sharing this feedback and following this ticket. We evaluated this ticket and we understand that there are valid scenarios where administrators would like to restrict customers from adding new participants and sharing the portal with others. However, we will not be able to prioritise this at the moment as there are other items in the short term roadmap which are of higher priority. We will update you when we decide to pick this up in our roadmap. Raafi Mohammed, Product Manager, Jira Service Management

            Hi d0d1ba410583 ,

            In response to your comment in Feb that this is lower priority, please reassess this. I'd have thought Atlassian would prioritise security issues.

            We had a password reset email shared to the entire company which caused a big reputation hit on the decision to move to JSM.  We had to disable the feature.

            In addition, this feature causes further security issues as use of organisations is the workaround for being unable to see where an external user comes from when they choose not to share their email. Which is an important security concern in Business-to-Business support, rather than public-to-business support where I get the need for privacy. We had to disable the feature as it was abused and use an automation to add the user's email to ticket description.

            In the short term I've added a related feature request around giving admins more control around visibility of external user's email addresses.

            See: JSDCLOUD-14924.

            Please link these issues as related, because if we had 7057, we would not need 14924.

            Another workaround to consider is to add a validation on the create transition on the workflow to ensure that the organisation field is empty. Although this has usability concerns, so you need to leave clues in your JSM Request Instructions.

            James Rickards (Spark-Nel) added a comment - Hi d0d1ba410583 , In response to your comment in Feb that this is lower priority, please reassess this. I'd have thought Atlassian would prioritise security issues. We had a password reset email shared to the entire company which caused a big reputation hit on the decision to move to JSM.  We had to disable the feature. In addition, this feature causes further security issues as use of organisations is the workaround for being unable to see where an external user comes from when they choose not to share their email. Which is an important security concern in Business-to-Business support, rather than public-to-business support where I get the need for privacy. We had to disable the feature as it was abused and use an automation to add the user's email to ticket description. In the short term I've added a related feature request around giving admins more control around visibility of external user's email addresses. See: JSDCLOUD-14924 . Please link these issues as related, because if we had 7057, we would not need 14924. Another workaround to consider is to add a validation on the create transition on the workflow to ensure that the organisation field is empty. Although this has usability concerns, so you need to leave clues in your JSM Request Instructions.

            Hi d0d1ba410583 , its surprising that Jira team is not being able to work on the issue created 6 yrs ago in 2018.

            Please take out some time out of your busy schedules to address this critical issue which has the capability to spam the whole organisation.

            Expecting constructive work to start on this soon. 

            Sandeep Gupta added a comment - Hi d0d1ba410583 , its surprising that Jira team is not being able to work on the issue created 6 yrs ago in 2018. Please take out some time out of your busy schedules to address this critical issue which has the capability to spam the whole organisation. Expecting constructive work to start on this soon. 

            Hi!

            I found a solution via automation, which worked in my case.
            If the issue is created and the customer selects to share with the organization, then the organization field will be removed.

            Poliana Garcia added a comment - Hi! I found a solution via automation, which worked in my case. If the issue is created and the customer selects to share with the organization, then the organization field will be removed.

            My team woke up today to this horrible (required) new field that was added to ALL our request forms without our knowledge or consent. This is a huge problem. Users are now unknowingly spamming the entire organization with this unnecessary option. How do we remove this immediately??

            Faten Abilmouna added a comment - My team woke up today to this horrible (required) new field that was added to ALL our request forms without our knowledge or consent. This is a huge problem. Users are now unknowingly spamming the entire organization with this unnecessary option. How do we remove this immediately??

            To reinforce the workaround and prevent sharing requests with the entire organization during creation, we have implemented a scripted validator for the Create transition.

            // use the IDs of your custom field (Organizations) and organization accordingly
            
            issue.customfield_XXXXX ?    
                !issue.customfield_XXXXX.some(c => c.id == 'XX') :
                true 

            Patrik Bernát added a comment - To reinforce the workaround and prevent sharing requests with the entire organization during creation, we have implemented a scripted validator for the Create transition. // use the IDs of your custom field (Organizations) and organization accordingly issue.customfield_XXXXX ? !issue.customfield_XXXXX.some(c => c.id == 'XX' ) : true

            +1

            Sam DeWind added a comment - +1

            I would say those aren't workarounds, but other ways to limit Notifications going to the whole organization.  This doesn't prevent the customer from making the choice to sending new tickets notifications to the whole organization.

            Dan Breyen added a comment - I would say those aren't workarounds, but other ways to limit Notifications going to the whole organization.  This doesn't prevent the customer from making the choice to sending new tickets notifications to the whole organization.

            The workarounds provided do not alleviate the fact that we can't hide the button from customers to solve the problem in the first place. 

            George Wilson added a comment - The workarounds provided do not alleviate the fact that we can't hide the button from customers to solve the problem in the first place. 

              cea8b6bddbc3 Raafi Mohammed
              esantos@atlassian.com Eduardo Santos
              Votes:
              476 Vote for this issue
              Watchers:
              267 Start watching this issue

                Created:
                Updated: