Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Organization Share Effects when editing tickets

Viktor Karlsson February 18, 2022

Hi, I'm evaluating JSM and few other products as a potential new SD-tool.

One thing that I just can't wrap my head around is the organization sharing and its potential effectsOur scenario is mostly b2b were organizations would contain 5-10 reporters each, and they would then request support from us, and they (the different orgs) are defiantly not related and should not in any way risk seeing issues between each other

Two things:

* Why is organization sharing the only field that connects an issue to the organisation ? Sharing a ticket has nothing to do with if the ticket belongs to an org or not, plenty of other service-desks has this as a core feature. If you've tickets created by customer that is part of an organisation then logically you would have something on the issue binding the two

* Say that:

1. A customer of org. X creates an issue and shares it with their org X

2. Agent in backend switches reporter on the issue to someone in Org Y by mistake This causes a totally different org to have access to the ticket. Can I set restrictions or do I literally have to clear org in automation everytime something happens to ensure i dont get a complete mismatch because an agent might write a name wrong

I like JIRA because if your willing to put down the time you can configure so much compared to other out of the box solutions, but damn, sometimes pure core functionality such as this and teams/groups/second line is just handled so differently.

2 answers

0 votes
Josh Costella
Community Champion
February 18, 2022

@Viktor Karlsson What @Jack Brickey said. However, I would take it a step further. 

I would look at why modifying the reporter would be something that needed to happen often enough to begin with that would warrant this concern?

Is there an overabundance of people creating tickets for other people and the service team has to correct it? 

If it was me, I would try to solve for that first since that seems like an uncommon process and use case. 

Viktor Karlsson February 18, 2022

Thanks for the quick responses.

I agree that it's a handling error, but it's not a one in a million use case here. It happens that for one reason or the other we need to change the reporter. It could be someone quits on the opposite company, vacation or something that should've been assigned to someone else, or just something urgent and the person on the other end isnt working that day. This is b2b territory, and maybe I've the wrong expectations on jira for it ?

It's just extremely easy to do this mistake because you type a name in a list where many people could have the same name (because it's not scoped in any way), and this one mistake could obviously cause a lot of sensitive information leaking to a completely different company.

Safest route seems to be not to allow this field to change. Just wanted to ask in case I missed something.

0 votes
Jack Brickey
Community Champion
February 18, 2022

So in JSM customers can optionally belong to an organization as a means of grouping customers. Customers in one organization cannot see issues associated with an organization they do not belong to. A reporter can optionally share an issue with their colleagues if the are in the same organization. By the way, they don't have to share an issue with the entire organization.

now, yes, if an agent was to change the reporter from a customer belonging to Org A to a customer in Org B then the wrong folks are going to potentially get updated on issues outside their Org. But in my mind that is a human error just like sending an email to the wrong person(s).

Mark Segall
Community Champion
February 18, 2022

To add to Jack's comment, if you don't trust the agents, you can always deny "Modify Reporter" permission in the permission scheme.

Like Viktor Karlsson likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events