Règles par entités

Décision Séminaire Juillet 2009
  • Ajout de la récursivité
  • 3 moteurs successifs de règles sur le tickets (entité et récursivité utilisable pour chacun):
    • Affectation d'un ticket à entité (surtout mailgate) (à créer)
    • Business rules
    • SLA (à créer)
  • Ordre de passage : entité racine -> fille (vu que toutes les règles sont jouées)
  • Vision des règles supérieure
    • Ajout d'un droit lecture (oui / non) pour l'affichage des règles supérieures
    • Un onglet pour les règles locales (associées au droit lecture écriture sur les règles métiers)
    • un onglet pour les règles supérieures (associées au droit de lecture oui/non)
  • Attention au niveau optimisation pour ne pas charger les règles plusieurs fois : si changement entité / nécessite rechargement
    • MoYo : c'est à dire ? je ne comprend pas.
  • Mailgate et entité : moteur de règle particulier
    • MoYo : ne serait-il pas intéressant de faire disparaitre l'affectation d'une mailgate à une entité ?
      • MoYo : auto-réponse après interprétation des critères définis plus bas : suppression de la notion d'entité dans les mailgates et transfert dans les règles. Vision des Règles rattachées à une mailgate à afficher dans une nouvel onglet de la mailgate.
      • MoYo : Qui a le droit de créer des mailgates vu qu'on supprime la notion d'entité pour une mailgate ? seulement l'admin ?
    • si pas entités mailgate -> passage dans moteur d'affectation
    • si pas d'entité après moteur -> Stockage des mails bloquées dans une liste (comme mass_ocs_import = visu + import + suppression ) pour correction par l'administrateur et vidée à chaque passage
      • Objet
      • l'émetteur
      • destinataire
      • date
      • mailgate
      • début du corps (pour éviter la surcharge)
      • motif du blocage
        • MoYo : Depuis quel menu est accessible cette liste ?
  • Critères de règles :
    • Mailgate (migration de l'ancien système : une mailgate = une entité)
    • adresse de l'émetteur (commence par... fini par... contient...)
    • adresse du destinataire (comme émetteur)
    • objet
    • corps du mail
    • n'importe quel header (message-ID => référence ticket)
  • Actions de règles :
    • assigner entité
    • assigner entité par domaine (résultat regex)
    • Refuser mail (pas d'import et suppression du mail) (sans motif spam)
    • Refuser mail (pas d'import, suppression du mail et réponse par mail)(avec motif / réponse du refus)
  • Ajouter un champs "domaine" sur l'entité

----
Discussion préalables

Pistes de réflexion :
  • walid : comment ? dans la liste on commence par toutes les règles de l'entité racine, en lecture seule ? ou alors 2 onglets "règles globales/règles par entité" ?
  • moyo : dans l'ordre de passage donc racine -> fille / pour des raisons de lisibilité : peut-être un onglet pour montrer les règles passant avant mais que l'on ne peux pas modifier
- Attention au niveau optimisation pour ne pas charger les règles plusieurs fois : si changement entité / nécessite rechargement
- Mailgate et entité : moteur de règle particulier 
- si pas entités mailgate -> passage dans moteur d'affectation
- si pas d'entité après moteur -> alerte vers administrateur ou refus suivant config
- Délégation de la création des règles aux administrateurs locaux
Walid :
- Critères
  • adresse de l'expéditeur
  • adresse du destinataire
  • lieu de l'émetteur ?
  • groupe de l'émetteur ?