email notification-exclude requester if matches writer's email address

michal@1-2.pl · 2010-11-30 16:31:48

It is GLPI 0.78.1.

I would gladly see the way to configure the notification mechanism to achive such situation that if a person/automaton responds to a glpi notification and a new follow up is created the information about it is not send to that person/automaton.

I had such situation recently that my bussiness partner went for a short holliday. He set up an auto responder on the account that he normally used for GLPI correspondence. We ended up with tons of email messages as well as with tons of extra follow ups on many tickets.

The solution may be very simple: one has to deny sending a notification to requester if requester's email address equals writer's email address .

The problem is I don't see any possible way to set this up using current interface .
Regards,

Last edited by michal@1-2.pl (2010-11-30 16:33:04)

sean.tapscott · 2010-11-30 19:26:15

haha, did you create an email loop? That's amazing!

michal@1-2.pl · 2010-11-30 19:37:39

As if you were there...

sean.tapscott · 2010-11-30 21:29:27

I'm wondering if there's a way to change a setting through the notification settings. I know you can check for different existences using the notification tags.

Don't know the syntax, but see if we can follow along. If we perhaps create an if statement that says in pseudocode:

If ##followup.author## = ##ticket.author.name## THEN
##ticket.useremailnotification## = "no" or false or whatever

This would, of course, be in a notification template, and the user would still get a notification, but if you can disable it using notification tag syntax while sending a notification, you'll avoid the overall loop.... I think.

The real syntax here though is the real mystery. I tried reading through the code, and its too far advanced for me, especially since I have no PHP experience.

michal@1-2.pl · 2010-11-30 22:25:47

I'm not much into the notification templates just yet. Maybe I'll give it a try though mind that systems such as bugzilla have the writer excluded from posting email messages by default. I noticed this "strange" GLPI behaviour just recently. Documentation is also heavily postponed by French - English translation. I'm not English myself but in IT communications I prefer English.

michal@1-2.pl · 2010-12-02 14:55:22

It seems that notification templates are only for email content customisation. They do not allow you to interfere with adressees.
Has anyone have any idea how to FIX the problem?
Again I am interested in such a behaviour that

if WRITER=REQUESTER then the mail is not sent to that email address unless WRITER is explicitly placed in the distribution list.

I think it should be the default behaviour of any notification action - just like Bugzilla.

The ability to add CC addresses freely would also be most welcome.

linker3000 · 2010-12-03 11:22:08

Yes,

I also ended up with an email loop the other day during testing so some sanitising of email address lists prior to sending would be sensible.

Also, removing duplicates would be useful so, for example, if the requester is also defined as the administrator they do not get two emails.

goblin · 2010-12-05 16:56:03

I have the same issue with same version, did anyone succeded with solution?
thank you

michal@1-2.pl · 2010-12-08 13:59:31

Dear Developers,

may you file a bug for it?
Regards,

Michal

sean.tapscott · 2010-12-08 16:18:50

I'm surprised Goblin didn't mention it, but look at his link:
http://www.glpi-project.org/forum/viewt … p?id=22205

What the developer means here is that you should try matching the pattern that begins the out of office replies and reject those. There should be a unique pattern to auto replies and this method assumes that. Besides that, I wouldn't exactly say its a bug, but more like a feature request.

michal@1-2.pl · 2010-12-08 16:50:48

Thank you for your prompt reply.
I strongly opt for putting a solution to any multiple e-mail messages, addresses etc. in the notification system.
I also think that being able to decide whether have the message sent to writer or not is an important thing provided it does not get duplicated because there is that e-mail address somewhere in other recipients fields.
Bugzilla solution seems very appealing to me:
1. It deduplicates e-mail addresses from the ultimate e-mail list.
2. It removes writer no matter what the writer did - I'd put an exception to it to have a confirmation sent to e-mail ticket sender putting writer to the notification list explicitly.
3. Allows you to add other e-mail addresses as cc group.

I tried contacting Remi on this with the following e-mail:

