JEMH: treat servicedesk customers as non-jira

I want to use JEHM to send servicedesk notifications.

We have several user groups allowed to create tickets in the customer portal without JIRA license

What I want to achieve: less notifications for customers and more for agents. Is this possible?

I thought this would work but it doesn't work as expected
The customer gets notifications twice. One from the jira-user mapping and one from the non-jira settings. I see the difference because one sends html and the other one text notifications.

JIRA notifications

  • group restrictions: servicedesk-customer (I need several groups but this fields does not support that aparently)
  • group restriction condition: groupMemberIsNonJira: treat user with group as non-JIRA

 

 

non-jira.pngjira.png

 

 

 

1 answer

This widget could not be displayed.

Hi Charlie,

Unfortunately this behaviour is a bug.

The ticket for this bug can be found here: JEMH-5145.

For updates regarding this bug be sure to check and vote on the JEMH-5145 ticket.

Cheers,

Rhys

Hi Rhys. Thanks for this clarification.

When I use html for both configurations I don't get the double notifications so that's alright.

 

But as a customer I'm also getting notifications I did not configure for non-JIRA users. "Issue updated" for example. I only want agents to get them.
Should I remove the reporter from the notification scheme? I thought it would work by treating them as non-jira

update: when I don't use the "group restriction condition" and treat them as JIRA users this way the SD customer gets notifications of internal comments

Hi Charlie,

Regarding the internal comments being sent to customers, does your Agent have the Service Desk Customer project role? If so then a notification of their comment will be sent to everyone involved in the issue (JIRA or non-JIRA), ensure that your Agents do not have this role.

If the comment receiver is a customer, ensure that the customer does not have the Service Desk Agent user permission or membership of the Service Desk Team or Administrators role.

Cheers,

Rhys

Hi Rhys

 

Our customer roles are based on several Active Directory groups containing 2000+ users.
Most agents also belong to these groups. That means we can't simply remove agents from the customer role. Every agent is also a customer

The customer I am testing with is not an agent

Is this behavior expected? It does not sound logical to me

Andy Brook Community Champion Jan 19, 2017

Hi Charlie,

You bring up an excellent real world scenario!

Let me first address the problem you raise:

What I want to achieve: less notifications for customers and more for agents. Is this possible?

I thought this would work but it doesn't work as expected
The customer gets notifications twice. One from the jira-user mapping and one from the non-jira settings. I see the difference because one sends html and the other one text notifications.

Yes it is (with caveats).  The JEMH Event Listener Project Mappings has JIRA and Non-JIRA settings.  Currently, the JIRA side has a pair of Group Restriction fields, that historically allowed users with a given group membership to be treated as non-JIRA, in this way, those users would have notifications for Events only enabled on the Non-JIRA notification side, and the remaining JIRA users will get the full set.  

There is a Condition value noGroups OrGroupMemberNonJira which neatly matches JSD portal users, however, doesn't work well if your users have other groups, are interactive in other JIRA projects.  This scenario brings up the need for a new Rule option that allows this decision to be made on Roles, I've added JEMH-5296 and will get this worked on soon.

 

Current Situation:

JEMH is constantly evolving to do the right thing for JSD notifications (its been a challenge!), historically we've had to derive whether a notification should be considered Private as JSD is not deterministic in setting the Private nature before it fires the IssueEvent that JEMH responds to, see https://jira.atlassian.com/browse/JSD-3533 for more on that.  The approach by JEMH has changed a little, to workaround this bug, so we know can guarantee that when the Notification Scheme is resolved to recipients we can be sure whether a Comment is public or not, and take action as needed.

The current behaviour does what we expect, in that:

IF the comment is Private THEN we remove anon non-Agents from the NotificaitonScheme derived recipient list.  The result is right outcome AFAWCT, if you believe otherwise, please log a support case with specific details!

Is your JEMH version current?  As you can tell, the implementation has varied over time as we tried to improve the solution for the best possible outcome.

Hi Rhys

Thanks for creating that improvement. I'll keep an eye on it. In the meantime the project can work with the default SD notifications. I disabled the JEMH event listener.

When I create a private comment the customer who has no JIRA license in use and belongs to one of the groups in the customer role gets the notification as well.

I'll test this better with more details and create a support ticket if necessary

 

thanks!
Charlie

forgot to mention the version: v2.0.15 (latest)

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted 5 hours ago in Jira

Atlassian Research Workshop opportunity on Sep. 28th in Austin, TX

We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...

23 views 1 2
Join discussion

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