-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
2,074
-
1
-
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.
- Make sure to set the customer share permissions as per your requirement
- is cloned from
-
- Gathering Interest
- relates to
-
- Gathering Interest
[JSDCLOUD-7057] Allow Service Desk administrator to disable the "Share" feature
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.
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.
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
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.
Just happened today where a Service Request was shared with the whole Organization. This should be removed, or configured at the organization or even user level. Some people will abuse it. If it can't be configurable, it should be removed.
+1
we had to set-up automation to send messages to our support team to manually fix these any time they happen. Agreed this is half baked.
What is a problem for us, is that when a customer does choses to Not Share, it removes their organization. All of our assignment and routing rules rely on the client's organization.
Not good enough @Sushant
Releasing half-baked features that break existing customer workflows is not acceptable to start with. Failing to prioritize finishing the job just adds to the incentive to move to a platform owned by someone who actually prioritizes good customer experience.
I need a rock solid ITSM platform, not a bunch of incomplete unusable new features.
Thank you for sharing your feedback on this feature request. While we understand that this is an important need, we are unable to work on this at the moment due to other competing priorities.
However, if this changes in the future, we will keep you posted on this ticket.
- Sushant Koshy, Product Manager, Jira Service Management.
Could you start working on improving and cleaning up the current functionalities (like this one) instead of constantly adding new ones? At the moment, my users are emailing each other across the organisation via this functionality, and admittedly they are having a great time doing it, but I am having less fun.
I had to build an automation just to fix instances where people accidentally share their tickets with our whole company. And of course that automation now counts against our quota thanks to the new "packaging model."
Cool.
I agree with Simon, this is unnecessarily complicated for our end users. Would love to see improved functionality implemented soon.
Please address this.
I need to use Organizations, but the 'Share With' field confuses the hell out of my user and and adds nothing of value.
We were able to achieve this on our datacentre instance by removing the "Manage Watchers" for the "Service project customer - portal access" role in the projects permission scheme. This blocks customers from being able to share the ticket hiding the button entirely but allowing agents to still do it via the Jira agent view.
We could also apply this workaround in our Data Center instances.
We were able to achieve this on our datacentre instance by removing the "Manage Watchers" for the "Service project customer - portal access" role in the projects permission scheme. This blocks customers from being able to share the ticket hiding the button entirely but allowing agents to still do it via the Jira agent view.
It astounds me that Atlassian hasn't fixed this yet.
Some of the most obvious UI configurability seems to have been overlooked by Atlassian in rolling out JSM cloud.
Like customising and/or removing this field and the ability to customise the "Email confirmation to" field.
OMG...
Absolutely ridiculous that this isn't implemented yet! Tickets could contain some confidential info and/or screenshots and default is to leave it sharing to the whole organization? I was dumbfounded when I saw that this is not configurable.
DEV'S: MAKE THIS A PRIORITY!!
It really is disappointing that this still hasn't been implemented. I voted for this feature 4 years ago and it is still an issue, and the reason why we only allow our users to log tickets via email.
We are implementing SAML and would like to allow users to access the site to be able to log tickets but not being able to manage this will cause confusion and dissatisfaction with our staff if they start seeing and getting notified about each others requests.
I would like to know when this is going to be added to your dev stream.
Thanks
Paul
The lack of this feature makes it impossible for us to use Jira Service Desk....
Would love to see this implemented. I understand how it is build and the vision behind it. But maybe it would be great just to hide it instead and use a default value there
We've been frustrated by this issue as well.
Today, as a fix, we've applied Jira automation. You can clear the "Organization" field on creation (or at any/all transitions). What this does is removes any organization that the user might share it with. It works great for when users haphazardly share with the org.
Here's how we do it for a project, but it can be done globally as well:
- Project Settings > Automation
- Create Rule
- Make the new trigger "Field Value Changed"
- Enter "Organizations" in the "Fields to monitor for changes"
- Keep "For" blank so it reads "All issue operations", then save
- Add new component > new action
- Select "Edit issue"
- in the "Choose Fields to Set..." area, enter "Organizations"
- Keep the "Organizations" dropdown blank so it reads "This field will be cleared" and save
You can test it by creating a test org with team members, create a ticket and add share with the test org (the org has to be added in the "customers" section of the project), once the ticket is created, hit refresh and it will disappear.
This really only works if there is no business requirement to share a ticket with an org, as any time someone tries to share it with an org, it will clear the field.
Hope this helps.
It is very worrying that this one is still in "gathering interest" - it is not a question of whether users want it or not, it is a matter of security! Users share confidential information with the entire organization without them knowing. Get a solution implemented!
This absolutely needs to be done - we have so many customers complaining that they are receiving "All of your support platform updates" and blaming us for the issue, when we can't limit their ability to share with the organization. So many people go through the support form so quickly, they don't realize what the field does. Many of them see a dropdown with their organization and select it because they think "Oh I'm supposed to mark that I'm from this company."
It's unbelievably unintuitive to users and creates possibly the worst customer experience possible by spamming them. On top of being obnoxious (and making us seem incompetent) it prevents users from receiving updates from the tickets they DO care about. What an absolute mess of user experience. I know this has been asked for for years - please get with it, Atlassian.
The idea behind this option makes sense, don't share the ticket with other users. However the feature is poorly implemented. We assign tickets by org and track tickets by org. So when a user decides to share with 'No One', then the issue goes into a black hole until someone stumbles on it or the customer complains. Very poorly implemented. Either give us the option to remove, or don't give the customer the ability to destroy workflows.
This seems like some what of a privacy concern as well. In a ticket that involves private and confidential information there should be NO option to share anything, and at minimum the option to remove it from the request form. Seriously not sure why this is not an option for such an advanced request system.. You all need to respond to this request.
Hi. please disable this option in portal request. This generate confution with clients.
Badly need this, i'm not sure why this isn't an option yet. We have to manage customers on each of our customers helpdesks.
We also want to disable this on the form screen. We don't want our users to decide what gets shared or not, we want to define that trough workflows so there's consistency.
+1 to this, do you have any ETA as to when this is likely to be implemented?
Why do we even have Organizations if they aren't helping us make workflows easier? This Share feature defeats the purpose of grouping our users together for multiple projects.
this should be implemented as soon as possible. Little QOL improvements like this really do a lot for user adoption and preventing unnecessary questions / errors from staff adopting the service desk implementation.
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!