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

As per our implementation-of-new-features-policy to get access to new features and improvements for Server and Data Center products, you will need to upgrade to a release that contains the change. Normally it is not backported.

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!

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

+1

Developing for a larger organisation.

If one of their users creates a request related to application A, that is not worth reading by their users contributing to application B.

+ 1. 

+1 my customers are complaining 

+1 

+1 This is a very important feature.
Please go on with development. All workarounds are very ugly.
Please default it to "private" or make it configurable.

Further +1's here. This is a GDPR trainwreck. Not sure this has been made clear further up but we have devised a work around here. As an issue is created we have an automation rule that copies the 'organsiation' name into a custom field called 'Client' and then deletes it. Once the organisation is removed from the ticket the default org wide sharing is disabled with it and cannot be added back. Whilst the option is still presented its selection is rendered obsolete. We are then free to do our analysis and reporting by client from the custom field. Only down side is i have to keep an identical list of clients in both the 'Organisation' and custom field and make sure they stay aligned or the automation will fail.

+1 to everything Matt Carter just said. My main issue is the inability to turn of the "Share" feature when viewing the issue in the portal. Why is it default functionality that any e-mail address (seemingly in the universe) could have an issue "shared" with them by a customer, and they would in turn be able to access the service desk portal (register new account) and its functions + see the issue. We DO NOT want our customers to have the ability to share tickets with the world.

+1 for GDPR - this is non-compliant. Information sharing must be opt-in by default, not opt-out, and the 'sharing with organisation' feature is not even common sense. Almost all tickets fall in to one or more of the following categories:
1. Private (e.g. IT support request), so at least embarrassing if shared
2. Minor (so not worth broadcasting)
3. Confidential (should not be broadcast)

Organisations were configured at our organisation recently as an attempt to try to prevent customers from being able to share tickets via Jira Service Desk with other organisations inappropriately, i.e. across organisational boundaries.

Inappropriate customers have been added to Jira Service Desk since Day 1, when our customers do actions such as:

