You are not logged in.
Bonjour,
La gestion des documents à l'énorme avantage de centraliser des informations et de les rendre disponibles à partir de n'importe quel poste de notre réseau informatique.
Le seul hic, à mon sens, est la façon dont ces documents sont stockés sur le serveur GLPI (/glpi/files/TXT). En effet, il est évident que l'on ne peut pas stocker deux documents de même nom même si le contenu de ces documents diffèrent.
Je prends par exemple le module Helpdesk. Il nous est très fréquent de documenter un changement de paramètres ou de configuration par une simple copie d'écran. Le fichier est alors nommé copieecran.jpg et placé dans un dossier partagé par dossier.
Imaginez le nombre de copieecran.jpg que l'on peut générer...
Au lieu de renommer chaque fichier afin d'assurer l'unicité, ne peut-on pas concevoir une gestion de la structure documentaire en créant des dossiers, sous-dossiers par type d'élément, et plus généralement selon son envie et sa façon de structurer les données ?
Par exemple :
TXT
|
|_ Ticket 2035
| |
| |_ Mode opératoire.doc
| |_ Validation.xls
| |_ Copieecran.jpg
|_ Ticket 2235
| |_ Copieecran.jpg
|
|_ Ordinateurs
|_ Ordinateur1
|_ FaxNumérisé.tif
Merci par avance pour vos commentaires.
Arnaud.
GLPI 9.2.1 / FusionInventory 9.2+1.0
Offline
Tout est un problème de convention de nommage...
copieecran.jpg ca n'est pas parlant du tout.
Copie ecran de quoi ? la vous n'avez que la nature de l'objet.
Du style changement de paramètres de firefox moi perso je l'appelerais :
changement_param_firefox_copie_ecran.png
C'est comme dans vos documents sur votre ordi, si tous vos fichiers ont le même nom ce n'est pas tres pratique.
L'archi que vous proposez implique la non unicité du stockage des fichiers.
Un document affecté a plusieurs elements sera dupliqué autant de fois que de lien.
D'ou a terme une perte d'espace plus que conséquente.
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
J'admets volontiers que mon exemple laisse un peu à désirer.
L'archi que vous proposez implique la non unicité du stockage des fichiers.
Oui, effectivement. Il s'agirait de créer des dossiers et sous-dossiers selon la politique documentaire interne ou selon son esprit tordu ;-)
Un document affecté a plusieurs elements sera dupliqué autant de fois que de lien.
Sur ce point là, je ne vois pas pourquoi.
Un document pourrait être lié sans pour autant être dupliqué dans chaque sous-dossier.
Prenons l'exemple suivant :
- Vous avez 2 tickets portant sur une formation utilisateur d'OOo.
- Vous possédez un document nommé FormationUtilisateurOoo.pdf.
- Ce document se trouve dans le dossier /glpi/files/TXT/Documentation/Ooo/.
- Ces deux tickets pourraient avoir un lien vers ce document sans pour autant créer une quelconque copie.
- En revanche, j'aimerais ajouter un document du type VisaFormation.png pour chaque ticket. Et donc avoir la possibilité de créer un dossier pour ces deux tickets afin d'y placer mes deux fichiers au même nom. Emplacement exemple : /glpi/files/TXT/Tickets/Ticket2025 et /glpi/files/TXT/Tickets/Ticket2032.
Il est vrai que je pourrais également les renommer en VisaFormation20061018LambertChristiane.png et VisaFormation20061103DupontRobert.png et les placer dans le même dossier, soit /glpi/files/TXT/ mais cette solution ne m'emballe pas trop.
GLPI 9.2.1 / FusionInventory 9.2+1.0
Offline
Faire des liens ca ne poserai pas de problème si tout le monde utilisait linux mais sous windows le support des liens laisse un peu a désirer.
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Merci tout de même pour votre analyse.
GLPI 9.2.1 / FusionInventory 9.2+1.0
Offline