Silverpeas » Silverpeas Core

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

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

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.

Validé et intégré en 5.15.x

• 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

• 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 */
);

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*/
...

Reporté en 6.x

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

% 

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

Validé et intégré.