This is a useful feature, although we would like email requests to be private by default, and for the portal for be shared by default.  Can these be split into their own settings?

I think these settings where reverted in JSD 4.9:

https://confluence.atlassian.com/servicedesk/jira-service-desk-4-9-x-release-notes-1005326200.html#JiraServiceDesk4.9.xreleasenotes-sharingiscaring

Will this be backported into the Enterprise releases?

3e69f2278c4a , 9f17c03fb7c9

From JSD versions 4.7.x there is an option to make the default sharing as private.
https://confluence.atlassian.com/servicedesk/jira-service-desk-4-7-x-release-notes-987143432.html#JiraServiceDesk4.7.xreleasenotes-private

Is there no way to set the default option as Private?

Please let me know how can I  do this.

Best Regards

Was this feature rolled back? I want all my requests to be private by default but the default is to be shared with organizations. I tried to go to Administration > Applications > Jira Service Desk configuration, and make all requests private by default, but I didn't see an option there. Is there a new way to enable private by default for requests?

there are serious use cases to have it set to private... as the user can even when ticket created still share if he wants and the dark feature is also there... so what is the matter.

I'd also like being able to decide for a request type if sharing should be available or not in general -> this comes into play with data protection regulations

I don't like these 'pushed' changes that requests are now by default private, this should have been an option in the UI, like you've did for e-mail.
Thanks for the darkfeature option, please implement this into a UI option.

Thanks Julien,

We're using the cloud version of JSD, will it be possible to disable the setting there too if/when you deploy this change to cloud JSD?

Harel

sfbehnke, 3qml-sanc, sradbil1965139021 itsau patrick.starrenburg hsafra rbakx1640630196

 Please note that it is possible to disable the new behavior introduced in the Customer Portal in JSD 4.7.x by following the steps below:

• Navigate to the following page to access the Dark Features page:

  <baseUrl>/secure/admin/SiteDarkFeatures!Default.jspa
  

• Enter sd.customer.share.default.private.disabled in the field Enable dark feature, click on the Add button, and verify that the dark feature sd.customer.share.default.private.disabled is listed in the page:
  

