Documentation for JIRA 6.3. Not using this? See below:
(JIRA 6.2.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

Oops! This page should redirect here: JIRA Service Desk Documentation.

4 Comments

  1. After going through this process ourselves recently for an internal proof-of-concept, we came upon a few stumbling blocks - the most confusing of which was creating the service to listen to new emails in a support mailbox and create (or comment) on new issues automatically from them.

    When creating the new 'com.atlassian.jira.service.services.imap.ImapService' service, it is important to configure the 'handler.params' value 'issuetype' correctly. We had created new issue types and removed all the old ones. Therefore, all the new issue types we had created had new ids associated to them, and it wasn't easy to determine what these new ids were. I'm not even sure you can, from the UI.

    In the end, we looked at a backup XML export for where it declares the issues types, and the ids were listed there.

    Overall, our proof-of-concept is going extremely well (wink)

  2. This is a great article. I can't believe its taken me this long to find it. I had one question with respect to permissions on 'tickets'.

    The articles states:

    Typically as an end user you can only see issues that you, or your company has raised.

    We employ the "Reporter only permission" strategy but have found it cumbersome when trying to allow other members of an organization to share tickets among them. Ideally we'd like everyone in an organization to be able see/modify any Tickets that anyone from their organization has created.

    Thinking about this logically, it makes sense that in order to do this all the users would would have to be a in group of some kind and that there would have to be a security level pertaining to that group, a permissions scheme for that group, or a separate project per group. None of these seem very scaleable as it would require creating new groups, permissions schemes, projects every time a new customer is signed.

    I did see one possible alternative to this on support.atlassian.com which involved adding specific users as CCs or participants on a particular issue. Can anyone shed any light on what exactly this feature does? I'm currently using JIRA 3.6.3 Enterprise and have not seen those fields before.

    1. Hi Bradley,

      The CC field is just a Multi User Picker custom field. We then add the CC field to the Notification Scheme for the project, and also to the Issue Security Level.

      Kind Regards,

      Andrew [Atlassian Support]

  3. Hi there! 

    I thought it would be useful to share the info here : At Valiantys, we have built a comprensive set of ITIL-based workflows for Service Desk applications of JIRA. They cover Incident, Problem and Change and can help you speed up your Service Desk deployment. You can freely download them from the Marketplace.

    Julie - Valiantys