Contexte

Objectif : répondre à l'attente des organismes fonctionnant en multi-entité de
pouvoir utiliser
certaines données à tous les niveaux.

Description :
  • ajouter la notion de récursivité sur les fiches contact / contrat / fournisseur.
  • Proposition / gestion des droits :
    • le création/modification d'objet récursif n'est autorisé que pour les utilisateurs de l'entité mère disposant d'un droit récursif
    • les utilisateurs des entités filles ne disposent que du droit en lecture (et d'utilisation)
  • ajouter la notion de notes globales (publiques et récursives)

Chantier en cours

Tables concernées

Actuellement :
  • glpi_contact (terminé)
  • glpi-contract (en terminé)
  • glpi_docs (terminé)
  • glpi_enterprises (terminé)
  • base de connaissance (terminé)
A etudier :
  • certaines dropdown
  • gabarits
  • groupes

Evolution de la base de données

Pour les tables concernées, ajout d'un champ recursive (0/1) et ajout au tableau $CFG_GLPIrecursive_type (index = type, valeur = nom de la table)

Prise en compte dans les fonctions

  • getEntitiesRestrictRequest : ajout de l'argument recursive qui permet d'étendre la recherche des enregistrements avec recursive=1 dans les entités mères.
  • dropdown, dropdownValue, dropdownContract : gestion automatique pour les tables concernées, avant classement des objets par entités (optgroup).
  • countElementsInTableForEntity, countElementsInTableForMyEntities : gestion automatique
  • getEntitySons permet d'avoir le tableau des fils d'une entité, par exemple lorsqu'on cherche à lier des éléments à un objet récursif

Gestion des droits

  • dans les formulaires principaux des objects concernés

La fonction haveRight ne peut plus être utilisée car il est possible d'accèder à la fiche d'un objet récursif d'une entité supérieure qu'on ne peut donc pas modifier, exemple :

La méthode*canEditAndRecurs* retourne 2 booléens : $canedit : droit de mise à jour et $canrecu : droit de créer des objets récursifs (il faut disposer d'un profil récursif sur l'entité courante).

list($can_edit,$can_recu)=$this->canEditAndRecurs();

La méthode*canEdit* retourne un champ de bits avec 1 pour droit de mise à jour et 2 pour droit de créer des objets récursifs.

$can_edit=$this->canEdit();

  • dans le traitement des actions de mises à jour

La fonction checkRight ne peut plus être uitilisée.

La fonction checkEditItem permet de vérifier si l'utilisateur courant peut modifier un objet donné, exemple :

checkEditItem(CONTACT_TYPE, $_POST[[ID]]);

  • pour les tables liées

Lors de l'initialisation des dropdowns, il faut appliquer la restriction d'entité uniquement pour les objets non récursifs (ancien comportement). Un objet étant visible dans les sous-entités, il peut être attaché a des objets de ces sous-entités.

Exemple :

if ($contact->fields[[recursive]]) {
    dropdown("glpi_enterprises","entID",1,getEntitySons($contact->fields[[FK_entities]]),$used);
} else {
    dropdown("glpi_enterprises","entID",1,$contact->fields[[FK_entities]],$used);
}

Lors de l'affichage d'une liste d'objets liés, il faut ajouter le filtre sur les entités gérées car il peut exister des relations vers des objets d'autres entités, non visible par l'utilisateur courant (on ne peut plus considérer que 2 objets liés sont dans la même entité).

  • remarques :

Un utilisateur normal ne peut pas ajouter un contact local à un fournisseur global, c'est normal, il ne peut pas modifier ce fournisseur.

Par contre il peut attaché ce fournisseur global depuis la fiche du contact local, il a le droit de modifier ce contact et d'utiliser ce fournisseur.

Attention aux appels croisés d'un formulaire sur l'autre dans le contrôle des droits. Par exemple le formulaire "contract" est utilisé depuis l'écran des équipements. Pour que cela fonctionne il faut contrôler les droits sur l'équipement (et pas sur le contrat).

Transfert

Certaines liaisons reste valables dans la nouvelle entité.

Première passe : simulateTransfer

Pour les types récursifs, on ajoute à la liste needtobe_transfer :
  • les objets non récursifs
  • les objets récursifs non visible dans l'entité destination.

On pourra créer une nouvelle liste noneedtobe_transfer contenant les objets récursifs pour éviter de ré-évaluer leur visibilité lors du second passage.

Seconde passe : transferItem

On modifie le calcul de $canbetransfer pour les types récursifs :
  • les objets non récursifs : On vérifie l'existence de liaison vers des objets non transférés
  • les objets récursifs : On doit vérifier que tous les objets (non transférés) conserve la visibilité de l'objet transféré.

On pourra rechercher les liaisons avec "ID NOT IN needtobe_transfer AND ID NOT IN noneedtobe_transfer"

  • Dans le cas d'un transfert par copie, suppression de la propriété recursive ? (tous les objets transférés sont dans la même entité) : on garde l'objet identique : fait.
  • Dans le cas de la suppression des liens, est-ce qu'on supprime aussi les liens vers les objets récursifs ? (ceux qui restent valable dans la nouvelle entité) : on supprime : fait.

Cas particulier

les Notes

  • les notes ne sont pas vraiement des objets récursifs car la gestion des droits est différente (public/privé).

Le nouveau type de note "global" (global = public + recursif) permet de créer des notes visibles dans toutes les entités.

La base de connaissance

  • Cas particulier de l'accès anonyme.
    Hypothèse Commentaires
    1 Pas de FAQ anonyme en mode multi-entité Simple à gérer
    2 un utilisateur anonyme ne verra que les articles "faq" de l'entité racine Cela implique que c'est le droit le plus élevé qui permet ce type de publication
    3 une entité spéciale (configurable, "entité racine" par défaut) contenant les articles de la FAQ accessible en accès anonyme. Cette solution permettant de déléguer simplement la gestion du contenu. Mais il ne serait pas logique que les utilisateurs authentifiés n'est pas accès à cette partie de la FAQ (donc l'entité racine reste probablement le meilleur choix)
    4 Accès anonyme concerne uniquement les tickets visibles par tous les utilisateurs = Entité racine + Récursif Relativement juste

JMD : Ma préférence va vers le 1 ou 4

Remi : le 4

Mooo pour la KB je suis aussi pour le 4

Donc on retient la 4 : fait.