----------------------
Excuse me for bothering you but I think it is important.
Problems:
1. If a GLPI user has autoresponder set there are lots of messages being created depending on mailgate run frequency.
2. E-mail addresses duplicated and multiple e-mail messages sent if user in a GLPI group or technician=requester...
Solutions:
1. Exclude writer's address from any notification unless explicitly put there for anybody's own risk.
I MEAN the ADDRESS not the WRITER so if any of the recipients' addresses match that address they should be excluded.
2. Also duplication of the addresses should be checked and extra occurences removed.
Thank you for all you have done already.
Regards,

----------------------

It really would make life a lot easier.

sean.tapscott · 2010-12-08 17:01:38

I don't get duplicate emails. I'm often the technician, administrator, and the requester and have never gotten duplicates.

Maybe my notification configuration is different though.

Last edited by sean.tapscott (2010-12-08 17:04:40)

michal@1-2.pl · 2010-12-08 20:14:48

I tried droping the messages with [autoresponder] but the problem is I see no field in criterion box that represents the e-mail subject. If I had such field I would put:
if <email subject> starts with [autoresponder] then drop it without notification.
What is the fields name for subject if available?

Thanks,

Michal

sean.tapscott · 2010-12-09 00:01:26

that's an interesting point. I don't see a subject field either. Lots of other nondescript fields to create criteria on though, like "Email : object". Not sure what that's supposed to be.

michal@1-2.pl · 2010-12-14 13:16:17

It might not be completely relevant but until very recently I treated "Rules for assigning a ticket created through a mail receiver" as a place for analising e-mail messages collected by receivers. Now it seems that this is JUST for "assigning a ticket created through a mail receiver" and not for any messages that follow it.
That said it makes utterly impossible to filter any auto responder messages because they are treated as part of an already assigned ticket.

MoYo · 2010-12-14 13:54:16

Yes you are right... Rules are not applied for followups.
Ticket created : https://forge.indepnet.net/issues/2531

MoYo · 2010-12-14 16:17:12

correction here :
https://forge.indepnet.net/projects/glp … ions/13307

michal@1-2.pl · 2010-12-26 12:19:41

Hello again.

I wish your correction worked. I applied it to no avail. I cannot prevent multiple messages creation.
It seems that I have to stop sending confirmation messages upon ticket creation. It is dangerous though because of the "cron" system GLPI is using. One cannot tell whether mailgate process is going to take part every half an hour or every half a day. I think it is kind of another bug unfortunatelly.
Regards,

Michał

Last edited by michal@1-2.pl (2010-12-26 12:20:32)

MoYo · 2010-12-30 12:08:57

I do not understand what is your problem now.

michal@1-2.pl · 2010-12-30 15:23:35

Explanation in detail:
<process 1 start>
|
v
robot sends information about backup job to glpi receiver account
|
v
<glpi creates ticket according to rules for assigning tickets to entieties>
|
v
<glpi sends acknowledgement to "writer" of ticket creation>
|
v
robot sends apologetic information that such message cannot be delivered or is registered as a new case in apropriate system
|
v
|first message to be sent|
<glpi creates follow up to the newly created ticket>
|
v
<glpi sends information to requester - in this case the very same robot - about new follow up>
|
v
robot sends apologetic information that such message cannot be delivered or is registered as a new case in apropriate system
|
v
| go to first message to be sent|
<process 1 end> - never reached.

The process continues until one change the "send follow ups" to no in the problematic ticket.
It is just one case.

Solution to process 1:
enhance rules mechanism with two additional actions: disable follow ups, suppress ticket creation notification.

<process 2 start>
|
v
<a ticket is created in glpi with requester, technitian, group... set correctly>
|
v
<glpi sends acknowledgement to all parties involved of ticket creation>
|
v
one of the recipients has autoresponder set because of any reason
|
v
autoresponder robot sends information to the response address - glpi
|
v
|first message to be sent|
<glpi creates follow up to the newly created ticket>
|
v
<glpi sends information to all parties involved/limited by notification rules>
|
v
autorespons robot gets it and sends response accordingly
|
v
| go to first message to be sent|
<process 2 end> - never reached.

solution:
exclude writer from notification circle even if writer=requester in notification rules.
One can force having the writer included if writer is explicitly put in the list.

Thank you again,

Michał

michal@1-2.pl · 2010-12-30 15:33:07

