[Design] filters: Subject to automation

[Ray Ryan]

On Monday, November 11, 2002, at 04:22  AM, Arnulv Rudland wrote:

> Bruce Dykes said:
>
>>> The obvious problem with this approach is that it
>>> doesn't let the user
>>> see the mod'd subject line, assuming outgoing rules
>>> are executed on
>>> Send.
>>
>> Which is a Bad Thing. Anything a user is reasonably
>> expected to have authored, such as addresses,
>> subjects, and bodies, should be vettable by the user
>> before sending.
>
> Agree!
>
> However, How bad it is, depends on where in the process the filter 
> hook is
> applied.
>
> I can think of three scenarios for the moment (there are certainly 
> more):
>
> 1. reply to an email.
> If the fitler event is fired on pushing the reply-button, the filter
> is applied before the email enters the editor. Then the Sibject will 
> already
> contain "[projcet] ..."
>
> 2. Forwarding of an existing item
> Same as above, if the item already contains the "project" attribute.

I think these first two scenarios are both handled by the same 
creation-time hook. There just has to be enough context around for the 
script to figure out if why creation is happening.

> 3. A complete new message.
> Here you have no project-attribute. For this case amn "Apply Filter" 
> button
> in the editor would do. This button would also be needed for changes in
> context during the process, e.g. when you forward a not from some other
> project.

Hopefully it will be easy and natural for the user to create a new note 
and then set its project attribute. So rather than a manual "Apply 
Filters Now" button, how about an "attributesDidChange" hook. When the 
appropriate filter is attached to this hook, it sees that the changed 
attribute was the Project and quietly (but visibly!) messes with the 
Subject line.

Ray