• CC our client or suppliers (forwarding an email and CC'ing) in an email that relates to them but should be a private internal ticket - happens a lot
• When our clients email Service Desk (perhaps they shouldn't have the email address but have it) and copy in our representatives
• CC mailing lists or other ticket systems.

Configuring 'Organisations' did not help partition users into their own organisations as hoped. Instead, unexpectedly over the weekend it started sharing new incoming tickets with the whole organisation. This is absolutely not the behaviour that was expected or wanted from 'Organisations'.

Initially, after first rolling out SD, on Day 1 we had to prevent Jira Service Desk from sending any email outside of our organisation using our email server because of external customers being added by our customers. We need to remove this restriction though so that we can reply to external customers that we do want (suppliers, sister companies, etc.). Unfortunately we cannot safely do so until we find a solution to prevent cross-posting across organisations.

Have just tried to revoke access to this as well for my organisation. Would appreciate being able to group by organisation and revoke access to sharing for users as well.

John Ashton posted a comment regarding this issue in the corresponding JIRA Service Desk Cloud ticket.

"A solution to this is REQUIRED by 25/05/2018 as the current solution is not compatible with EU GDPR regulations."

I want to make all of you on this ticket aware of the urgency of that request as well.

Edit: Somehow a picture I had in the clipboard go attached. Sadly I don't have permission to delete ist. Can someone take care of that?

Please! 

+223

+1 not good that you could be sharing very personal information with H&S for instance with your whole organization by default.

+1 vote from me. I see this as a huge Bug in the system. It does not make sense at all the way it is setup right now. 90% of service tickets do not need to be shared with the whole organization and thus organizations should not be added by default. Why does the whole organization need to know when toner needs to be ordered for one printer! Needs to be set private by default or not shown to the customer at all. The Administrator should decide whether the customer should be allowed to share the particular Request type as it is done with Request Type forms. 

I saw one workaround posted where you need to create multiple Organizations and put all users in at least 2 organizations. that way it defaults to Private. This workaround just puts more work on the administrator to manually manage the system. Personally, now I have to manually add 500 customers to 2 organizations... and thats just one of our Client Silo's. In addition, now I have to keep up with additions and removals of customers to make sure they are added and removed from both organizations instead of just letting customers sign up in their respective customer portals. 

The second workaround is to disable the Automation where it sends the email when organizations are added. Why? I like this feature and helps us manage incidents where our agents can add an organization group that holds client stakeholders, and they get notified and can opt in to follow the ticket. I believe, this is what it is designed for and a critical feature for us. Thus, this workaround is not acceptable either, as it makes the whole "Organizations" feature useless. 

https://jira.atlassian.com/browse/JSDCLOUD-4382

I have been a JIRA Software fan for over 5 years and pushed my company to use JSD. I hope Atlassian fixes this quickly as now I am struggling to accomodate some basic requests from my company. 

+100. This default behavior completely backwards and breaks privacy.

I would love this feature. To me, disabling the notification is just a band-aid solution that doesn't actually solve the root problem. I would love to know which industry uses this software in a way that sharing publicly by default is a smart solution.

Another vote for this to be fixed. The implementation of 'Organisations' in SD is deeply flawed. We implemented it and, thank goodness, found the issues due to the major design flaws quickly so we just as quickly totally reversed it. As it stands the 'Organisations' feature is totally unusable for us. Worse it could end up with a huge backlash and fallout in almost all real world companies.

Our situation:

1. European HQ of global company with national offices in most major European countries.
2. We populate our JIRA Service Desk with users by linking to Microsoft AD. This brings in all users and allows us to have them authenticate with their AD account but we get in all the 'non real person' accounts junk as well.
3. Organisations looked good because we could do one time effort to pull in live persons (users=customers) into the various organisations (offices/sites) and we would then have a clean user list per office.
4. So we made an organisation for each national office and put users for a site into each organisation. Great! Except...

Like everyone we found that the default in SD was that when customers raise a request via the portal the request was shared with the whole organisation (what!?!) and worse it was emailed to everyone (double what!?!) Really the way to go if you were using SD for reporting HR requests - you can imagine the sort of request subjects there!

The setup/design for organisations should be:

1. Baseline, as always, be that the system administrator can fully customise all aspects
2. Baseline, by default, be that the setup initially exposes the absolute minimum of information. Having the default when you turn on an option be that information is blasted out to your whole company is, simply, insane.
3. I don't agree with starting with 'Private' and tightening down. The system should start tight and loosen - only to be done by system administrator.
4. I don't agree with using the term 'Private' in the first place, there is no need. By default request is private and you have to share by choice with extra persons. It simply is playing with a loaded gun to do otherwise. The only reason 'Private' was used I think is because Atlassian set it up as totally exposed to all and sundry in the first place.
5. System admins should have the option to decide whether to even surface the 'Organisation' object as something to share with at all. We would never - ever.

Finally it seems clear to me that Alassian must not have people with 'real world' experience doing the features design in SD. I don't think any experienced/sane administrator of any organisation of > 2 persons would ever have agreed to this - as it stands. If this is the case then Atlassian should get (trusted) customer input on design decisions like this before they build the functionality and run the risk of huge backlash from system admins getting bitten by flawed design logic functionality.

+1

Just to let people know - there is a way to kill this feature completely but not control it in a fine grained manner (like what is being asked here). You can disable this component that controls Sharing from Customer Portal entirely which will prevent this from showing up and putting your information at risk by being shared externally.

It makes zero sense to have requests shared by default with all the organization members. You should be able to configure this and if don't the less intrusive and privacy-breaking option should be the default option at least. Please fix it soon.

+1

Another confirmation of this Problem, that is causing plenty of internal frustration. Please provide us with a "default" setting for this option or set the default to Private. 

I second @Jan-Peter Rusch's comment - it should be configurable by issue type whether a request is automatically shared with an organization or kept private. Would love to see this feature soon!

urg.  this bug caused me major embarrasment within my team, has hurt our own branding and most certainly blunted the push for more JIRA internally.  a major oversight guys.  please fix it.