Copie du chantier precedent

Premiere approche sur la notion de transfer

On part du principe que c'est pour un même utilisateur donc que toutes les dépendances lui restent associées. Donc pas de changement de contact.

  • Conception :

Nouveau sous-menu Transfert dans le menu Outils

- Une page où tu sélectionnes ton pc de départ (-> donc te liste les connexions directes / Connexions réseaux / logiciels / Documents) puis un système de cases à cocher pour sélectionner ce qu'il y a à transférer et le pc d'arrivée, et hop [Transfert]

Bien sûr, au préalable, le pc d'arrivée à été créé ou importé depuis ocs.

Vanb, parlait à juste titre d'une historisation lors d'un transfert. Sauf que pour cela, il faut que l'historisation de tout déplacement/modification de connexions/logiciels/périphériques pour un pc soit déjà fonctionnelle dans l'onglet historique, ce qui n'est pas le cas pour l'instant.

Mais cela pourrait être intéressant.

  • Cas d'un transfert d'un logiciel OEM

bien sûr, si un logiciel est OEM, on ne peut pas le transférer.

  • Page de résultat du transfert
    • Pc de départ / pc d'arrivée
    • Connexions/périphériques/logiciel et licence transférés
    • Connexions/périphériques/logiciel et licence NON transférés

Pour les non-transférés - nouvelle option : quoi faire : Rien ? Supprimer ? Réattribuer ?

C'est une première ébauche. Ne pas hésiter à poursuivre dans la réflexion.

PS : Attention, pour ma part, cette fonctionnalité n'est pas propice à des upgrades de grande envergure, où un module forcément plus complexe doit être étudié.

Autre type de transfert

La problematique ci dessus est dans le but de transferer un element d'un objet à un autre.

Ici c'est un transfert au sens deplacement d'un objet dans un conteneur vers un autre conteneur.

Dans la 0.70, le concept d'entité est une tres bonne facon de cloisonner des informations par rapport à des besoins.
La problematique (d'ou ce chantier) est la notion de transversalité (=transfert).
Un exemple :
  • Un service de hotline gere deux clients différents avec GLPI (donc deux entités).Ces 2 clients achetent les memes postes clients. Ca oblige a faire de la double saisie pour les gabarits... imaginez pour 80 clients.

=>Cette contrainte est extensible à tous les gabarits, les modeles, types, et autres .... s'ils sont identifiés de facon unique par entité (un champ FK_entities dans la table)

ce qui en decoule, c'est qu'a partir d'une objet nous devons pouvoir faire des "deplacer"/"dupliquer".

voila une autre proposition :
  • La notion de deplacer/dupliquer serait une action massive qui nécessiterait le choix d'une entité de destination (avec par defaut l'entité de l'objet source) et le bouton valider.

La vrai problematique est la suivante : que doit on faire dans le cas où il existe des relations entre les objets. Par ex : l'imprimante doit elle suivre quand on deplace l'ordi, que faire de l'ecran,.... le photocopieur réseau (un periphérique) est relié à un switch, on le deconnecte avant de le déplacer ??

Donc : dans le cadre d'une action massive, on ne peut pas poser ce genre de question c'est vite trop complexe. il faut donc trancher : si action massive deplacer/dupliquer, ca serait sans les liens (une analyse plus poussée est peut etre a etudier).
si action individuelle (ex : le dupliquer dans archires) alors il faudra peut etre un formulaire suplémentaire pour prendre en compte les choix de l'utilisateur quant au déplacement des objets reliés.

commentaire: tout en comprenant la contraite technique de cette proposition, c'est la solution la plus dangeureuse pour l'intégrité de la base de onnées qui est proposée. si un transfert massif est demandé , en général c'est comme si une "sous-entité entière bouge . si on doit le faire objet par objet ...
il faut examiner ça de plus près .

Je dirais finalement :
  • que c'est un complément de la premiere approche proposée ci dessus.
  • que cette reflexion doit probablement trouver ses reponses en discutant encore un peu pour connaitre la meilleure facon de faire.

portée du chantier

La notion de transfert prend aussi son importance dans les plugins.
Dans le cadre de ce chantier, ne peut on pas envisager le développement d'une api re utilisable par les plugins.