Redmine

Jean-Philippe Lang wrote:

Why not use the more standard X-Priority header?

Hrm. The header Priority has values "normal", "urgent" and "non-urgent". I can't find any RFC that defines the values of "X-Priority", but most examples I see use the values 1 through 5. While this maps up to Redmine's default priority values, other systems might have limited or extended these enumerations (e.g. my company uses "Low, Normal and Emergency". How would these modified values be mapped to X-Priority? 1, 3, 5? It's kinda vague, yeah?

I guess that's why I thought just creating a Redmine-specific priority header would be a better choice. What're your thoughts on this?

The following patch adds a standard Priority field defined in RFC 2156. The priority values are mapped to one of "normal", "urgent", or "non-urgent".

diff --git a/app/models/mailer.rb b/app/models/mailer.rb
index f58a1c88d..33b82a519 100644
--- a/app/models/mailer.rb
+++ b/app/models/mailer.rb
@@ -71,6 +71,7 @@ class Mailer < ActionMailer::Base

   # Builds a mail for notifying user about a new issue
   def issue_add(user, issue)
+    headers['Priority'] = priority_for_header(issue)
     redmine_headers 'Project' => issue.project.identifier,
                     'Issue-Tracker' => issue.tracker.name,
                     'Issue-Id' => issue.id,
@@ -103,6 +104,7 @@ class Mailer < ActionMailer::Base
   # Builds a mail for notifying user about an issue update
   def issue_edit(user, journal)
     issue = journal.journalized
+    headers['Priority'] = priority_for_header(issue)
     redmine_headers 'Project' => issue.project.identifier,
                     'Issue-Tracker' => issue.tracker.name,
                     'Issue-Id' => issue.id,
@@ -763,6 +765,17 @@ class Mailer < ActionMailer::Base
     h.each {|k, v| headers["X-Redmine-#{k}"] = v.to_s}
   end

+  def priority_for_header(issue)
+    position_name = issue.priority.position_name
+    if position_name.start_with?('high')
+      'urgent'
+    elsif position_name.start_with?('low')
+      'non-urgent'
+    else
+      'normal'
+    end
+  end
+
   # Singleton class method is public
   class << self
     def token_for(object, user)

Added test code to #2746#note-12.

Setting the target version to 5.0.0.

Go MAEDA wrote:

The following patch adds a standard Priority field defined in RFC 2156. The priority values are mapped to one of "normal", "urgent", or "non-urgent".

I found that it is not appropriate to use the Priority header to express issue priorities because the header is related to QoS control of mail delivery. RFC2076 says the header "can influence transmission speed and delivery".

Since issue priority has nothing to do with mail delivery priority, it is wrong to use the Priority header to express issue priority.

The discussion git a bit derailed from the original request here.

I think the consent now is to just sent the configured priority name as an additional header. For that, I have attached an updated patch which was extracted from Planio. To resolve this issue, we could just apply this patch which is a nice low-friction addition.

Further trying to map this to the value to the "standard" X-Priority / Priority fields in mails could then be an additional step. However, this is something that some people may not want and it is something which has wildly differing support in the MTAs and MUAs with various headers allowing different values and slightly differing semantics.

From my (limited) research, the most common headers are:

• Priority - Allows the values Non-Urgent, Normal, Urgent
• X-Priority - Allows the numeric values 1 - 5 with lower numbers indicating higher priorities. Outlook only emits 1, 3 and 5 respectively.
• Importance - This appears to be a "Microsoft standard". It allows the values Low, Normal, High

Microsoft / Outlook map their internal importance value to all of these header values.

If so desired, we could set one or all of these headers based on the result of IssuePriority#low? or IssuePriority#high?. However, I don't believe this is particularly useful, as it still just reflects the priority of the issue overall, not the priority of the respective notification. As such, I'd rather vote for just adding the name of the priority in the X-Redmine-Issue-Priority header as implemented by the attached patch and not attempt to deduct a mail priority / importance from that.

Related documentation:

• https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/2bb19f1b-b35e-4966-b1cb-1afd044e83ab
• https://stackoverflow.com/a/64922489/421705

Setting the target version to 5.1.0.

Committed the patch in r22244. Thank you for your contribution.

Redmine 5.1.0 will have X-Redmine-Issue-Priority header field that indicates the issue priority.