-
Bug
-
Resolution: Fixed
-
Medium
-
None
NOTE: This bug report is for JIRA Service Desk Cloud. Using JIRA Service Desk Server? See the corresponding bug report.
Basically there has several customer complaining on the notification stop working after they upgraded to the latest version 1.2.0.2. However if they disable/de-activate the service desk plugin, notification working fine as usual.
Steps to reproduce:
- Create a test project and test issue
- Associate it with service desk
- Perform any event (add comment, change assignee..) that will trigger the notification
- Check the mail queue in JIRA
Unexpected result:
Mail queue is empty and there is no notification being send out
Expected result:
Mail queue should consist of pending notifications to be send out to the respective party.
If you disable the service desk plugin, everything works fine which means notification are being send out as per normal.
Downgrade to version 1.1.6 using the guide Downgrading an Add-on to an Earlier Version. Since Service Desk is implemented as an add-on, the procedure is the same as UPM.
- Discovered while testing
-
JSDCLOUD-72 Disable Notifications per Project; Use JIRA's default notification rules and templates
- Closed
- is duplicated by
-
JSDCLOUD-387 No notifications for issues not created via Service Desk
-
- Closed
-
- is related to
-
JSDCLOUD-446 Reporter does not receive notifications when creating issues without using ServiceDesk customer portal
-
- Closed
-
-
JSDSERVER-323 notification not working in version 1.2.0
-
- Closed
-
[JSDCLOUD-323] notification not working in version 1.2.0
Rick, where is this located? I do not know where you are talking about finding that config file.
I have the system setup so that the reporter should be getting an email when an issue is being commented on.
Hi Nick,
Can you verify that the system's configurations expect the notification to send?
/secure/admin/NotificationHelperAdmin.jspa
-Rick
Hello, I cannot get the notifications to send out to customers when a comment is generated unless the customer is a part of the Service Desk Team. This is the process that the tickets get worked.
The ticket is received through the email catch.
A ticket is created and a notification is received by the Team and the Ticket Creator.
A comment is added or a transition in the ticket and no email is sent out to the Reporter, Unless the reporter is also a watcher. But to be a watcher they would also have to be on the Service desk Team so that is Not desirable.
We are running JIRA 6.1.3 And Service Desk 1.2.5
Please Help.
Hello,
we are also affected with this Issue after upgrade to Service Desk 1.2.4.
Our current setup is JIRA 6.1.7 with SD 1.2.4.
rick6, just to let you know, 1.2.4 is being deployed to OnDemand today.
Can confirm that notifications to reporters are now working! Thanks Gilmore and everybody!
rick6, we are working on getting 1.2.4 into OnDemand very soon.
vdung - "If someone else makes changes, Reporter will receive notifications." – This is what is now working in 1.2.4 that wasn't working in 1.2.0 or 1.2.1 (as you mentioned at the end of your comment). This is the same problem mentioned by helmich.douma1 and summarised by rick6 above:
In short, the permissions and notification helpers indicate that this user (assigned to the "Service Desk Customer" project role) should be receiving emails. However, tests show that it only works when that user is assigned to the "Service Desk Team" project role, which is not desirable for many reasons.
As for the other behaviour, our documentation states:
Customers receive email notifications when they raise a request through the Customer Portal, when their request is resolved, when another user comments on their request, and when there is a change in the 'status name'."
This was also mentioned by pcherukuri earlier in this comment thread. According to both the documentation and description field of this issue, the problem is fixed.
Finally, a message to all watchers of this issue.
The comment thread of this issue has become rather confusing, with multiple use cases and scenarios mixed in together. We believe we have fixed the problem as it was initially described. If you believe this is not the case, we encourage you to raise a new bug report detailing the exact scenarios where it is/isn't working, such as:
- Whether the issue was created via the Service Desk customer portal, or through normal JIRA in a Service Desk-enabled project.
- Whether the action that generated the notification was performed by the reporter or a different user
- Whether the action that generated the notification was performed in the Service Desk customer portal, or in JIRA
- Whether the user to receive the notification was a watcher on the issue
Cheers,
Gilmore
Hello Gilmore,
I'm an on-demand user and would love to test this out. When do releases typically roll out? Or will we need to wait until 1.3.x? Currently we're at 1.2.0.2.
-Rick
Hello gdavidson@atlassian.com,
Just conducted a quick test on JIRA 6.2.1 with ServiceDesk 1.2.4:
- Reporter still won't receive notifications if he/she's the one who makes changes, even though Notify me is enabled.
- If someone else makes changes, Reporter will receive notifications.
So please clarify if this is an expected behavior. Even if it's expected behavior, users might not expect it since they have purposely enabled Notify me. Please justify.
Other than that, I think you may need to test with JIRA 6.2. I conducted a test earlier with ServiceDesk 1.2.1 in JIRA 6.2 and discovered that Reporter will not receive any notifications no matter who makes changes.
Hello gdavidson@atlassian.com,
could you explain what behaviors were exactly resolved?
A quick test on a local instance shows the same behavior which is described here and on my SAC issue.
Regards,
Tim
Hi all,
The fix for this issue was originally due to be released in 1.2.3, but we discovered a late issue in that build and had to cancel the release.
However, we have now released version 1.2.4 to marketplace.atlassian.com, which contains this fix.
Cheers,
Gilmore
Hopefully this will be fixed in 1.2.2 which is the next version, really hoping this can be fixed as soon as possible.
Hi Justus,
Thanks for the clarification! Also, I've noticed that this is set to "fixed in 1.2.3" (woohoo!) as noted here https://jira.atlassian.com/browse/JSD/fixforversion/40195/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel. When is that scheduled to roll out for OnDemand users?
Rick,
The Resolution doesn't mean much for our internal workflow, which is why it didn't get updated. That said, since it appeared to cause some confusion, I've set it to Incomplete to signal that the Status is "In Progress".
Given that this is set back to "in progress", does it make sense to set the resolution back to "unresolved"?
Hi @Helmich,
That permission is already there by default (in my particular setup). See http://screencast.com/t/B7nQYk1ffDD
We also verified (with the notification helper) that the user I mentioned in my previous post (https://jira.atlassian.com/browse/JSD-323?focusedCommentId=580983&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-580983) should be getting emails. Given what others have stated, it seems like the configurations are being set correctly, but Service Desk 1.2.x introduced a bug that broke this functionality, which was working previously (see https://jira.atlassian.com/browse/JSD-323?focusedCommentId=581023&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-581023).
I'll be very happy to see a resolution on this one!
-Rick
Helmich,
Can you show screenshot of what you are referring to as a temporary fix please?
Thanks!
Nate
give "Project Role (Service Desk Customers)" only browse project permission
use "Service Desk Customer - Portal Access" for browse, create, comment etc.
and notifications will be send.
Hello pcherukuri,
sorry for the late reply.
I explained the behaviour within my SAC reqeust SDS-386 which i have linked. I have attached a video where you see the problem and see whats happen (Outlook, JIRA Mail Queue, Update process, Create issue process) with SD 1.1.6 and SD 1.2.0
Andy Nguyen explained the main problem to.
Customers receive email notifications when they raise a request through the Customer Portal, when their request is resolved, when another user comments on their request, and when there is a change in the 'status name'.
That is correct but the problem which is described in this issue works without any problems in Service Desk 1.1.6.
Service Desk 1.2 Breaks this functionality.
Regards,
Tim
We have a support request open and I've sent logs and backups so hopefully they have some good data to look at to test this out and get it fixed.
I'm experiencing a similar issue. Here are the steps and tests I went through.
Background:
- We're using JIRA OnDemand with Agile and with Service Desk.
- We created a default Service Desk for project XYZ.
- We are using the default permission schema created by Service Desk.
- We created a user (i.e. test-client) and removed the JIRA "users" and "jira-users" role so they didn't have access to all the back end tickets.
- We assigned the test-client user to the "Service Desk Customers" project role.
Tests:
- When the user is assigned to "Service Desk Customers", they only get the initial email but NO followup emails when a comment is added.
- When a user is assigned to "Service Desk Team", they will get the initial email plus an email when a comment is added.
Earlier in this thread, Helmich stated that only users with admin privileges receive notifications. However, when using the default notification schema, the reporter is almost always set to receive a notification for items like issue creation, issue comments, etc. In fact, you can even verify this by visiting the notification helper /secure/admin/NotificationHelperAdmin.jspa. Here's an example: http://screencast.com/t/8oLQ3E1ZDmeK
In short, the permissions and notification helpers indicate that this user (assigned to the "Service Desk Customer" project role) should be receiving emails. However, tests show that it only works when that user is assigned to the "Service Desk Team" project role, which is not desirable for many reasons.
Hi everyone,
I just recorded a quick screencast that demonstrates the problem. I created a local test user that only has customer level access to service desk and created an issue as them. They got the initial email but none of the subsequent ones. I also show where the error messages are being created. We are running Jira 6.2 and Service Desk 1.2.1. I really hope this helps you all get to the bottom of this. It most certainly is still a problem and has not been resolved.
http://www.screencast.com/t/tDOzsGsP
E.L.
Service Desk Customers receive email notifications when they raise a request through the Customer Portal,
Service Desk Customers DON'T receive email notifications when their request is resolved, when another user comments on their request, and when there is a change in the 'status name'.
only users with administrator rights receive all notifications..
JIRA v6.2
JSD v1.2.1
That link does not work, can anyone else view it?
Our customers who we have given service desk access to are not receiving any notifications at all.
Hey te@airberlin.com,
I went through 2 of your above comments and I think I understand the problem you notice. Let me try to summarize it in steps for clarity:
Issue you are noticing is:
1. Helpdesk executive creates a request through customer portal on behalf of the customer.
2. They receive Service Desk notification.
3. They update the issue either through comments/edit/transitions.
4. They do not receive Service Desk notification. _Even though they have enabled 'notify on my own actions' and 'they are the reporter' _
The way Service Desk notifications work is 'they do not get generated if the changes are made by the reporter themselves'.
It is well documented here:
Customers receive email notifications when they raise a request through the Customer Portal, when their request is resolved, when *another user comments* on their request, and when there is a change in the 'status name'.
Hope that helps!
Thanks,
Service Desk Team
It is not only permission based. In our main IT Service Desk project we doesn't have enabled the new SD 1.2 restrictions.
If an Helpdesk employee created an issue and he is the reporter than he doesn't receive a notification and notify on my own actions is enabled. And he has the permission. Also if a customer stands in a user picker it will work.
Only the reporter will not notified.
@nbritton - Yes! That's the same behavior we have observed. That's why we thought all was well when we first tested it. I then created a test user with only customer level permissions to test the emails. I created an issue as the test user and got the first email but none of the following ones (comments, etc.)
From my end, this appears to be permissions based. Anyone that is a member of Administrators or Service Desk Team will receive all notifications. Anyone in the service desk customers group will not.
For me it is also not working. The situation is the same.
The Reporter doesn't get any notification it the issue was not created within the service desk portal.
What is the situation if the Helpdesk created the issue for the customer.
Disable the module what sd5 says, will end in duplicate notifications (short testing) one Service Desk notification and one classic JIRA notification.
The usage of notifications templates (Service Desk / JIRA) is also really strange. Played a little bit and looked at the mail queue.
The first issue created notification has in booth scenarios the Service Desk template when the issue is created from a Service Desk. The difference comes when there is interaction by support (comment / workflow).
Restrict Customer to portal only | Template |
---|---|
![]() |
JIRA template |
![]() |
Service Desk template |
Regards,
Tim
i came here just following the support request, now i've to open another one?
Hi,
So, we investigated the issue and couple of scenarios that we tested are:
1. Service Desk notifications get sent when a request from customer portal is raised.
2. Service Desk notifications get sent when a request is updated within JIRA.
3. JIRA Notifications for a 'Service Desk' project are sent.
If the issue with notifications that you are noticing is for a very specific scenario then I would strongly recommend raising a request with https://support.atlassian.com. Same login credentials will apply.
Thanks,
Service Desk Team
Hi,
We have re-opened the issue and our team is currently investigating it.
Thanks,
Service Desk Team
We are also getting the same error message that Clyde mentioned after upgrading to 1.2.1. I don't believe this has been fixed.
Does not seem to be fixed in 1.2.1, still getting the following in the log. Able to post a comment on an issue, an email is visible in the mail queue, then it disappears but no mail actually goes out.
2014-03-14 13:28:34,559 http-bio-206.252.132.32-80-exec-16 WARN user 808x4406x1 176ervn 68.199.34.58 /secure/WorkflowUIDispatcher.jspa [servicedesk.internal.notifications.UserNotificationServiceImpl] Cannot retrieve request type for issue KEY-47 with key lodge-client-help in context of 'key/lodge-client-help'
2014-03-14 13:28:39,589 http-bio-206.252.132.32-80-exec-10 WARN user 808x4418x1 176ervn 68.199.34.58 /secure/CommentAssignIssue!default.jspa [web.action.issue.CommentAssignIssue] The i18n key in property 'jira.i18n.description' for this transition does not contain a valid i18n key.
2014-03-14 13:28:48,053 http-bio-206.252.132.32-80-exec-10 WARN user 808x4420x1 176ervn 68.199.34.58 /secure/CommentAssignIssue.jspa [servicedesk.internal.notifications.UserNotificationServiceImpl] Cannot retrieve request type for issue KEY-47 with key lodge-client-help in context of 'key/lodge-client-help'
I think it was a issue in the notification-filter-impl module because when I disable it I get the functionality back. 1.2.1 did not fix the issue, so this is the workaround that works for me. I run the service desk without the notification enabled for all service desks.
Hi everyone,
Service Desk 1.2.1 has just been released containing a fix for this issue. It is available now for download on marketplace.atlassian.com, and we will give an update on this issue once it is available in OnDemand.
Cheers,
Gilmore
Any news when this is to be resolved. Not even the reporter of an issue gets notifications on our system. I'v just upgraded our licence fee to a phenomenal amount and migrated all our customers over to Service Desk to now find this out. Really not impressed.
seems working for me. (upgraded jira to 6.2)
seems wrong
still not working and now i get no error
I've found that this is not fixed with 6.2 despite the above message, I event tried creating a new service desk project and still have the same problem.
I did notice different results from the original report - I can see the messages in the mail queue, it appears that when they send is the point where it fails. For every message sent, I see messages like the following:
2014-03-08 15:48:50,959 http-bio-206.252.132.34-8090-exec-20 WARN user 948x1099x1 1a0o97k 68.199.34.58 /secure/AjaxIssueAction.jspa [servicedesk.internal.notifications.UserNotificationServiceImpl] Cannot retrieve request type for issue KEY-1 with key get-it-help in context of 'key/get-it-help' 2014-03-08 15:48:53,037 http-bio-206.252.132.34-8090-exec-1 WARN user 948x1109x1 1a0o97k 68.199.34.58 /secure/WorkflowUIDispatcher.jspa [servicedesk.internal.notifications.UserNotificationServiceImpl] Cannot retrieve request type for issue KEY-1 with key get-it-help in context of 'key/get-it-help' 2014-03-08 15:48:54,986 http-bio-206.252.132.34-8090-exec-1 WARN user 948x1118x1 1a0o97k 68.199.34.58 /secure/CommentAssignIssue!default.jspa [web.action.issue.CommentAssignIssue] The i18n key in property 'jira.i18n.description' for this transition does not contain a valid i18n key. 2014-03-08 15:49:00,367 http-bio-206.252.132.34-8090-exec-1 WARN user 949x1120x1 1a0o97k 68.199.34.58 /secure/CommentAssignIssue.jspa [servicedesk.internal.notifications.UserNotificationServiceImpl] Cannot retrieve request type for issue KEY-1 with key get-it-help in context of 'key/get-it-help'
I did find the notification for the initial creation seems to work, it is everything else after that that doesn't send.
In my case, it seems that only the Reporter will not be notified. In details:
- The Reporter of an issue will not receive notifications if:
- He is not the Assignee of the same issue
- He is not one of the Watchers of the same issue
- The project is associated with ServiceDesk
Assuming that notifications are configured to be sent to Reporter, Current Assignee, and All Watchers
- The Reporter will still be notified if:
- He is also the Assignee of the same issue
- He is one of the Watchers of the same issue
- The project is not associated with ServiceDesk
So a workaround is to ask the Reporter to add himself as a Watcher of the issue he reported.
ServiceDesk 1.1.6 is not affected. However, if you'd like to downgrade, take notice of this bug (with suggested workarounds):
All of these issues affect JIRA 6.1.5 and 6.1.7 but are fixed in JIRA 6.2. If you upgrade JIRA to 6.2, you can use the latest version of ServiceDesk without problem, not even when you choose to uninstall it.
Is there any status on this getting fixed, we definitely don't want to downgrade and using the default Jira notifications isn't ideal, so we'd love to know if this is going to be released soon. Thanks!
I've played a little bit and i found a better workaround than to downgrade.
When you disable the special service desk notification by a database query for the needed projects, then the notifications for the reporter will send again.
The query is inside JSD-72.
The problem also affects projects where Service Desk functionality was shortly enabled and is now disabled.
Does someone with the same notification error have the latest jira installed?
if i downgrade i recieve an error every time i try to accesss something. which is the correct procedure?
You aren't, but I already downgraded to 1.1.6 version as a workaround.
nicholas.overton can you please raise a support case on support.atlassian.com and we can look at helping you out further. This is for tracking a specific bug and it sounds like you're running things a bit differently than to what's described here. Thanks.
David Currie
Atlassian Support