Tuesday, November 25, 2014

Atlassian Jira Service Desk assign an issue to Jira User workaround.


Issue:
Atlassian Service Desk does not allow you to assign an issue to a Jira User or Collaborator without making them Agents. For me, Agents and Jira Users have very different roles. Agents own the work flow and process of the issues, the assignment, and the communication with the customer. Jira Users are the dev/support teams who work to resolve the issues, and sometimes provide additional feed back.

Specifications:
OnDemand
Jira - Version 6.4
Jira Service Desk Add On - Version 2.2

Solution:
While the entire Atlassian suite is great, and I love it, this fairly new product still has some business model kinks to be worked out. Fortunately, given the extensive customizing capability, although complex, you can work around this issue until they ultimately listen to their user base and make the necessary updates.

For now, you can follow these steps...

1) Add a custom field using the user picker type. Applying to most screens and which ever projects you like. User JIRA administration, issues, custom fields.

2) Add an operation for your new custom field to all notification events under notification schemes. JIRA administration, issues, notifications schemes.

3) Make sure you set your service desk project roles accordingly. Under JIRA administration, projects, select project, roles.

4) Make sure to set the custom fields as required. Under JIRA adminstration, projects, fields, operations, required.

5) Make sure you add your custom fields to the service desk display views and queues.  Just under the services desk.

6) Make sure to remove your custom field from customer portal view, and auto default the value. Under services desk, settings tab, and edit fields on each of your request types if you have any.

7) Make sure you JIRA Service Desk notifications are currently on. Under add on's service desk configuration.

8) Non administrators do not have access to browse users via auto complete by default for the user picker custom fields you created.   Please make sure that the user from non-administrators group has the Browse Users permission, which is under global permissions.

9) For JIRA support users, create and save a new filter using the service desk project and your custom field set to current user so they can have quick access to their task from the homepage issue navigation menu.

10) To have it show up as a gadget on your global dashboard, similar to your "assigned to me" issues. Create a   Issues, Manage Filters, Edit the sharing permission.

I hope this helps a lot of you, it took me about 2 days to figure it all out.

Thanks,
John

9 comments:

  1. This workaround is only for 'assign'. But you still cant work on issue unless you are 'agent'. Correct?

    ReplyDelete
  2. This work around allows you to assign service desk issues to jira users where they can then work on, comment, and resolve those issues/tasks. This keeps the working support or dev roles and the customer success roles separate. Only the Agents can progress the issues/tasks back and forth between queues, distribute/manage the assignment, owning and driving successful resolution, and ultimately be the customer facing liaison.

    ReplyDelete
    Replies
    1. Can you elaborate on that? I have the problem that the devs need to be able to log work on an issue. Thus, they need to have the permission for "work on issues". I didn't try your workaround yet, but does it solve the "work on issues" problem?

      Delete
    2. Yes it solves the work on issues problem. You will have the actual "Service Desk" which the agents will have access to and a "Service Desk Jira Project" which the developers will have access to. Step 3 is where you provide developers access to the jira project and not the agents. The agents wouldn't have access to Jira, and the developers wouldn't have access to the service desk process and queues... as it should be. The agents can then assign developers to work on the issues, without them also being agents. The developers would then use the "Service Desk Jira project" as they would any other Jira project, with the addition that they can also comment both internally and externally to the customer.

      Delete
    3. how did you in this case avoid the default servicedesk permissions override ?

      Delete
  3. thank you for the workaround, sounds good.
    - you have 2 projects: a) "Service Desk" b) "Service Desk Jira Project". correct ?
    - are both projects running with the "Jira Service Desk Add On" or only a) ?
    - stay the issues unique or you have to move/clone them between a) and b) ?
    - can developers still log their work ?
    thank you for the clarification, julien

    ReplyDelete
    Replies
    1. - You can have as many Service Desk's as you like. Each time you create a service desk it also create a Jira Project, unless you choose a Jira Project that already exists. In my case I have just 1 Service Desk, and 1 related Service Desk Jira Project.
      - Yes you can have two Service Desks running with the add on, associated to two different projects.
      - Yes you can move the issue to another project in your system. It can be a service desk project or not, doesn't matter.
      - Yes developers can absolutely log their work, hence the reason for the work around.

      Delete
    2. thanx john. seems not to work by me: the service desk addon always override the permissions prevent the developer to work/logwork on the issue.

      Delete
    3. You may have just missed step 3. Make sure to set your roles for the jira project. Keep in mind your developers can only access the service desk jira project, and not the actual service desk that the agents use. Also check that the users/user groups you set for each role have the permissions you want, which you can find Under JIRA administration, projects, select project, permissions. But in this case you probably want to add your developers to the Collaborator role.

      Additionally in the same permission area on the top right corner is a "permission helper", which should help you identify any constraints on a users permissions if you get stuck again.

      Delete