The question I have is related to ServiceDesk specification.
My target is to have a functionality where my Customers (B2B) can log in, leave a ticket related to the problem they found or request for new functionality they would like to see. But the visibility from the portal side should be:
- user can see other users' cases as long as they belong to the same group/organisation
- users cannot seecases created by users outside of their group/organisation
At the same side from the backoffice (so operators' desk) I want to make sure that they are able to see all requests without the need of separating it to individual ServiceDesk instances.
I thought it could be solved by Project/Group, but it is not so straightforward when I look through ServiceDesk options.
Thus is it possible to create such setup in ServiceDesk? Or the only way is to have multiple ServiceDesks (individual ones for each group/organisation) - which then lacks a full visibility on the backoffice side (as the operator needs to switch between ServiceDesks to see what's in the pipeline)?
Here's how we "almost" achieved the same goal.
First up we created a group for each organisation we work with and added those groups to the Service Desk Customers role on the people tab of the single service desk project. Each user in the organisation have an individual user account created and added as a member of the respective organisational group. At this point individuals can log on and create requests in the Customer Portal - nothing new yet.
Next, we created a custom "Multiple Group Picker" field. This field was then added to the Jira Service Desk Screen for the project, and used to create an Issue Security Scheme with a security level that includes the Group Custom Field Value based on the newly created custom "Multiple Group Picker" field. The Security Level was set as default, and the Issue Security Scheme assigned to the project. At this point, if you manually populate the custom field of an issue, users can only see it if they too are a member of that group - again nothing new yet!
Next, we installed JIRA Automation plugin - https://marketplace.atlassian.com/1211836- and extended the plugin with a custom action - http://blogs.atlassian.com/2014/02/extending-jira-automation-plugin/. This custom action is triggered every time an issue is created via the service desk and automatically populates the custom "Multiple Group Picker" field based on the group membership of the reporter. In short, if a reporter is a member of an organisational group, that group is added to the custom "Multiple Group Picker" field. At this point, when an issue is created, the population of the custom field means that the security level of the issue is automatically set up without any interaction by the reporter of the service desk team - so far so good.
Now, here is the slight compromise. The customer portal does not provide any mechanism for a user to see other users issues. So our current workaround is achieved through Confluence. In summary, the organisational groups are given permissions to view a specific space in Confluence. Within that space, a page is created for each organisation and the page is restricted to the respective organisational group. This page contains a Jira macro which shows open issues where the custom field contains the organisational group. At this point, a user can access confluence and only see the page containing open issues for the organisation they are a member.
Finally, we modified the introduction text at the top of the customer portal to include a link to the Confluence space. At this point the user can now navigate to the open issues for their organisation from the Customer Portal.
It's not a perfect solution, but it just about works until
a) Atlassian implement the ability to view other requests from the customer portal or
b) we can find a way to add a link to the header of the customer portal which would display a custom servlet that shows the open issues for a users organisations.
If you are interested I can share the plugin we have created which provides the custom action for Jira Automation plugin...
@Lara Reedick - that's a pity, as our work around depends on the JIRA Automation Plugin which is only currently available on JIRA server. If you do migrate to JIRA server, I can happily supply our extension to the automation plugin which performs the task of setting the custom Multiple Group Picker field
One more question, I tried to do this with our account but the users who only have portal access cannot be assigned to groups. How did you work around this? Did you give all your customers access to Service Desk proper?
Users with restricted portal access cannot be added to groups
Also, did you investigate using this functionality at any point: https://developer.atlassian.com/jiradev/jira-applications/jira-service-desk/automation-rule-components#AutomationRuleComponents-Step2.Reviewandtweakthegeneratedstubcode
We wrote our solution based on the Automation plugin for JIRA - before any automation capability was added to JIRA Service Desk. So at this stage we are aware of the ability to extend the JSD automation rules, but have not done so yet, and may not do so because the current method allows for us to perform the same mechanism when the issue is created inside JIRA. In effect we can identify tickets by user groups which might be external companies or internal departments/teams.
Many thanks for your guidance - I will definitely give it a try as soon as all pieces are in place installed. I will keep in touch if any further questions appear.
However indeed - having a built-in possibility to have it in ServiceDesk would definitely be more than useful.
Hello Community 👋, I'm a product manager at Atlassian, looking at improving change management capabilities across our products. In particular, we're looking at bridging the gap between Dev & ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events