Hallo,
wenn die Regel immer noch greift, dann liegt das am Profildokument der Maildatenbank. Du müsstes dieses Dokument bearbeiten und dann die entsprechende Regelinformation dort löschen.
Siehe hier:
Table of Contents
I. Disabled rules that still trigger
II. Deleted rules that still trigger
III. Rules that are enabled but do not run
IV. Workaround for rules that are deleted but still trigger and rules that are enabled but still run
V. New mail rules run but do not appear in Rules folder
VI. Background Information on mail rule functionality
**********************************************
I. Disabled rules that still trigger:
This issue is common in Notes R6 where mail templates from Notes 6.0.2 (and releases after this one) and R6.5 are used. This issue occurs when the Calendar "MiniView" rule is not configured and either a single mail rule exists and it is disabled, or multiple mail rules exist and they are all selected to be disabled. The result is that the first mail rule (with an OrderNum field value of 0) is not properly disabled and it will continue to execute.
This issue was reported to Quality Engineering as SPR #FBAY5UCKZR.
Workaround (to repair current issue):
1. Examine the document properties of the existing rules and be sure that the one with a field value of 0 (zero) in the OrderNum field is disabled.
2. Create and execute the following LotusScript agent:
Dim session As New NotesSession
Dim db As NotesDatabase
Dim doc As NotesDocument
Dim ff As NotesItem
Set db=session.currentdatabase
Set doc=db.getprofiledocument("CalendarProfile")
Set ff = doc.GetFirstItem("$FilterFormula_0")
Call ff.Remove
If doc.getitemvalue("Use_CalendarRule")(0) = "1" Then
doc.Use_CalendarRule = "0"
End If
Call doc.Save(True, True)
3. Re-enable the Calendar "MiniView" rule if so desired.
Solution (to avoid this situation in the future):
To resolve this issue, the LotusScript code within the Disable action in the "(Rules)" folder must be updated, as follows:
For Notes R6.5 and R6.0.2 (and releases after 6.0.2):
Original code (line 23):
If Not ( Lcase( Left( items.name,16 ) ) = "$filterformula_0" ) Then '//Resave for MiniView
Modified line:
If Not ( Lcase( Left( items.name,16 ) ) = "$filterformula_0" And profile.getitemvalue("Use_CalendarRule")(0) = "1") Then '//Resave for MiniView
For Notes R6.0 and R6.0.1:
For R6.0 prior to 6.0.2, either update to the 6.0.2 (or later) template and make the above correction, or replace the following area of the code as noted:
Original code (starting on line 22):
If Lcase(Left(items.name,7)) = "$filter" Then
Call items.remove()
End If
Replacement code:
If Lcase(Left(items.name,14)) = "$filterformula" Then
If Not ( Lcase( Left( items.name,16 ) ) = "$filterformula_0" And profile.getitemvalue("Use_CalendarRule")(0) = "1") Then '//Resave for MiniView
Call items.remove()
End If
End If
II. Deleted rules that still trigger:
This occurs if a rule was deleted while it was still enabled. This causes the rule entry in the Calendar Profile to not be removed. In order to avoid this issue in the future, be sure to always disable a mail rule prior to deleting it. Ways to workaround this issue (and remove the rule entry from the Calendar Profile) are listed further below.
This issue was reported to Quality Engineering as SPR# MGAN5EDSB2. There is a related issue where deleting a mail rule while the Preview Pane is open can cause an error (in Notes/Domino releases prior to 5.0.9). For more information on this issue refer to Document #1084301, "Receive Error When Deleting Mail Rule While the Preview Pane is Open."
For server-based mail rules, tested in 6.5.2 and 6.5.3, it was found that mail rules that were deleted while still enabled were in force until either SET RULES was issued from the Domino console (which showed the remaining rules as registered), or the Domino server was restarted.
NOTE: In some cases, a rule may not have been deleted but still runs and does not display in the Rules folder.
The cause may be a duplicate Rules folder, visible only in the Designer client. To check if this is the case, open the mail database in Designer and select Folders to see if there are duplicates. It is unknown why this would occur, but it may be related to unexpected behavior during the upgrade of the mail file design.
To remove a duplicate Rules folder:
1. Open the mail file in the Designer client.
2. Open the Folders design list.
3. The "(Rules)" folder with the older date should typically be the one to delete. If deleting the older folder causes issues, then repopulate the folder using the instructions below.
To populate a Rules folder:
1. Create a view with the selection formula, Select Form="Mailrule".
2. Open the documents that appear in the view to determine which correspond to rules missing from the Rules folder. If the rule is not within the view, do not continue with these instructions. Instead, follow the instructions in the Workaround section below.
3. Drag the document into the Rules folder.
III. Rules that are enabled but do not run:
This issue can occur due to different logic issues in the rule enablement functionality. One issue is that newly created mail rules that are initially disabled/off do not increment a necessary rule counter field. This issue is true within mail templates in both Notes R5 and R6.0.
In Notes R5, there is an additional issue in which the Disable Rule(s) action incorrectly sets the rules counter to a numerical value, rather than the expected text value. In the Notes Domino 6.0 mail template, there is an additional issue where the Enable Rule(s) action sets the rule counter to a value "1" less than is appropriate.
Additionally, given the numbering process used, enabled rules may not be numbered contiguously. Given that R5 will run a maximum of 50 rules per user, it is possible that a rule may not trigger if its internal number is greater than 49 (numbering starts at 0).
Relative to this issue are the following SPRs:
JCHN52B5GF: The "Disable Rule(s)" action incorrectly sets the rules counter to a numerical value rather than the expected text value.
MGAN5EDTNN: Notates an issue where the mail template code logic does not increment the rules counter for new disabled rules as well as an issue with the 6.0 mail template's "Enable Rule(s)" action incrementing to a value 1 less than expected.
DCOY4TX7JE (the workaround below can be adapted to resolve this issue): Server rules that are out of sequence will not execute. It was assumed that the issue occurred because the rules were set up on different replicas.
SBUR59GPW8: This requested that the maximum number of rules be increased. In Notes Domino 6, the maximum is now 100. For more information on this issue, refer to Document #1091326, "Is There a Limit to the Number of Mail Rules Each User Can Create?"
MGAN5W4VQN: Notates various issues in the mail template code logic that does not properly check to see if the Calendar Configure button was clicked (to enable "MiniView" rules), and thus causes the first mail rule and/or block mail rule to overwrite an existing rule. For more information on this issue, refer to Document #1160706, "Using the Block Sender functionality can internally overwrite previously created rules."
For Notes R6:
In the Rules script library, the following update should be made in the subroutines, ButtonOKClient, ButtonOKWeb and ButtonOKQuick.
Locate the following section of code and add the lines noted:
If note.isnewnote Then ' this is a new rule
' we need a new sequence number
Set viewcollection = view.allentries
If viewcollection.count = 0 Then
If profile.getitemvalue("Use_CalendarRule")(0) = "1" Then
nrulenum=1
Else
nrulenum=0
End If
Else
For Notes R6.5:
In the BlockUserRule script library, Declarations section, update the FindHighestRule function as follows:
If Highest=0 Then 'Remove this line and replace with below:
If Me.m_CalProfile.Use_CalendarRule(0)="1" Then
Highest = Highest + 1
End If
FindHighestRule = Highest
End Function
IV. Workaround for deleted rules that still trigger and rules that are enabled but do not run:
These issues can be worked around using the following steps:
1. Select all of the mail rules that are not enabled and click the Enable Rule(s) action. NOTE: If no rules display in the view, then create one.
2. Click the Disable Rule(s) action.
3. Determine if the Rules OrderNum field values have gaps. If so, they must be reordered.
4. In order to determine a field's OrderNum value, right-click the document, choose the second tab, and find the OrderNum field in the list. The value will be in the right pane.
In R5, the first rule should be 0, the second 1, etc. If there are any gaps, they must be programmatically renumbered.
In R6, the first rule sometimes starts with 0 and sometimes starts with 1. All the following rules should follow in sequence and must be programmatically renumbered if they do not.
In R6 Server Rules, the first rule starts with 0.
5. If the OrderNum field values do not have gaps, enable the rules that you want to be active, or, as necessary, delete the "dummy" rule created in the first step. No other steps are needed at this time.
6. If the OrderNum field values have gaps, proceed below to the agent for reordering the rules.
Agent for reordering the rules:
With all of the rules enabled and then disabled, the following agent can be run to reorder the OrderNum field of the rules. The agent should be created as a Run Once agent in the mail file:
NOTE: The example below is designed to resolve rules issues where the order number is affecting the execution of the rule. Product Support is not available to make further modifications or enhancements to this code.
Dim s As New notessession
Dim db As notesdatabase
Dim rulesfolder As notesview
Dim rules As notesviewentrycollection
Dim rule As notesviewentry
Dim ruledoc As notesdocument
Set db=s.currentdatabase
Set rulesfolder=db.getview("Rules") 'If renumbering Server Rules then change the GetView parameter to "(Server Mail Rules)"
Set rules=rulesfolder.allentries
Set profile=db.GetProfileDocument("CalendarProfile")
'Optional code for User Rules to remove rule entries from the Calendar Profile which did not disable as expected.
'NOTE: A specific workaround and code fix for a Notes R6 issue is noted above in the section titled "Disabled Rules that Still Trigger"
'The code below must be used if you want to simply "clean out" the rule entirely in the profile.
'NOTE: The code below will disable the C&S Miniview rule so it must be manually re-enabled.
'If profile.getitemvalue("Use_CalendarRule")(0) = "1" Then
' profile.Use_CalendarRule = "0"
'End If
'Set Count=profile.getfirstitem("$FilterFormulaCount")
'Call count.remove
'Forall ff In profile.Items
' If ff.type = 1536 And Lcase(Left(ff.name,15)) = "$filterformula_" Then
' Call ff.remove
' End If
'End Forall
'Call profile.Save(True, True)
If profile.getitemvalue("Use_CalendarRule")(0) = "1" Then
number=1
Else
number=0
End If
Set rule=rules.getfirstentry
While Not rule Is Nothing
Set ruledoc=rule.document
ruledoc.ordernum=Cstr(number)
Call ruledoc.save(True, True)
Set rule=rules.getnextentry(rule)
number=number+1
Wend
NOTE: While using the agent above is the recommended procedure by Product Support for handling these issues, if a more straightforward agent is desired, the following approach can be used. However, the use of the agent below results in the complete deletion of the Calendar Profile document. This document is used to save all user settings found under Tools --> Preferences, such as Calendar free time, Alarms, Mail Delegation, Calendar Delegation, and so on. All these settings must be reset by the user manually through the user interface. It is suggested that users review their current settings under Tools --> Preferences and note the settings prior to executing the LotusScript code below.
The following agent sets up a handle to the current user's mail file and deletes the Calendar Profile:
The agent should be set up as a "Run Once" agent in Notes R5 and to run on "None" in Notes R6.
Dim session As New NotesSession
Dim db as NotesDatabase
Dim doc As NotesDocument
maildbinfo = Evaluate(|@MailDbName|)
Set db = session.getdatabase(maildbinfo(0), maildbinfo(1))
Set doc = db.getprofiledocument("CalendarProfile")
Call doc.remove(true)
To avoid these issues in the future:
-- Prior to deleting a rule, always disable it first.
-- When creating a rule, always have it enabled/on. If you do not want the rule enabled, highlight it in the folder and click Disable Rule(s).
-- If using Notes R6.0 or R6.5, make the corrections noted above in the sections, "Rules that are enabled but do not run" and "Disabled rules that still trigger."
An enhancement request was submitted to Quality Engineering as SPR #RWAS547K42, which requests that additional functionality be added to reorder the internal numbering used for rules. There are currently no plans to address this issue in Notes R6 or R5.
V. New mail rules run but do not appear in Rules folder
The cause may be duplicate (Rules) folders, visible only in the Designer client. To check if this is the case, open the mail database in Designer and select Folders to see if there are duplicate Rules folders.
There may be several reasons why there are duplicates, the most common being that a previous version of the folder was not removed if the mail template was upgraded. The outdated folder should be deleted.
Sometimes, "missing" rules will now appear in the remaining Rules folder and sometimes they will not. If they still do not appear, you must create a view that displays all documents with the form, Mailrule, and either drag them into the Rules folder or delete them. If the rules are deleted, you may have to delete the user's Calendar Profile as well.
VI. Background on mail rule functionality:
When a mail rule is enabled, a $FilterFormula_# field is added to the Calendar Profile, where x equals the number of the rule in the list, starting at 0. For example, if you have three rules in your Rules folder, and the 1st and 3rd rules in the list are enabled, the Calendar Profile will have $FilterFormula_0 and $FilterFormula_2. This field has a formula that matches the condition of your rule which is used to perform the rule action when mail is deposited.
When a rule is disabled, the corresponding $FilterFormula_# field is removed from the Calendar Profile.
NOTE: The fact that the $FilterFormula_# field is not deleted when a mail rule is deleted prior to being disabled is the SPR issue discussed above. By design, the $FilterFormula_# entries are not renumbered when a rule is disabled or deleted.
The Calendar Profile also contains a field, $FilterFormulaCount, that should coincide with the total number of rules within the mail file. The $FilterFormulaCount should always be at least one value higher than the highest $FilterFormula_# entry. Otherwise, the rules that fall numerically above $FilterFormulaCount-1 will not run.
For example if $FilterFormulaCount is 4, no $FilterFormula entries above $FilterFormula_3 will be executed. The reason for the offset by 1 is because the $FilterFormulaCount has a starting value of 1 and the $FilterFormula_# entries have a starting value of 0.
NOTE: In Notes R6, the numbering can be slightly different depending on whether the Calendar & Scheduling Configure button has been executed. When you click the C&S Configure button, an additional rule is created and is written to $FilterFormula_0. Any previously existing rules are rewritten to a $FilterFormula_# entry one value higher. For example, $FilterFormula_0 is shifted to $FilterFormula_1, and $FilterFormula_1 is shifted to $FilterFormula_2, and so on. The $FilterFormulaCount value is also incremented by 1. So, in the case where a user clicks the C&S Configure button, the $FilterFormulaCount value is equal to the number of user rules. plus 1.
Sample LotusScript to get a handle to the Calendar Profile document:
You can create a LotusScript agent or button with the following code in order to get a handle to the Calendar Profile. If you enable the LotusScript Debugger (Files --> Tools --> Debug LotusScript), you can step through the code and expand the DOC object, and then the ITEMS array, in order to view the $FilterFormula_# fields and the #FilterFormulaCount field.
Dim session As New NotesSession
Dim db as NotesDatabase
Dim doc As NotesDocument
maildbinfo = Evaluate(|@MailDbName|)
Set db = session.getdatabase(maildbinfo(0), maildbinfo(1))
Set doc = db.getprofiledocument("CalendarProfile")
Thema: Neue Maildatei für User anlegen (Gelesen 4323 mal)