Règles métier : 

• Les règles de comm régissent la visibilité des utilisateurs et groupes => un groupe avec N utilisateurs, mais seulement M visibles par le user qui le consulte ne pourra voir que les M users qui le composent sur les N possibles
• Les règles de comm ne régissent pas la liste des établissements du searchpanel : seuls les établissements de rattachement sont affichés, les établissements indirects d'un groupe manuel ne sont pas proposés, le filtre sur l'établissement est masqué s'il est unitaire
• Les règles de comm ne régissent pas la liste des classes du searchpanel : toutes les classes d'un établissement de rattachement seront listées, même si l'utilisateur n'a pas de users visibles dans ces classes
  • Pour des soucis de performance pour les utilisateurs multi-établissement (souvent des chefs de projets), l'API criteria utilisée par searchpanel user/groupe/favoris a été modifiée pour accepter le paramètre getClassesMonoStructureOnly=true (false par défaut) qui permet de ne remonter la liste des classes seulement dans le cas où l'utilisateur est rattaché à un seul établissement. Un appel à l'API permettant de remonter exclusivement les classes est fait coté front si l'utilisateur choisit le filtre sur les établissements, ce qui va alimenter le filtre sur les classes. Ainsi, les utilisateurs sur un seul établissement ne voient pas de modification du comportement des filtres (select structure masqué, select classes alimenté) et les utilisateur multi-structures vont voir les échanges data réduits et le parsing plus court sauf si un filtre établissement est utilisé
• Le filtre de recherche de l'annuaire comporte des règles de compatibilité des filtres pour les utilisateurs, groupes et favoris, le tableau récapitulatif peut être trouvé ici : Cadrage fonctionnel groupes et partages#Fen%C3%AAtredepartageetfavorisdepartage
• Fiches utilisateurs : 
  • L'association d'un utilisateur à un établissement et aux classes peut être retrouvé dans la fiche utilisateur afin de permettre de "dé-homonymiser" les users (info pour tous profils)
  • Les relations parent-enfant peuvent être retrouvées dans les fiches utilisateurs lorsqu'elles sont consultées par les profils personnel et enseignant afin de permettre de "dé-homonymiser" les users, mais pas fournies aux profils parents ou élèves (sauf dans la fiche mon compte de leurs propres relations) pour ne pas permettre la récupération d'informations non-souhaitables pour ces profils.
  • L'ajout des informations telles que la relation parent-enfant, les classes des parents/enfants, les établissements et classes de rattachement, obligent à utiliser une route normalement restreinte aux ADMC, ADML, enseignants d'un classe (Paramétrage de la Classe) et dans Mon Compte. La route a vu ses droits ouverts pour délivrer des informations minimales et adaptées pour les fiches utilisateurs. L'impact de cette ouverture est que le mail d'un utilisateur peut s'afficher dans l'annuaire dans le cas d'utilisateurs avec des droits étendus (ADML, enseignant de la classe) (mais, ADML peut déjà visualiser ces informations en console). Un paramètre a été ajouté à la config des PF pour masquer, pour les enseignants d'une classe, ces informations sur les fiches des autres personnes de leur classe (en particulier les enseignants entre eux). Suite à cette modification une route spécifique pour paramétrage de la classe a été mise en place
  • Les autres informations sont soumises au droit de publier dans Mon Compte ou à l'utilisation d'une application qui les fournit (Console, Paramétrage de la Classe)
• La gestion de favoris de partage de l'annuaire et du sharepanel est soumise à un droit workflow Directory - directory.allow.sharebookmarks