JIRA is now available as three separate applications, JIRA Software, JIRA Service Desk, and JIRA Core. For more information on administering these applications, refer to the Administering JIRA Applications documentation.

JIRA as a Support System

Redirection notice

This page will redirect to SERVICEDESK:JIRA Service Desk Documentation .

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

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

4 Archived comments

  1. User avatar

    Craig Pugsley

    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)

    10 Dec 2007
  2. User avatar

    Bradley Wagner

    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.

    13 Jun 2008
    1. User avatar

      Andrew Myers [Atlassian]

      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]

      22 May 2009
  3. User avatar

    Julie d'Antin

    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

    20 Sep 2013
Powered by Confluence and Scroll Viewport