Use Priorities in Project Mapping Rules
When processing an email via a Profile and its Project Mappings, the default evaluation of those rules is 'first match wins'. Its also possible to change this strategy to a rule-priority based approach.
Priority Ordering
0 - default (lowest) priority
1 - highest priority
2 - lower priority
...
1000 - much lower etc.
Steps
Review the Profile with the Rule Evaluation Strategy of First Match Wins, click Edit:
Select Priority Rule Evaluation Strategy, and hit Submit:
See the result:
With the Rule Evaluation set to Rule Priority all Rules now get a Rule Priority value that determines evaluation order. Review the Project Mappings, see them indicate default priority:
In this example there is an existing domain rule, but we'll create a higher priority rule for sender boss@localhost that will win against the default. In this case, we'll customize the issue created to have a priority of Blocker. To do this, edit a Project Mapping (here the TEST project mapping):
Then go to the Rules section and click Create:
Create a new rule, setting the From: regexp to be boss@localhost:
Now, to indicate that this rule has applied, we customize the Rules properties, note that the Evaluation order of rules can be changed, just as it could with 'First Match Wins'. Potentially, this allows high priority rules to be evaluated sooner. Click the cog icon to configure the rule:
From this point, everything can be configured, see the available sections indented under the Rule. To set the priority, select the Issue section:
(NOTE: many fields are inherited from the parent Project Mapping, and in turn from the Default Project Mapping). Click Edit:
Select the Blocker issue Priority, (if 'Non' is the value defined through inheritance from the Default Project Mapping, then the JIRA default will apply)
And Submit, to see it overridden:
Validate new Project Mapping Rule
So, to validate, we need to create/copy an existing Test Case, and set the From: address to be boss@localhost, Submit to save
Now run the Test Case:
Analysing the result
The result screen shows:
1.The Profile that was used
2.The Project Mapping that was used
3.The Rule that matched
4.The value that caused the match
The important thing here is what Rule applied, (3) above shows .*@localhost which is a general match for <anyone>@localhost. It won because that rule had a default priority, and the other rule for boss@localhost also had that priority, ie, it was no better.
Updating the Boss rule
Now change the boss rule to have a have a priority value other than default, note that the Project Mapping view gives short cut edit links to each rule, use it for RULE 2:
Setting any priority will result in a win over a default priority Rule so, set the lowest possible (20), and Submit:
Now see the priority in the Rule:
Repeating the Test Case execution above, this time, the results are different, below, you can see that the modified Rule (1) has been matched on the sender address value (2). All customizations relating to the issue would then have been applied:
Performance Considerations
To make best use of resources, JEMHC loads all rules and sorts them in priority, order, this means that the highest rules will be tested first. Once a rule match wins, equal or lower priority rules are discarded.