DominoArea.org [Archive]

Bonjour à tous,
J'ai quelques utilisateurs domino web access qui se sont créés une règle de redirection de leurs messages vers une autre adresse internet, automatiquement. Aujourd'hui, ils souhaitent supprimer cette règle, mais nous n'y arrivons pas. Nous sommes en domino 6.51 (serveur et client). ce qui est "marrant" c'est qu'en tant qu'admin, lorsque j'ouvre leur base mail, sur mon serveur, je ne vois aucune règle de redirection Par contre, dans les logs, il apparait bien "Message auto forwarded by..." chaque fois qu'ils reçoivent un memo.
Si quelqu'un d'entre vous a une idée, car je sèche.
merci à tous.

n'as tu pas plutôt un agent qui tourne dans leur base mail??

Bonjour,

Quand vous ouvrez le dossier (Rules) de leurs bases sous Designer vous êtes sur qu'il n'y à rien ?

Bonjour,

J'ai eu le même soucis avec un utilisateur, qui n'avais plus de régles dans sa base, et pourtant elles continuaient de tourner ...

En fouillant dans les KBs de Notes, j'ai trouvé une technote spécifaint de supprimer le docs profils avec un agent, dont voici le code :

Code : Tout sélectionner

Sub Initialize
   Dim session As New NotesSession
   Dim db As NotesDatabase
   Dim doc As NotesDocument
'   maildbinfo = Evaluate(|@MailDbName|)
   Set db = session.CurrentDatabase
   Set doc = db.getprofiledocument("CalendarProfile")
   Call doc.remove(True)
End Sub

L'inconvénient est que l'utilisateur perd ses préférences (signature ...), mais ça marche ...

@+

Sylvain

L'usager a surement détruit le document règle sans la désactiver au préalable.

Via NotesPeek tu pourrais les voir.


Au lieu de détruire le calendar profile, voici un bouton que tu pourrais envoyer à tes usagers pour qu'ils l'exécutent avec le client lourd:

Sub Click(Source As Button)
Dim session As New NotesSession
Dim db As NotesDatabase
Dim workspace As New NotesUIWorkspace
Dim folder As NotesView

Set db = session.currentdatabase
Set folder = db.GetView("(Rules)")

'Trouver le document "(Calendar profile)" dans la base
Dim calendarProfile As NotesDocument
Set calendarProfile = db.GetProfileDocument( "CalendarProfile" )

'LEs règles sont conpilés dans un champs nommé $FilterFormula_xx xx représente un OrderNum
'On retire les champs du "(Calendar profile)"
Forall item In calendarProfile.Items
If( Lcase$(Left$(item.Name,15)) = "$filterformula_" ) Then
Print "Cleanup " & item.Name
Call item.Remove
End If
End Forall

'Enregistrer les changements du "(Calendar profile)"
Call calendarProfile.Save( False, False )

'Désactiver toutes les règles visibles ou non.
Dim mailrule As NotesDocument
Set mailrule = folder.GetFirstDocument
While Not( mailrule Is Nothing )
Call mailrule.ReplaceItemValue( "Enable","0" )
Call mailrule.Save( True,False,True )

Set mailrule = folder.GetNextDocument( mailrule )
Wend

'Ouvrir le dossier Règles poru que l'usager réactive seulement celle qui sont nécessaires
Call workspace.OpenDatabase( db.Server, db.FilePath, "(Rules)" )

Messagebox "Mise-à-jour terminée, veuillez réactiver les règles s'il y a lieu."
End Sub







Voici une note en anglais qui explique bien le fonctionnement des règles:




To allow users to use Mail Rules:
Edit the Server document. The "allowed to use monitors" field should be set to * or should list the users allowed to use Mail Rules.

NOTE: Mail Rules have nothing whatsoever to do with Agents. Users do not need the ability to run agents on the server to use Mail Rules.


Mail Router
Just before a new email is saved in the mail database, the Router task on the server looks at the CalendarProfile document stored in that database. This
special document has hidden fields called $FilterFormula_xx.

Note that the individual "Mailrule" documents are not used by the Mail Router. Only the CalendarProfile is used. It's therefore possible that the CalendarProfile document may not reflect the individual Mailrule documents found in the database. For example, if you paste a Mailrule document in to the database, the CalendarProfile document is not updated, and the Mailrule document has no effect.


Mailrule documents
Each user's mail database contains a Folder called Rules. This will usually only contain documents created with the form "Mailrule". Keep in mind that this is a Folder and not a View. (Iris should change this to a View.) If there are other documents in this Folder, then the CalendarProfile may get an invalid $FilterFormula.

The Mailrule form calculates two hidden fields that are stored on all Mailrule documents: $FilterFormula and OrderNum. When the user clicks the Enable/Disable Rule(s) buttons, the CalendarProfile document is updated. Each Mailrule document is identified on the CalendarProfile as $FilterFormula_OrderNum.

If the user did a copy&paste of an existing Mailrule document, then there will be two Mailrule documents with the same value for the OrderNum field. When the CalendarProfile is updated, each Mailrule document will try to store their information in the same $FilterFormula_OrderNum field. One Mailrule document is therefore not added to the CalendarProfile. To correct this problem, use the MoveUp and MoveDown buttons (this changes the OrderNum field). This will ensure that all Mailrule documents have a unique OrderNum field.

If you're having trouble with Mailrules that are not working, or deleted Mailrules that are still being evaluated by the Mail Router, then remember:
1) The Mail Router looks at the CalendarProfile document only.
2) To recompute the CalendarProfile's $FilterFormula_xx fields, select all Mailrule documents in the folder and click the Disable Rule(s) button, then select all Mailrule documents again and click the Enable Rule(s) button. It's a good idea to use the MoveUp MoveDown buttons to make sure each Mailrule document has a unique OrderNum value.

Mailrules that MoveToFolder or CopyToFolder, store that folder's UNID as part of the $FilterFormula. You should therefore never paste a Mailrule from one database to another.


if you delete a Rule document in the mail file, before disabling it, the calendar profile still has the field that stores the compiled version of that Rule, so it still runs

Si vous ne parvenez pas à supprimer les règles dans le document profil, vous avez aussi la possibilité de bloquer toutes les règles utilisateur de type redirection via le document de configuration du serveur (en R6.53) :

il faut ouvrir le names.nsf et allez chercher le document de configuration.
Editer le document et allez dans l'onglet Router/SMTP / Restrictions and Controls / Delivery Controls.
Sélectionner Disabled dans le champ User rules mal Forwarding.

et voilà même si les utilisateurs font des règles de redirection, elles ne fonctionneront plus..

Bonjour à tous et merci beaucoup pour votre aide. J'ai utilisé l'agent préconisé par l'un d'entre vous, et cela a bien fonctionné. J'ai du demander l'aide d'un copain développeur, car je n'y connais en dév, mais cela marche.
Encore merci.

Si vous ne parvenez pas à supprimer les règles dans le document profil, vous avez aussi la possibilité de bloquer toutes les règles utilisateur de type redirection via le document de configuration du serveur (en R6.53) :

il faut ouvrir le names.nsf et allez chercher le document de configuration.
Editer le document et allez dans l'onglet Router/SMTP / Restrictions and Controls / Delivery Controls.
Sélectionner Disabled dans le champ User rules mal Forwarding.

et voilà même si les utilisateurs font des règles de redirection, elles ne fonctionneront plus..


Est-il possible possible de restreinte un groupe d'utilisateur???