Make New Mail Rule

[akim]

My attempt to create a mail rule fails.
I attempted to script a rule to filter mail that had been sent more than 4 days in the past.

I wanted the new rule’s header to be DateSent , the rule type to be header key, and the qualifier greater than value

tell application "Mail"
	set newRule to make new rule at end of rules with properties ¬
		{name:"Trial", enabled:true}

	tell newRule
		make new rule condition at end of rule conditions with properties ¬
			{header:"DateSent", rule type:header key, expression:"4", qualifier:greater than value}
	end tell
end tell

Script Debugger compiles the mail rule’s header in blue as though it is a system or applescript property, rather than purple. Please refer to the attached pdf to see it in color.

Make New Rule Trial.pdf (23.2 KB)

1. What method can I use to script AS to communicate that the Mail’s rule’s property of header belongs to the Mail application and not to AppleScript or any other overiding process?

2. How do successfully create a new mail rule with:
   rule type: header key
   qualifier greater than value

[paulskinner]

This only addresses your first question.

tell application "Mail"
	set newRule to make new rule at end of rules with properties ¬
		{name:"Trial", enabled:true}
	
	tell newRule
		using terms from application "Mail"
			make new rule condition at end of rule conditions with properties ¬
				{header:"DateSent", rule type:header key, expression:"4", qualifier:greater than value}
		end using terms from
	end tell
end tell

[akim]

@paulskinner

using terms from application "Mail"

Thanks for your addition of using terms from application “Mail”. I have attached Mail’s Rules Pane on the newly created rule.
Rules Pane.pdf (68.1 KB)

Unfortunately, the modification of using terms from application “Mail” did not create the following Rule properties:
rule type header key
header DateSent.

It did, however, create:
qualifier greater than value

[paulskinner]

I understand the result is not as desired. I believe some aspects of Rule creation via script has been broken for several versions of mail. I’m not sure if theres a workaround or not. I wasn’t able to find any method that allowed me to make rules in this way. It’s also terribly awkward that no programatic changes to the Rule set are visible without quoting and restarting Mail.app.

Edit: Just to be completely accurate. I haven’t found any way to create rules that are correctly formed. As you have seen, it mis-maps some aspects of the rules you do create.

[Camelot]

It absolutely is a bug in Mail and how it handles Rules in AppleScript - basically any properties passed in at creation time are completely b0rked

However, all is not lost - the rule and its conditions are created, just wrong. However, you’re free to immediately set the values to what you want:

tell application "Mail"
	set newRule to make new rule at end of rules with properties ¬
		{name:"Trial", enabled:true, all conditions must be met:true}
	-- anything except 'name' is unset/default, so correct that:
	 set enabled of newRule to true
	
	tell newRule
		using terms from application "Mail"
			-- any parameters (except, weirdly 'expression' is b0rked') but we can try...
            set newCond to make new rule condition at end of rule conditions with properties ¬
				{header:"FFFF", rule type:header key, expression:"4", qualifier:greater than value}
            -- now we have to actually do the work
            tell newCond
				set its header to "DateSent"
				set qualifier to greater than value
			end tell
		end using terms from
	end tell
end tell

[paulskinner]

This is great news! Thanks @Camelot!

Edit: This code adds a fully functional “MoveIncominMail>4DaysOld” rule to my Sequoia Mail.app Version 16.0 No Using terms of required.

Edit 2: Reduced initial properties for rule creation and rule condition creation.

tell application "Mail"
	set targetMailbox to mailbox "Old Incoming Mail" of account "Exchange"
	set newRule to make new rule with properties {name:"MoveIncominMail>4DaysOld"}
	tell newRule
		set newRuleCondition to make new rule condition at end of rule conditions with properties {rule type:header key}
		tell newRuleCondition
			set its header to "DateReceived"
			set qualifier to greater than value
			set expression to "4"
		end tell
		set enabled to true
		set all conditions must be met to true
		set move message to targetMailbox
		set should move message to true
		set stop evaluating rules to true
	end tell
end tell

[akim]

Camelot, I enjoyed your insight that Mail’s command to make new rule fails to assign variables for many rule condition properties, The make new rule in Sequoia 15.4 successfully set enabled to true in addition to setting variables for name and all conditions must be met.

I modified your script as follows:

tell application "Mail"
	
	set newRule to make new rule at end of rules with properties ¬
		{name:"Trial", enabled:true, all conditions must be met:true}

Mail allowed a new rule to create values for properties : expression and qualifier.
But did not allow creation of values for properties: header and rule type.
Setting header to DateSent strangely, set rule condition’s rule type to header key, without explicitly assigning that value to rule type.

	
	tell newRule
		using terms from application "Mail"
			set newCond to make new rule condition at end of rule conditions with properties ¬
				{expression:"4", qualifier:greater than value}
			
			tell newCond
				
				--Set rule condition's rule type to header key, without explicitly assigning that value.
				set its header to "DateSent"

--
			end tell

			newCond's properties --> ¬
			{header:"DateSent", expression:"4", rule type:header key, qualifier:does contain value}

		end using terms from
	end tell
end tell

This had led me to some other questons.

1. Is the unexplained behavior by Mail arising from the command make new?

2. Does the Mail make command or more globally, the AS make command, limit itself by syntax or other means to confine assigning limited property variables from a {property:value} AS record?

3. How does Mail automatically assign the header key value to the rule type property, when the DateSent value is assigned to rule condition’s header property?

[Camelot]

I think the answers are going to be nuanced, and beyond anybody here’s ability to answer with absolute certainty (unless there’s a rogue Mail.app/AppleScript developer lurking in the wings…? )

Anyway, more specifically:

The make new rule in Sequoia 15.4 successfully set enabled to true in addition to setting variables for name and all conditions must be met .

Not on my machine. Any new rule was disabled by default, which is why I added the line to enable it. True, though, the all conditions must be met flag is honored.

I suspect, under the hood, there is some default value that’s used and not getting overwritten - although that doesn’t explain why yours defaults to enabled, and mine to disabled.

Setting header to DateSent strangely, set rule condition’s rule type to header key, without explicitly assigning that value to rule type.

OMM, at least, setting a mail rule to header key: “Date Sent” appears in mail.app using the 'Date sent" option, not specific key, so it’s definitely doing something ‘under the hood’ to map the key to the action.

As for the rest of your questions…

1. Is the unexplained behavior by Mail arising from the command make new?

According to the dictionary, make is coming from the Standard Suite, so not some Mail.app-specific override.

2. Does the Mail make command or more globally, the AS make command, limit itself by syntax or other means to confine assigning limited property variables from a {property:value} AS record?

TBH, I find it inconsistent (or more directly, a crap shoot), so assume there is some level of application integration needed to map the properties to the object. There probably is some rule about it, and I generally prefer to make new objects with their properties directly, but it’s not worked enough that I’ve come to rely on creating a minimal-viable object and setting its properties after the fact, like I did here.

3. How does Mail automatically assign the header key value to the rule type property, when the DateSent value is assigned to rule condition’s header property?

See my note above about how ‘Date Sent’ is being re-interpreted. I don’t know if it’s specific to this header (i.e. Apple made a special case for DateSent knowing that it’s likely to be a highly-used key, so they added a special case. I’m not on the Mail.app development team, though, to know for sure.