-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(NotificationMailling): add 'References' header for mail grouping (Gmail) #14296
feat(NotificationMailling): add 'References' header for mail grouping (Gmail) #14296
Conversation
Waiting for customer validation. |
bfed8d9
to
02d2d31
Compare
install/migrations/update_10.0.6_to_10.0.7/queuednotification.php
Outdated
Show resolved
Hide resolved
04df93c
to
5bbb79b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made some tests, and grouping notifications for a same item in Gmail requires additional changes. Indeed, mails are grouped only if subject is identical. I was able to achieve it on my GLPI instance by changing subject in Ticket notification template translation this way:
-##ticket.action## ##ticket.title##
+##ticket.title##
We should so probably consider changing default subjects of our notifications to make them identical across events. I guess such change could be made in another PR.
Anyway current PR will also prevent grouping of some notifications that are currently grouped. For instance:
passwordexpires
andpasswordforget
for a sameUser
will not be grouped anymore, and that may be considered as an expected behaviour;plugin_formcreator_form_created
,plugin_formcreator_need_validation
,plugin_formcreator_accepted
andplugin_formcreator_refused
for a samePluginFormcreatorFormAnswer
will not be grouped anymore, and it will probably be considered as a bug.
So, as it will change grouping behaviour on plugin notification, that could be considered as a BC-break, we should probably made such a change in main branch only, and produce a documentation to explain how to override the CommonDBTM::getMessageReferenceEvent()
to customize grouping.
Also, we should review all core notifications to ensure that we are correctly define grouping rules where it is necessary.
I put it as a draft, as we need to decide what should and what should not be done to finalize this PR.
50796fb
to
f10b946
Compare
f10b946
to
c630c9b
Compare
As discussed IRL with @orthagh, we can merge this PR in 10.0/bugfixes branch. Until now, all notifications related to the same object, depending on email client, were either always separated (in Gmail for instance), either always grouped (in Thunderbird for instance). With proposed changes, grouping instructions should premit to harmonize behaviour between email clients. This will change the way messages are grouped a bit, but it would not prevent end-users from receiving notifications, so the change is therefore acceptable in 10.0/bugfixes branch. Note: As far as I understand, according to RFC2822, Gmail should group messages into a same thread even if subjects are different, but it is actually not the case. So, we still have to review default notification subjects, but it could be done in another PR. |
From
Gmail
, mail grouping does not work.To work GLPI notification need :
https://workspaceupdates.googleblog.com/2019/03/threading-changes-in-gmail-conversation-view.html
this PR add custom header
References
with<GLPI-%uuid-%itemtype-%items_id>