Can I use JIRA Service Desk together with JEMH ?

[Peter Straub]

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)?

[Andy Brook]

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): 

• https://confluence.atlassian.com/display/SERVICEDESK/JIRA+Service+Desk+permissions
  

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.

[Peter Straub]

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]

> 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.

[Peter Straub]

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]

> 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.

[Peter Straub]

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]

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.

[Peter Straub]

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]

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?