After you followed these steps, if a customer is a member of exactly 1 organization, this organization will be automatically selected in the request creation form (as it used to be the case before JSD 4.7.x

Well put, Steven.

Folks, please be sure to vote for JSDSERVER-6761 since this closed ticket is a done (albeit raw) deal.

We have built 25 of our service desks with sharing in mind and on top of that we built plugins according to that logic. This decision is wrong and is going to be costly for me to fix for my company. This single move hurts Atlassians view. People are asking for configuration! Stop screwing around and trying to avoid adding configuration here. It will NEVER be one size fits all. 

Totally agree with Sherryl that this setting must be configurable. 

Hoping that Atlassian can make a quick patch to this so that everyone can adjust as needed!

It is extremely unfortunate that the change was a 180° change, and not a configurable setting.

I have created JSDSERVER-6761 and hope that everyone whose current systems will completely break from this change will vote and have the family and friends vote for that ticket. As this ticket is closed, our comments posted that an opportunity was missed to do the right thing may not get to the right eyes.

Forcing customers to share each time doesn't work for us either. Prefer the way it was previously, or ideally configurable. 

Reading the release notes, https://confluence.atlassian.com/servicedesk/jira-service-desk-4-7-x-release-notes-987143432.html#JiraServiceDesk4.7.xreleasenotes-private this is very disappointing to me. 

Unless I am missing something the implemented feature seems to be 

1. Portal - Now our customers who wanted to share previously have to choose to share each time - and we can't set a default to over-ride this. This is going to upset anyone who was happy with the way it was before, or had used organizations selectively to facilitate mandatory sharing, like us. 
2. Email - Everything is or nothing is shared at Jira level.

If so I was happier with the way it was before and won't be able to upgrade without the customers complaining about the extra steps they need to follow to share tickets, and people being missed out of conversations when someone else forgets to share. 

+1 on a handling on project level.

An alternative would be to toggle the setting "share / do not share" based on an automation rule, which would add much more flexibility to the process.

Our use case requires sharing for some Organizations but not others, so we would want it set at an Organization level.

Because of the previous sharing defaults we only set up Organizations where we have small groups of people who want to see all of each others tickets. E.g.  "Customer 1 Super Users Organization".  

Regular users from "Customer 1" don;t belong to any Organization because they shouldn't see any other tickets apart from their own.

We then use a drop down "Customer Name" field set on each ticket to indicate internally that they are all in the same customer so we can do reports. 

This means a simple On/Off or On/Off at Project level doesn't really help us - it disables or enables our Super Users Organizations from sharing ticket by default but doesn't allow us to add the rest of the customers into an Organization without stopping the sharing of the Super Users.

Ideally we could set it at Org level so that a ticket logged by a super user is shared with the super users org they belong to, and not shared with a regular users org that they also belong to. That way we could abandon our drop down field and the pain of setting it on each tickets, and know this would be taken care of automatically by Organization membership

Turning this off completely breaks our work process - could you please add a project configuration to control default sharing?

Our work processes also require that requests are shared with the organisation by default.

If so Atlassian - whatever is done make sure that the DEFAULT setting is OFF and it has to be explicitly and manually enabled, and it can ONLY be turned on by an administrator and - for good measure - the system gives dire warnings informing the person of the impact come up before the setting is changed.

Totally agree with Harel. Our work processes also require that requests are shared with the organisation by default.

Please make this a project setting.

We used this feature to automatically share tickets between customers. Our tickets involve technical errors to systems that all the customer's team should be aware off.

Turning this off completely breaks our work process - could you please add a project configuration to control default sharing?

I do not see this in the cloud version. I noticed updates that seemed to cancel it in 4.7.0 and move it to 4.7.1. Has that not been released for the cloud version yet?

Hi guilherme.leme,

for some reason, your screenshot did not make it into your comment.

The best would be for you to open a new support ticket via the link https://support.atlassian.com/, so that the Atlassian Support Team can assist you and troubleshooting this behavior, since it is not normal (any newly created request should be private by default on Service Desk 4.7.0)

Hi Julien!!

"All new requests are private, regardless of how many organizations you’re in." for me, it still presents the same problem, when I open a ticket on the portal it self shares for the organization I participate.

guilherme.leme,

the solution created for this feature request is explained here: https://confluence.atlassian.com/servicedesk/jira-service-desk-4-7-x-release-notes-987143432.html

• For requests created from the customer portal:
  "All new requests are private, regardless of how many organizations you’re in. You can still easily share them by choosing your organization in the drop-down menu when raising a request."
• For requests created from the Service Desk mail handler:
  "If you’re part of only one organization, new requests will still be shared by default. Don’t like it? You can go to Administration > Applications > Jira Service Desk configuration, and make all requests private by default."

I hope that it helps!

Fixed? What is the solution created?

Great!

Woohoo! Ready for Release! Great

Now that the status of this request has changed to IN PROGRESS, hopefully we will see this in the very near future.

Atlassian team, kindly update us on the progress and ETA if possible.

We really need this function as we have large customers.

We found that using an organization with 6000+ employees (to make our service desks public for our internal usage of the tool) completely thrashed our Jira with frequent garbage collections. It seems to make a tremendous number of SQL queries. At a glance, it seemed like the number of participants on a request (including organization members) combined with the number of automation rule executions (including customer notifications) really does not scale up well.

Vote for this. It's security hole because any personal request automatically became shared for organisation when customer just forget make request personal.

Same here a lot of problems. It is not just a notifications bombing problem but also a security breach. Any user in the organization can by default see all issues of other members!!

This is causing too much trouble in our company too.

I had to disable all the notifications related to organizations.

Please give it some attention.

This is showing as "under consideration". Does anyone know if this is a "good sign"?

This is creating a daily problem for our organization. PLEASE fix this ASAP or at least provide a workable alternative. 

We love JSD and the organization feature is fantastic, but sharing by default under certain conditions makes the experience incredibly inconsistent for end users and difficult to predict. We need a way to turn this off

All - please read/review my earlier comment above, https://jira.atlassian.com/browse/JSDSERVER-4382?focusedCommentId=1578868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1578868

Again, this functionality if it is setup to be automatic is deeply flawed, and the Atlassian programmers who created/propose this show they have no understandanding of the implications of it. Sure, for a bunch of programmers using Jira and/or Service Desk to record issues they might want to share them with all and sundry. But if JSD is being used by groups like HR it is an disaster waiting to happen. I would go so far as to say that for an IT person enabling the function it could be a dissmissable offense. It's that bad/serious.

The default for this functionality must be disabled, it must have to be explictly enabled, and I would go so far as to require that when someone (an administrator ONLY) turns this on then they are given a dire warning of the consequences of doing so.

Otherwise the functionality of the feature must be drastically changed.

My comments above are based on what we observed when we tested this months ago - if the functionality has already changed then we would need to be advised and we do testing again.

Gerardo,

having a switch that toggles the behavior of the organisation sharing feature would be a good idea.

Some need it (like we do), others have got big problems using it. The "bombardment" of users with non essential content is not correct. You won't get a mail/notification as member of an organisation which shares all the tickets, if the service desk is configured that way. Check for customer notification settings. And, by the way, the user can always chose to have a private or a shared ticket, when creating the ticket.

So just a switch to toggle that behavior on a service desk project base would be a good idea.

We use this feature to automatically share tickets between customers. Our tickets involve technical errors to systems that all the customer's team should be aware off.

To avoid spamming the users we disable the "Organization added" customer notification.

Please don't disable it completely or default it to off - if a change is made please add a project configuration to control default sharing.

i don't mean to be rude but what sort of organisation chooses to automatically share information and bombard users with non essential content. - Im referring to Atlassian.

Seriously this should not be the default behaviour of service desk as it takes away the option to choose by the user and makes it impossible for email tickets to be marked as private from the get go.

Please make the effort and resolve this issue, its not a feature to add this request it's an issue that should be resolved as a priority.

Absolutely essential!

The security aspect of the default sharing could be circumvented by using an appropriate security level scheme. But then request participants would not be able to access the issues because the corresponding field is missing in the security level configuration (https://jira.atlassian.com/browse/JSDSERVER-1703). An issue that's open since 2015. You could vote for this one as well.

This is kind of a security issue for us. Customers usually create tickets by email (no option to check "private"). We don't want to have their tickets visible to all of their colleagues who do use the portal. Instead, we're having to go in and clear it out manually which is repetitive and really should be based on a configurable setting. 

Thanks!

I'd really the ability to have requests marked private by default. Adding someone to a 2nd "dummy" organization as a work-around is not easy to maintain in a larger organization. Plus, it's just a band-aid solution anyway. I see this request has been out there since 2016, Can Atlassian share if this is ever going to get dealt with? 

yip, no customer looks at that field and everyone shares it to the organisation

adddd please

Please implement! 

+1

+1 let's implement it!

+1

This is causing massive problems for us now.. Please update