-
Suggestion
-
Resolution: Low Engagement
-
None
-
None
-
1
-
1
-
NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.
Problem
If there is an existing user with the same email address as the one set up as the email channel, the user will be added as the Request Participant for every request created from the email.
This is as outlined in Adding request participants.
If you create or respond to a request via email, add a request participant's email address in the TO or CC fields. The participant receives an email notifying them that they have been added.
Suggestion
Do not add the user who has the same email address as the one set up as the email channel as a Request Participant automatically
Workaround
Disable the user in JIRA if the user account is not in use except for the email channel
This is similar to JSD-2298 but the scenario is creating a comment by replying to a notification email.
Scenario:
1. Reporter creates an issue via email. There is a customer user with the same email address as the one used by JSD to fetch emails.
2. Reporter receives a notification email from JSD.
3. Reporter replies to the notification email. This reply creates a comment.
4. The customer user with the same email address as the one used to fetch emails is added as a Request Participant.
Expected result: at step 4, do not add this user as a request participant. It is unnecessary. This user is no longer added as a request participant when the issue is first created via email, as per the issue noted above. I think the same handling should be applied when responding to email notifications.
I did raise this as a support issue, and was told the functionality is working as intended but that I could raise a feature request.
- is related to
-
JSDSERVER-2298 Users in the To field are added as participants when creating issue from email
-
- Closed
-
- relates to
-
- Closed
[JSDSERVER-3290] Do not add customer with same email address as the one used to fetch emails as a request participant.
| Resolution | Original: Won't Do [ 10000 ] | New: Low Engagement [ 10300 ] |
| Status | Original: Closed [ 6 ] | New: Closed [ 6 ] |
| Resolution | New: Won't Do [ 10000 ] | |
| Status | Original: Gathering Interest [ 11772 ] | New: Closed [ 6 ] |
| Workflow | Original: JAC Suggestion Workflow [ 3011786 ] | New: JAC Suggestion Workflow 3 [ 3650968 ] |
| UIS | New: 1 |
| Workflow | Original: Confluence Workflow - Public Facing v4 [ 2665176 ] | New: JAC Suggestion Workflow [ 3011786 ] |
| Support reference count | New: 1 |
| Workflow | Original: JSD Suggestion Workflow - TEMP [ 2323887 ] | New: Confluence Workflow - Public Facing v4 [ 2665176 ] |
| Status | Original: Open [ 1 ] | New: Gathering Interest [ 11772 ] |
| Workflow | Original: JSD Suggestion Workflow [ 2052504 ] | New: JSD Suggestion Workflow - TEMP [ 2323887 ] |
| Workflow | Original: JSD Suggestion Workflow - TEMP [ 2047812 ] | New: JSD Suggestion Workflow [ 2052504 ] |
Hi,
Thank you for raising and watching this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request.
This is an automated update triggered by low engagement with this suggestion (number of votes, number of watchers).
We hope you will appreciate our candid communication and our attempts to become more transparent about our priorities. You can read more about our approach to highly voted suggestions here, and how we prioritise what to implement here.
To learn more about our recent investments in Jira Service Management and Data Center, please check our public roadmap and our two dashboards containing recently resolved issues, and current work and future plans.
Regards,
Jira Service Management, Server & Data Center