Priority is a field that the sender of the message sets. I don't think we should allow filters to change that. The implementation of overriding the priority is pretty obscure anyway, as it leaves the 'priority' header intact and (if I understand this correctly) sets an auxiliary priority flag in the .MSF file. Except for filters, there is no UI for this feature. If someone wants to override the priority on the message after it's arrived, or to undo the override from a filter, they need to create a new filter and Run Now. (Even more problematic if the priority of the message is a criterion in that filter -- see bug 252041. It's even possible, I suppose, that the override feature is the cause of that bug.) Especially now that we have unlimited tags, it makes much more sense for someone who's concerned with the priority of incoming messages to create a filter to tag a priority message; the tag is easily seen, easily altered, easily removed. See bug 190201, which I thought was a good idea. Removing this option would allow WontFix of bug 188549, bug 181561, bug 298837.
Component: MailNews: Composition → MailNews: Filters
QA Contact: composition → filters
have you just coined a new term? :) Interesting idea. I probably agree with this assessment. Also affects part of bug 254589.
Product: Core → MailNews Core
(In reply to comment #0) > Priority is a field that the sender of the message sets. I don't think we > should allow filters to change that. > > The implementation of overriding the priority is pretty obscure anyway, as it > leaves the 'priority' header intact and (if I understand this correctly) sets > an auxiliary priority flag in the .MSF file. > > Except for filters, there is no UI for this feature. If someone wants to > override the priority on the message after it's arrived, or to undo the > override from a filter, they need to create a new filter and Run Now. (Even > more problematic if the priority of the message is a criterion in that filter > -- see bug 252041. It's even possible, I suppose, that the override feature is > the cause of that bug.) > > Especially now that we have unlimited tags, it makes much more sense for > someone who's concerned with the priority of incoming messages to create a > filter to tag a priority message; the tag is easily seen, easily altered, > easily removed. See bug 190201 [EXPIRED, but reopening for comment], which I thought was a good idea. > > Removing this option would allow WontFix of bug 188549, bug 181561 [since FIXED], bug 298837. cc for discussion
With the addition of custom filter actions and search terms, it would be worth reviewing the list of filter and search options to see which should be in core, and which could be moved to extensions. I can see the point of including priority as an extension-only action. However, that would then break existing users, and for that reason may not be worth the effort.
I'm not so sure that there is a contingent of users of this feature. It seems pointless to me, but the last time I got a mail flagged with non-default, non-"Normal" priority was around 2000-2001. (I hadn't even started using Mozilla at that point. I think, I have never seen the priority indication in Thunderbird except when testing priority-related bugs.) Per your comment in the other bug, do you actually see spam coming in with priority set? I suppose if that were an issue, then this feature has some utility.
ATM around 20% of the mail in my spam folder have priority "highest". Not that i need this feature in any way, and would not miss it.
Since the concept of priority is mostly implemented in TB already, if it was my decision I would rather spend my time improving its support, rather than trying to remove it. I don't use priority, but the main reason that I don't is that it is not convenient to change it on a single message. If it was, I would probably use it. I think the point of a priority field is to improve message triage. It is not primarily about maintaining the original intent of the author. Yet I have certainly been in organizations where priority was used to flag important messages. In such an organization, I could imagine the value of a filter: If (Sender is not in my address book) (set priority to normal).
[Bryan] I'm not arguing against this, but throwing out gut reaction for discussion. Would allowing change of priority: a) be considered feature creep b) be hijacking a field for usage to which it was not intended, and (in backend) conflation is something which we seen to cause problems in other areas c) invite confusion in UI, amongst users and support
I think rkent's case would likely have some real value for users but it would be an entire other set of UI contols and information that would need to be designed and implemented. The example of being able to change priority on a message or multiple messages would need to be fixed. Also I checked the RFC and it seems like priority was intended only for the author to set. Though I could be interpreting that incorrectly and we don't always have to follow RFCs exactly. http://tools.ietf.org/html/rfc4021#section-2.1.54 I wouldn't really advocate removing this but I also would push for creating a better priority managing system.
The general attitude has been that recipients should be able to control priority of received e-mails, i.e., override the sender's priority. But that was back when we showed the priority column by default, and colored the e-mails differently based on priority, etc. We do still have a priority column, btw, we just don't show it by default.
I think the biggest problem with this header is that it is subjective to the sender of the message, and as stated in comment #5, frequently abused by people to increase their importance. On the other hand, flags and tags are set by the user, thus within the recipient's control, and make more sense to categorize the messages. Personally, I'm not using the priority field at all but use flagging a lot, so leaving it as is with priority not shown by default and keeping it an option for someone to use it should be fine. There are other bugs on manipulating header fields (e.g., the Subject line), which I'd consider delicate as you are altering the original message, but there may be use cases for that as well.
I also vote AGAINST removing this function.
You need to log in before you can comment on or make changes to this bug.