Project

General

Profile

Actions

Feature #7716

closed

Règles de synchronisation

Added by Pierre TEISSONNIERE over 5 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Administration
Start date:
03/29/2016
Due date:
% Done:

100%

Estimated time:
Livraison en TEST:
Livraison en PROD:

Description

Bonjour,

J'ai développé une fonction qui nous est nécessaire. Il s'agit d'une règle de synchronisation qui récupère les utilisateurs des groupes passés en paramètre.
Pour l'instant, ma règle de synchronisation est du style :

PTE_test=4,6

avec les groupes à synchroniser passés en liste séparés par une virgule.

2 questions pour le maître des clés :-) :
Quel préfixe souhaites-tu que l'on utilise (à la place de PTE) ? Je n'ai pas compris la logique des DS_ et DC_ pour pouvoir construire le mien.
Je pense passer un autre argument pour dire si l'on prend ou pas les sous-groupes (recursif ou non). Une idée ? Exemple :

DG_recursive=4
DG_single=4

Etant donné qu'il ne s'agit pas d'une modification structurelle, on peut la mettre en 5.15.2 s'il vous plait ?


Files

groupUpdate_1.png (78.3 KB) groupUpdate_1.png Yohann Chastagnier, 04/15/2016 05:23 PM
groupUpdate_2.png (81.4 KB) groupUpdate_2.png Yohann Chastagnier, 04/15/2016 05:23 PM

Related issues

Has duplicate Silverpeas Core - Feature #6031: Enrichir les règles de synchronisation de groupesClosed11/07/2014

Actions
Actions #1

Updated by Pierre TEISSONNIERE over 5 years ago

  • Tracker changed from Feature to Support
  • Assignee deleted (Nicolas Eysseric)
  • Target version deleted (Version 5.15.2)
  • Navigateur set to Tous
  • Votre version de Silverpeas set to 5.0

Tant que j'y suis, je suis en train de mettre en place quelque chose qui ressemble à la demande de feature #6031. Ce qui me semble le plus logique serait d'utiliser le format LDAP search.

Exemple : (|(&(DC_fonction=Directeur)(DC_ville=Lyon))(DS_AccessLevel=A)) pour obtenir les utilisateurs qui sont Administrateurs ou qui sont directeur à Lyon

Existe-t-il une fonction dans Silverpeas pour parser ce type de chaine de caractères ou bien est-ce que je la code moi-même ?

Je passe le ticket en support (ça me semble plus logique).

Actions #2

Updated by Pierre TEISSONNIERE over 5 years ago

  • % Done changed from 0 to 90

J'ai terminé le code pour ce ticket et le ticket #6031.
Les règles existantes sont toujours valides. On été ajoutées les règles de type LDAP query search avec les opérateurs &, | et !
Pour la règle de groupes multiples, recursive ou pas, il me manque les informations de nommage.

  • Quel préfixe utiliser (à place de PTE) ?
  • Quel argument pour la récursivité après le préfixe ? recursive, simple ?

Peut-être que quelqu'un d'autre que Nicolas peut répondre.

Pour les tests, j'ai importé 10 000 utilisateurs (217 Guests, 543 Administrators, 271 DomainManagers, 8702 Users, 271 KMManagers) répartis dans 10 entreprises.

Cette requête, qui est quand même un peu complexes, (|(&(DS_AccessLevel=A)(DC_company=Entreprise10))(&(!DS_AccessLevel=U)(DC_company=Entreprise1))) renvoit 100 enregistrements en un peu moins d'un seconde.

Un point qui peut être amélioré serait d'augmenter la taille du champ "Règle de synchronisation" au niveau interface et BdD.

Actions #3

Updated by Miguel Moquillon over 5 years ago

Pour les préfixes :
DS pour Données Standard
DC pour Données Complémentaires
Dans ton cas, il serait peut-être plus propre de définir un nouveau préfixe qui indique sur quoi porte la règle. Par exemple DR pour Données de Règles ou PR pour Paramètre de règles.

