Can I use JIRA Service Desk together with JEMH ?

We use JIRA Service Desk, but don't use the email functionality.

I'd like to use JEMH for system integration purposes (Issues created by a customer system)

How do I resolve the permission conflicts (Customer Portal vs. customer system)?

1 answer

0 votes
Andy Brook Community Champion Jun 12, 2015

Hi Peter,

I'd like to use JEMH for system integration purposes (Issues created by a customer system)

Yep.  JEMH has many capabilities for ingesting remote system mails, threading followups, extracting content for storage in custom fields, translating foreign supplied values into 'JIRA' equivalent values, #allthethings !

How do I resolve the permission conflicts (Customer Portal vs. customer system)?

One must be careful with permissions, review the following, compare with JEMH 'configuration' that could affect fields (eg assignee): 

JSD will 'veto' your JIRA permission scheme where it is enabled, for specific operations.  This is intentional and is not something JEMH can work around.

If your remote participants are JSD portal users or JIRA users

What we have found is that if you are careful with configuration and avoid specific actions like setting an assignee (leaving JIRA to 'fill in the blanks') this seems to work nicely with project default assignee, and I think, component assignee (when the sender of a mail is a JIRA account holder (regardless of type) they are used as the context for issue creation, and all related settings, including, configuration driven assignees - something that JSD v2 Agents are only permitted to do.

If your remote participants are email only users, the JEMH default user can be added into the related project Agent role, then, all expected configuration will work just fine.

Currently, we plan to assign the remote participants as JIRA users. New tickets will be unassigned upon creation. The JSD Mail Handler will be disabled. For us it is important that the Service Desk notifications are handled the same way by JEMH as with the Standard JIRA Mail Handler. Do you see any conflicts?

Andy Brook Community Champion Jun 14, 2015

> Currently, we plan to assign the remote participants as JIRA users. New tickets will be unassigned upon creation. The JSD Mail Handler will be disabled. This means (a) JEMH will auto create users in some way, or (b) that JEMH will treat these users as email only? > For us it is important that the Service Desk notifications are handled the same way by JEMH as with the Standard JIRA Mail Handler. If users are created by JEMH (and they are given group memberships that appear in the Project 'Customer' Role) then they can be notified by JSD. If you want to use JEMH email-only user support, it wont be possible to drive notifications to them from JSD, but, JEMH can create notifications specifically for just email users. The definitions of the mail content for JSD are defined within JSD (its an addon). JEMH definitions are not currently replicating its look and feel, though this is planned for future.

The primary use case for JEMH is creating complete JIRA issues out of incoming emails. There will be only one remote user per customer project that will be handled by JEMH. I thought of creating this specific user manually. It is very likely that this user is email - only, i.e. that it will never create issues via the JSD customer portal, but that it has the permission to do so. I'd prefer to work with the JSD notifications after having created the issue. Is this possible? You write that the users have to be created by JEMH. Is this a pre-requisite in order to use JEMH together with JSD properly?

Andy Brook Community Champion Jun 16, 2015

> The primary use case for JEMH is creating complete JIRA issues out of incoming emails. Yes that's the core function of JEMH. > There will be only one remote user per customer project that will be handled by JEMH. I thought of creating this specific user manually. The issue is that these users may not be able to 'see' issues that are created for email only users. > It is very likely that this user is email - only, i.e. that it will never create issues via the JSD customer portal, but that it has the permission to do so. JSD Portal users 'are' JIRA account holders, but they cannot login to JIRA interactively, just JSD's front end. Email users have no 'permission' as such. An account needs to be provisioned, that is somehow in the JSD Role: Customer (eg via group membership) :- > You write that the users have to be created by JEMH. Is this a pre-requisite in order to use JEMH together with JSD properly? It depends. If your remote senders don't need to log into JSD to see these issues, and you're using JSD for a management purposes, then no user needs to be created, you can stick with the email-user notifications handled by JEMH. > I'd prefer to work with the JSD notifications after having created the issue. Is this possible? Not for email only users, which is a capability JEMH provides. If you want JSD to handle notifications, JEMH needs to auto-create user 'accounts', and allocate groups to give them access to your Project. Currently, group allocation is at the Profile level, so if you want to do this many times over, with different groups, that area would need to be enhanced. With email-only users, JEMH will take care of notifyications to that set of users. JSD will continue to notify JIRA account holders.

When you say that email users don't 'see' issues, you mean that these issues are not visible when using the Customer Portal? This is true for any user of this customer? In our case, there will be this above mentioned remote user (customer incident management system) and there will be 'human users' that have access via Customer Portal and are also allowed to raise incidents and other service requests. Do these users see the issues created by the remote user?

Andy Brook Community Champion Jun 17, 2015

If an issue is not created with a valid Customer Request Type, it will not appear in the JSD Portal for Agents. > Do these users see the issues created by the remote user? Do you mean does userX see userY issues? no, it should be that issue security keeps issues restricted to the Reporter, rather than a group or wider access.

Thanks for your valuable information. I've created a JIRA user as 'remote user'. This user is a "Collaborator" within JSD and therefore a "Customer" too. This user has the 'full' permissions, i.e. to create and comment issues. I successfully created an ticket by sending an email on behalf of this user. The JSD agent edited it and added some "request participants". Thus Customer portal users are able to see what's happening with this incident. The 'remote user' gets all the notifications that it should receive. (Standard JSD notification scheme). There is one thing that's not working properly: The 'remote user' cannot comment the issue by replying to the notifications.

Andy Brook Community Champion Jul 19, 2015

The 'default reporter' needs to be an Agent / Collaborator in order to edit the issue and more. Email users have their comments added 'under' that user, without correct role memberships, JSD will deny a 'standard' user permission to work on the issue?

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

248 views 0 11
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot