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.  

This should be configurable by issue type. There are different use cases: Sometimes you raise an issue which should not be shared with anyone, but e.g. we've got a service portal where a customer triggers a new evaluation of a pricelist. This should be shared with everyone in his department. Notification for everybody in a organization can be switch off at least with release 3.5, so mails are not an issue. I suggest a switch on the issue type configuration screen in JSD to set the default value of sharing with private being the default setting.

As a workaround I have added another organisation "ALL" with everyone in it.  
But this needs to be manually kept up to date!
Agreed "private" should be the default setting.

I have to second that request. Private by default, or at least an option to select the default value would be a must.

I can see this problem was first reported on the 12/Oct/2016 9:37 AM  when do we expect the resolution to be implemented? 

Suggested workaround is to add a dummy organization and add all customer with only one organization. By doing this, they will automatically consider having more than one organization and the request is private by default.

Any update when this will be implemented would be great thanks!

This is madness. Tickets should be private unless explicitly shared with an organisation. You can't even set an automation rule to remove organisation. 

This default is MADNESS. Everything William Patino said is correct. What team had the brain fade decision that default sharing with every one in an organization is a good idea. 

We just added organizations for reporting purposes, then the managing Director sent in a request that got sent out to 40 people! This is not a suggestion, I suspect this is a bug. 

+ 1 Billion to get this "logic" removed. For now we have removed organizations. 

I have run into this same problem in our UAT testing before release to the business.

My biggest frustration is that even if I disable the email notifications as suggested above, a more curious employee can just go into the customer portal select *Requests>Organisation, a*llowing them to view any ticket shared with the organisation.

What if an employee raises a sensitive/embarrassing request?
What if higher level management raise requests without thinking?

I have to say this is a serious over sight when creating a service desk, consider majority of people raising requests can be on the less IT savvy side.

A possible workaround, if your main issue are the Emails that get sent out when sharing a request with the organization: Head to Project Settings > Customer notifications and disable the rule Organization added.

When this rule is disabled, requests still will be shared by default, however other members of the organization will not get an Email notification about the created request.

OMG, just ran into this same issue for the POC/trial we are doing. Unbelievable that you cannot change the default to be private instead of copying everyone on the team department. We put everyone into departments so we could easily report and this is the consequence.

+1 Million

+1

This would be a really useful - and should be a standard application for a service desk system.

Thanks, that was far more helpful then Atlassian support who just told me to implement a local server vs just giving me the main goal of preventing it from emailing everyone.

Too bad though, that the default auto fill in and sharing with everyone in their organisation makes it so that you cannot use organisations and categorize issue types based on who made the request or do reporting as to which organization needed more help then others.

Hi wpatino14361353,

You would not need to create an organization for each customer as if the customer does not belong to any organization, the request will not be shared with anyone.

Regards,
Nabil

Maybe I'm not understanding the way this system should be implemented.

Why would it be advantageous for a IT help desk / service desk system to by default share and email any random minor ticket to everyone in a company, department or organization?

Why would a VP or the rest of the company care if Bob can't find the print button? That's not a legit collective learning moment. It's embarrassing for Bob and spam for everyone else.

Most tickets are minor not major outages or problems where everyone needs notification.

Often even when customers think the server is down, they haven't asked anyone around them, so now you have every one thinking and worrying about something that is not true, every one is less productive and disrupted.  

I feel not much thought has been put into this feature and I don't understand why or what scenario exists within an IT help department where most customers or where their customers would want to be spammed by every ticket that may or may not affect them. If this were a software dev or feature team ticket system, I could see it, but not a IT customer service desk.

When Atlassian gets a help ticket request, does everyone in your whole company see it and get a email every time? I doubt it, and some how all of my co-workers are not getting emails about my tickets I put in. So it must be possible on some level, that or jira is not using it's own cloud product that it is selling.

This feature does not work in conjunction with other notification controls or workflows. It works out side of any controls and really was not properly integrated before it was put into the wild. If you can't control a feature or at least turn off a feature, it shouldn't be added.

Suggestions:

If you need less complexity in administration for customers, I could ask for a simplification

• an easy option to remove/disable the share ticket option altogether
• or only have it by default only share with people / orgs they type in, and not auto fill in their organization.

• Another simplification could be remove the share feature altogether

• or remove it's link to organisation.

Workaround Questions:

If we removed all customers and organisations and added them with no organization, would it by default share with everyone in the system or only with people they type in?

The only other idea I had was to make a organization for each person, then when it shares with everyone in a org by default, it is a org of one person and nullified, just it would be a lot of extra work.

+1 we need this too.