I managed to make cron job (cli) work so please skip the automatic actions part. It has changed comparing to 0.72 though. I find glpi instead of cli very unreliable too.

Regards,

Michał

MoYo · 2010-12-31 07:56:10

if you make a rule to exclude auto respond messages you will solve your problem.
It was the aim of applying rules for followups.

michal@1-2.pl · 2010-12-31 10:00:59

Show me the Way my Master.
Nothing works better than a good example.

If there is a"special" setting for autoresponder or you have a clue how to recognise every possible form of auto response message I am all yours. Otherwise my solutions are valid and still is there a way to distinguish WRITER from REQUESTER if they match in notification rules?

Truly yours,

Michał

Last edited by michal@1-2.pl (2010-12-31 10:01:16)

michal@1-2.pl · 2010-12-31 10:12:03

Hello again,

"It was the aim of applying rules for followups." it was apart from other usefull stuff if the solution actually worked. I can send you my files that were changed according to your fix to no avail.
But no matter how hard one tries to create smart rules one cannot outsmart every possible autoresponder.
Pretty please consider those two fixes - refined maybe by your knowledge and experience:

solution:
exclude writer from notification circle even if writer=requester in notification rules.
One can force having the writer included if writer is explicitly put in the list.
Solution to process 1:
enhance rules mechanism with two additional actions: disable follow ups, suppress ticket creation notification.

Thank you and your team for so much usefull work done,

Michał

Last edited by michal@1-2.pl (2010-12-31 10:12:33)

MoYo · 2011-01-04 10:36:28

Is there a email header permit to know is it is an autorespond message ?
Ticket created. https://forge.indepnet.net/issues/2553

The solution to exclude writer is not a good solution for me.
The notification permit to know if your request is take into account or not.

Forum GLPI-Project

Announcement

#1 2010-11-30 16:31:48

email notification-exclude requester if matches writer's email address

#2 2010-11-30 19:26:15

Re: email notification-exclude requester if matches writer's email address

#3 2010-11-30 19:37:39

Re: email notification-exclude requester if matches writer's email address

#4 2010-11-30 21:29:27

Re: email notification-exclude requester if matches writer's email address

#5 2010-11-30 22:25:47

Re: email notification-exclude requester if matches writer's email address

#6 2010-12-02 14:55:22

Re: email notification-exclude requester if matches writer's email address

#7 2010-12-03 11:22:08

Re: email notification-exclude requester if matches writer's email address

#8 2010-12-05 16:56:03

Re: email notification-exclude requester if matches writer's email address

#9 2010-12-08 13:59:31

Re: email notification-exclude requester if matches writer's email address

#10 2010-12-08 16:18:50

Re: email notification-exclude requester if matches writer's email address

#11 2010-12-08 16:50:48

Re: email notification-exclude requester if matches writer's email address

#12 2010-12-08 17:01:38

Re: email notification-exclude requester if matches writer's email address

#13 2010-12-08 20:14:48

Re: email notification-exclude requester if matches writer's email address

#14 2010-12-09 00:01:26

Re: email notification-exclude requester if matches writer's email address

#15 2010-12-14 13:16:17

Re: email notification-exclude requester if matches writer's email address

#16 2010-12-14 13:54:16

Re: email notification-exclude requester if matches writer's email address

#17 2010-12-14 16:17:12

Re: email notification-exclude requester if matches writer's email address

#18 2010-12-26 12:19:41

Re: email notification-exclude requester if matches writer's email address

#19 2010-12-30 12:08:57

Re: email notification-exclude requester if matches writer's email address

#20 2010-12-30 15:23:35

Re: email notification-exclude requester if matches writer's email address

#21 2010-12-30 15:33:07

Re: email notification-exclude requester if matches writer's email address

#22 2010-12-31 07:56:10

Re: email notification-exclude requester if matches writer's email address

#23 2010-12-31 10:00:59

Re: email notification-exclude requester if matches writer's email address

#24 2010-12-31 10:12:03

Re: email notification-exclude requester if matches writer's email address

#25 2011-01-04 10:36:28

Re: email notification-exclude requester if matches writer's email address

Board footer