Some mails from customers are added as internal comments

[Dominik Kaźmierski]

Hello Atlassian Community!

I am experiencing an issue with incoming emails from our customers. Specifically:

1. Some emails are added as internal comments, even though our permission scheme does not allow customers to create internal comments.
2. After such emails are processed, I often receive an additional comment saying: "Reporter does not have permission to create attachments." However, our permission scheme explicitly allows reporters to create attachments.

See the screenshot below:

Additionally, I’ve noticed another issue related to mentions:
When a customer is mentioned in a comment and replies to that mention via email, their response is rejected by the mail handler with the message: "User (...) does not have permission to comment on an issue in project (...)." This behavior also contradicts our permission scheme.

Do I need to add customers as request participants to resolve these issues?

Should I escalate these problems to Atlassian Support?

Thanks for your help!

[Marc - Devoteam]

Hi @Dominik Kaźmierski 

Are there any automation rules active, that might trigger this action.

The point @Jack Brickey makes is also something to check.

What does your permission scheme look like?

On the attachment create permission, is the option Service Project Customer - Portal Access provided.

This is required for non Jira users (customers)

[Dominik Kaźmierski]

Hi @Marc - Devoteam
Thank You for your response.

We do not have any automation rules related to attachments or the visibility of comments. In the issue shown in the screenshot attached to my question, there are only three automation rules in total:

1. Copying people from watchers to request participants (triggered after the first transition).
2. Assigning a value to one custom field based on the value of another custom field (also triggered after the first transition).
3. Changing the issue status from "Pending" to "Work in Progress" after receiving a comment from the request creator. (This rule has not been triggered.)

I have attached screenshots of the permission scheme in my response to Jack’s comment below.

[Marc - Devoteam]

Hi @Dominik Kaźmierski 

Any rule action on the project can have in the config an action to set this, it's best to check all rules.

No global rules or rules active in the legacy automation section?

[Dominik Kaźmierski]

Hello @Marc - Devoteam 
I double checked all of the automation rules and none of them have any action related to editing comment from any user.

[Jack Brickey]

I wonder if some of your customers also have Jira user licenses and have browse/comment permissions.

[Dominik Kaźmierski]

Hi Jack, thanks for answer!
Person from attached screenshot is a customer without a paid license:

His first mail reply was added as 'Reply to a customer' comment and the next two replies were added as 'Internal notes' (see the screenshot attached in my question).

As a customer he has both browse and comment permissions (Service Project Customer - Portal Access):

The same thing goes to the Attachments permissions:

[Jack Brickey]

Hi @Dominik Kaźmierski , can you please verify that the email address being used by the customer is in fact configured in your project and that a request type is being assigned to it? project settings > channels > email 

[Dominik Kaźmierski]

Hi @Jack Brickey 

All customers are added to the project via the jira-servicemanagement-customers group, allowing us to avoid manually adding over 1000 users. The user in question is part of this group and has a valid email address.

A request type is assigned to emails, and many other emails are correctly added as comments.

I’ve checked the logs and noticed that only the first comment from the user, which was added as a normal comment, appears in the logs. There is no record of the subsequent comments that were categorized as 'Internal notes.'

[Jack Brickey]

Hmmm, if you don't see the entry in the email log for a comment added then I suspect the entry is not made via the email channel. Are the customers using the portal for response? 

[Dominik Kaźmierski]

This user never logged in. He contacted us only via e-mail.

[Jack Brickey]

Scratching my head here. Is it possible that someone added an incoming mail handler under the System admin section using the reply email address for the JSM project? And just to rule it out, you are not using a third party email handler addon app?

you might need to open a support request so the can login and inspect.

[Dominik Kaźmierski]

We have Jira's default mail handler and we are not using any third party addons for mails. I think it is the best to open a support request in this case. Thank you!

[Jack Brickey]

Please report back on findings. I am curious.

[Dominik Kaźmierski]

Hello @Jack Brickey , I think I found the solution.

It turns out that the problem was caused by several factors:

1. Emails from some customers were being categorized as "internal notes" due to settings in the permission scheme. This was because the "Add Comment" permission should only include "Service Project Customer - Portal Access," but I also had the "jira-servicemanagement-customers" group added. Removing this group from the permissions resolved the issue. There is a known BUG that causes emails to be redirected to the Global Mail Handler instead of the JSM Projects Incoming Mail (https://jira.atlassian.com/browse/JRACLOUD-84127) when a customer group is added to the permission scheme.

2. The issue above likely also caused attachments from those emails to be removed. Since the messages were intercepted by the Global Mail Handler, JSM interpreted this as the user not having permissions to add attachments.

3. Some email replies from users were being blocked by the mail handler because we had configured two email addresses — one for customers (Project settings > Channels & self service > Email) and another for all notifications sent from JSM (Project settings > Notifications > Internal notifications). It turned out that customers were receiving notifications about changes in tickets, comments being added, etc., from an email address not accessible to them. So, when they chose to reply to the notification email, they were responding to the wrong mailbox. I updated the email addresses, and this resolved the issue.

Over the past few days, I have been testing these solutions, and so far, none of the problems have reoccurred.