Defect #10414
closed
Duplicated Message-Id in headers of mails send by Redmine
0%
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)
Updated by Jérôme BATAILLE about 12 years ago
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.
Updated by Etienne Massip about 12 years ago
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?
Updated by Etienne Massip about 12 years ago
- Target version set to Candidate for next minor release
It is not.
Updated by Jérôme BATAILLE about 12 years ago
That's it, the conversation id is called references.
Thanks to have integrated the patch in the next minor release.
Updated by Etienne Massip about 12 years ago
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.
Updated by Jean-Philippe Lang about 12 years ago
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.
Updated by Jérôme BATAILLE about 12 years ago
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.
Updated by Jérôme BATAILLE over 10 years ago
- 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
Updated by Jérôme BATAILLE over 10 years ago
You can remove it from Candidate for next minor release
Updated by Toshi MARUYAMA over 10 years ago
- Status changed from Resolved to Closed
- Target version deleted (
Candidate for next minor release)
Thanks.
Updated by Jérôme BATAILLE about 7 years ago
Hi, you can indicate in the Resolution that's it's Invalid, if you have the time to, thanks a lot.