GNOME Bugzilla – Bug 624896
Add a column for X-Priority headers
Last modified: 2021-05-19 11:45:49 UTC
I have a summary buffer with a column for "Flagged" (with a red circle containing a white exclamation mark in it) in my summary window. However, when I get email (currently tested with IMAPX backend) that contains a proper X-Priority: 1 header, for example, which is the highest priority, still there's no icon or checkbox in that column. I'm building the latest gnome-2.30 branch from the git repository and installing it on my Ubuntu 10.04 64bit system.
Evolution's philosophy is the recipient gets to decide which messages are important, not the sender. X-Priority headers are not reflected in any of the columns.
I could have sworn this worked in previous versions of Evolution. Anyway, I think this decision is incorrect. It's fine if we want to give users the ability to mark important messages (but what is the "Follow Up Flag" column for?), but the fact that the sender of the email felt it was important and wanted to flag it that way should not simply be ignored. Many people use that flag for good purposes (I have some triggers I created for my source code control system, for example, that sends email on various events. I use the X-Priority flag to mark messages which require the recipient to take some important action, as opposed to simply being informative). We need to have a way (optional if you like) of representing that to the user. My preference would be this: if the X-Priority field is set to 1 (or 2?) then the default setting for the Flagged column is true/enabled. If the user wants to un-flag it, they can click on that column again to disable the flag and override it. If you don't like that, then another option is to add a new column to the summary, something like "Priority" or whatever, that adds in the icon (same icon as the Flagged column if you like) if X-Priority is set. Then if I want to see that I can add that column to my summary; if I don't want to see it then I can remove the column. This is not so nice because it eats up screen real-estate and, to my mind, largely duplicates the value of the Flagged column, but it's better than nothing I suppose.
This depends on the bugs it depends on (currently bug #262536 and bug #710701). The thing is that the 'Flagged' column corresponds to \Flagged IMAP message flag. These flags are just on/off, not a multivalue and they can be read without touching message content; in contrast to custom header value, which can be read only from the message content. With some providers (like EWS), the headers are not always known (they are not even provided by the server in such case). Even the providers try to read the top message headers when they recognize a new message, it doesn't store them all, neither Camel allows to store a subset of them anywhere (consider multiple applications accessing the same account, each of them wanting different set of custom headers to be available in the summary for the message list). I do not say it's impossible to do, I only want to show that it's not always possible. User can enable the custom headers for the message preview in Edit->Preferences->Mail Preferences->Headers, but I agree it's not the same as having it shown directly in the message list. A workaround for this would be to have an Incoming filter which will do something like: If any of the following conditions are met Specific header X-Priority is 1 Specific header X-Priority is 2 Then Set Status Important Such filter can have side effects (due to the Specific header condition), full message download when needed.
*** Bug 365119 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.