Mailrules extended ( 2021 edition )

A few years ago, more precisely in 2008, I already wrote about an extension of the Rules Engine in Notes / Domino.

Although the existing programming covers a large part of users’ requirements, it would sometimes be desirable to be able to create more flexible rules.

If you look at how the rule created by the user is implemented internally, you will see that the rule is converted into an @formula.

So it is obvious to have a functionality that allows the direct input of a formula.

I have already posted ideas on the HCL portal (https://domino-ideas.hcltechsw.com/); these are also in “Likely to Implement” status.

Version 12 of Notes / Domino is currently in the beta phase. So I looked at programming in the Domino Directory template (pubnames.ntf). Unfortunately, at the moment it looks like the functionality is not yet implemented in V12.

If and when an implementation will take place; I have no information on that. Is that bad? No, I don’t think so.

The big advantage of Notes / Domino is that we can extend the functionality ourselves in many areas.
My extension of the rules from 2008 ran without change from version 8.5 to version 11.0.1FP2. I have looked at the current code of Beta2. This has changed only insignificantly. Therefore I have transferred my extensions into this code.

The changes concern 2 design elements.

Both design elements have no dependencies to other design elements.
Furthermore my function extensions are comprehensible for every average developer.

The “(RulesDlg)” form has been extended by a section that allows entering an @formula

The “condition” item was extended by the selection “@Formula“

All changes in LotusScript library “Rules” are commented ‘Ulrich Krause, @Formula support. No change was made to the basic functionality.

The two design elements can be downloaded here.

To implement, simply replace the two design elements in the Domino Directory with the elements in the downloaded file.

Information About Server Mail Rules

While server rules are accessed only from the Configuration document, the individual rule entries themselves do each have their own document.

In the individual rule document when a server rule is created, it is assigned an OrderNum. The first rule created is assigned 0, with each subsequently created rule being incremented by 1. The actual rule formula is stored in an entry $FilterFormula, which is a @Function formula representation of the rule.

In the Configuration document, the $FilterFormulaCount field is a counter that is created with registering the first rule and counts one up with every new rule that is created. When a rule is enabled, the individual rule document’s $FilterFormula field is written to a $FilterFormula_n field in the Configuration document. The n value is dependent on the OrderNum field value from the individual rule document.

Note: Because the n value for the $FilterFormula_n initially starts at 0 and the $FilterFormulaCount starts at 1, the highest $FilterFormula_n n value is expected to be 1 lower than the $FitlerFormualCount value. It is also possible that the $FilterFormulaCount value is not decremented when rules are deleted. This behavior will have no effect on the proper execution of server rules.

Another important field stored in the Configuration document is $FilterSeqNo. This field contains a numeric text value that is incremented when any rule is updated, enabled, or disabled. The Router, which executes server rules, checks this value to see if it has been incremented. If the value has been incremented. then the rules are reloaded from the Configuration document.

If you issue the Domino console command “set rules”, Domino will register the active rules. You will see a status message similar to the following:

Successfully registered 2 system filters.

The amount of system filters returned is the amount of active server rules.

Because enabled server rules are stored in Configuration documents, and there are other server specific fields in the Configuration documents, it is critical that you do not make a copy of a Configuration document as the basis of a Configuration document for a second server. For example, you want to create a Configuration document for Server B, so you copy the document from Server A and modify the necessary changes. This action can cause unexpected server rule execution, which may not be resolved by simply disabling or deleting the rules from the copied server document.
If this issue should occur, then the following instructions can be used to ‘clean up’ the stored server rules in the Configuration document:

1. Disable all rules using the configuration user interface.
2. Delete any undesired rules using the configuration user interface.
3. Create a LotusScript agent with the code below. The agent should be designed to act on a collection of “None” or Selected Documents.

Dim s As New notessession
Dim doc As notesdocument
set doc=s.documentcontext
Forall ff In doc.Items
    If ff.type = 1536 And Lcase(Left(ff.name,15)) = "$filterformula_" Then
        Call ff.remove
    End If
End Forall
doc.~$FiltersSeqNo= Cstr(Cint(doc.~$FiltersSeqNo(0))+1)
Call doc.Save(True, True)

4. Open the Configuration document, and execute the agent.
5. From the server console issue the command: set rules
6. Enable rules as desired from the configuration user interface.

{Source Lotus Software KnowledgeBase}