Defect #10414
closed
Duplicated Message-Id in headers of mails send by Redmine
Added by Jérôme BATAILLE about 13 years ago.
Updated about 8 years ago.
Category:
Email notifications
Description
If a modification is made on the same issue the message Id can be the same :
def self.message_id_for(object)
# id + timestamp should reduce the odds of a collision
# as far as we don't send multiple emails for the same object
timestamp = object.send(object.respond_to?(:created_on) ? :created_on : :updated_on)
hash = "redmine.#{object.class.name.demodulize.underscore}-#{object.id}.#{timestamp.strftime("%Y%m%d%H%M%S")}"
host = Setting.mail_from.to_s.gsub(%r{^.*@}, '')
host = "#{::Socket.gethostname}.redmine" if host.empty?
"<#{hash}@#{host}>"
end
the message id is made with the created_on date and not with the updated_on date.
Usually it's more likely that there is a created_on field when there is no updated_on,
and not the opposite.
Here is a fix :
timestamp = object.send(object.respond_to?(:updated_on) ? :updated_on : :created_on)
The only case that seems odd is the table wiki_contents that as an updated_on field but no created_on one.
Anyway the patch as the original code always fallback on the existing field.
The patch just finds the more accurate information, updated_on.
Isn't the message id the conversation id? If yes, it does not seem too weird to have the same id for every update of a specific issue?
- Target version set to Candidate for next minor release
That's it, the conversation id is called references.
Thanks to have integrated the patch in the next minor release.
It's candidate =)
From what I've seen, it seems that Original-Message-ID
header is more usable then References
which should list all the ids of all the messages of the conversation.
If a modification is made on the same issue the message Id can be the same
How to reproduce? Because when an update is done on an issue, this is the timestamp of the journal that is used, not the issue timestamp.
In the main actual cases the created_on is reflecting the update time.
So there is no case for the moment were you can reproduce the bug because in the only table having the two fields (issues) the date is get through the journal table.
But I suppose it's sort of misleading (and we were mis leaded, lost a few days to understand why messages were not received) when adding new mailer methods, because we were sending mails reflecting changes in the issues, but not using the journal informations.
I suppose again that if other mailer methods are added, they can fall into this case, it's the reason why I proposed the patch.
- Status changed from New to Resolved
After digging into the code, I realized the patch I proposed leads to an inconsistency :
references and message_id use the method that I proposed to patch.
It implies that the patch breaks the references for an issue update.
I now use message_id on a journal object, thus the message_id is always unique.
Sorry for ma bad understanding of the problem.
I close this issue
You can remove it from Candidate for next minor release
- Status changed from Resolved to Closed
- Target version deleted (
Candidate for next minor release)
Hi, you can indicate in the Resolution that's it's Invalid, if you have the time to, thanks a lot.
- Resolution set to Invalid
Also available in: Atom
PDF