Quant à ton paramètre de récursivité, si ce dernier signifie bien "récupérer tous les groupes dans l'arbre des sous-groupes jusqu'à une profondeur de n", alors je nommerai le paramètre plutôt comme suit : DC_subgroupsDepth (on sait ainsi à quoi fait référence ce paramètre et qu'il faut le joindre avec le paramètre lié au nom du groupe).
Si, par contre, ton paramètre liste juste les groupes à récupérer et dans quelles conditions (avec les sous-groupes ou non), dans ce cas, oui des paramètres comme :
DC_groups (pour les groupes sans les enfants), et DC_recursiveGroups ou DC_groupsWithSubgroups (pour les groupes avec les sous-groupes) seraient plus judicieux.

Actions #4

Updated by Pierre TEISSONNIERE over 5 years ago

Merci pour les détails. Si je comprend bien, DS pour la table st_user et DC pour la table domainsp_user (ou autre selon le domaine).
Si ça te va, je vais mettre DR_groups et DR_recursiveGroups.

Actions #5

Updated by Pierre TEISSONNIERE over 5 years ago

Traité par PR https://github.com/Silverpeas/Silverpeas-Core/pull/712

Si vous considérez que ça traite bien à 100% la demande du ticket #6031, je vous laisse le clôturer.

Actions #6

Updated by Pierre TEISSONNIERE over 5 years ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100
Actions #7

Updated by Yohann Chastagnier over 5 years ago

  • Tracker changed from Support to Feature
  • Category set to Administration
  • Status changed from Resolved to Integration in progress...
  • Target version set to Version 5.15.2
Actions #8

Updated by Yohann Chastagnier over 5 years ago

Validé et intégré en 5.15.x

Des modifications ont été apportées lors de l'intégration dans le but :
  • d'alléger le code dans la classe de service d'administration
  • d'isoler le traitement de l'évaluation d'une règle de synchronisation d'un groupe et d'ajouter une panoplie de tests unitaires
  • d'ajouter de l'outillage, notamment un mécanisme capable d'évaluer une expression par notation préfixée avec parenthèses
Aussi, la persistance des données a été modifiée de sorte de pouvoir enregistrer des règles plus longues (2000 caractères maximum)
L'écran d'ajout et de modification d'un groupe a également été adapté en conséquence, notamment au niveau de l'aide.
Quelques modifications ont été apportées au niveau de la navigation :
  • suite à la création ou à la mise à jour d'un groupe, l'utilisateur retourne sur la page du groupe en lecture
  • toujours suite à la création ou à une mise à jour, la règle de synchronisation est immédiatement exécutée si cette dernière est bien différente de la valeur précédente
  • affichage du nombre d'utilisateurs dans le groupe et au niveau des sous-groupes
  • le champs description n'est pas affiché en lecture s'il est vide
  • plus de retours d'erreur concernant l'exécution de la règle de synchronisation

Il faut noter également à ce niveau, dans le cas d'une synchronisation d'un groupe qui nécessite un accès vers un serveur LDAP (la règle de base DC_[propriété]=[valeur] engendre en accès LDAP), que le traitement de synchronisation est stoppé dès lors que le serveur LDAP n'est pas accéssible, cela sans que l'ensemble des utilisateurs avant l'exécution du traitement ne soit modifié.

Concernant la mise en place de la nouvelle règle sur les groupes, nous avons opté plutôt pour DR_GroupsWithSubGroups (car la notion de récursivité porte plus sur la technique de récupération des informations).

Pour les règles complexes, nous avons suivi le mécanisme d'une expression par notation préfixée avec parenthèses (qui semble effectivement être la base d'une expression LDAP search). Cela introduit néanmoins une petite différence sur l'opérateur de négation, par rapport à ce qui a été proposé, dans le sens où il doit être utilisé sur une opérande entre parenthèses et pas directement appliqué sur une règle de base.


L'écran de mise à jour d'un groupe se présente maintenant de la manière suivante :



Un petit moteur d'interprétation d'une expression par notation préfixée avec parenthèses a été développé à cette occasion : PrefixedNotationExpressionEngine<T>.
Ce dernier permet à l'appelant de définir ses opérateurs avec leur comportement et de définir comment doivent être converties chaque partie de l'expression.

Un exemple d'initialisation d'une instance de ce moteur :

/*
 Ce moteur est capable d'évaluer des additions, des soustractions ainsi que des multiplications
*/
PrefixedNotationExpressionEngine<Integer> engine = PrefixedNotationExpressionEngine.from(
  (stringToInteger) -> stringToInteger == null || stringToInteger.isEmpty() ? null : Integer.parseInt(stringToInteger), /* convertisseur */
  new OperatorFunction<Integer>("+", (computedValue, newValue) -> computedValue == null ? newValue: (computedValue + newValue)), /* opérateur d'ajout */
  new OperatorFunction<Integer>("-", (computedValue, newValue) -> computedValue == null ? newValue: (computedValue - newValue)), /* opérateur de soustraction */
  new OperatorFunction<Integer>("multiply", (computedValue, newValue) -> computedValue == null ? newValue: (computedValue * newValue)), /* opérateur de multiplication */
);

Quelques exemples d'expressions que le moteur précédemment initialisé peut évaluer :
engine.evaluate("-(+(+(3)(4))(multiply(-5)(2)))(10)"); /*le résultat est -13*/
engine.evaluate("-(+(3)(4))(+(-2)(4))"); /*le résultat est 5*/
engine.evaluate("+(+(3)(4))(+(-(5))(2))"); /*le résultat est 14*/
engine.evaluate("+(+(3)(4))(+(-5)(2))"); /*le résultat est 4*/
...

Actions #9

Updated by Yohann Chastagnier over 5 years ago

  • Status changed from V6 pending to Closed

Reporté en 6.x

Actions #10

Updated by Nicolas Eysseric about 5 years ago

  • Has duplicate Feature #6031: Enrichir les règles de synchronisation de groupes added
Actions #11

Updated by Yohann Chastagnier almost 3 years ago

  • Status changed from Closed to Resolved
  • Assignee set to Yohann Chastagnier
  • Target version changed from Version 5.15.2 to Version 6.1

Il est désormais possible d'utiliser le caractère spécial

% 
dans [valeur] de la clause
DC_[propriété] = [valeur] 

Ce caractère permet d'inidiquer aucun caractère ou n'importe quelle séquence de caractère (comme l'opérateur like dans le language SQL).
La casse est ignorée.
Pour échapper le caractère spécial, il faut le précéder du caractère [ \ ].

Par exemple : DC_title=responsable% permet de filtrer les comptes utilisateurs dont le titre commence par responsable (Responsable communication, Responsable production, etc.).

PR : https://github.com/Silverpeas/Silverpeas-Core/pull/954

Actions #12

Updated by Nicolas Eysseric almost 3 years ago

  • Status changed from Resolved to Closed

Validé et intégré.

Actions

Also available in: Atom PDF