Bug #13477
ferméPartage de fichiers sur une publication raccourci
0%
Description
Si un utilisateur a accès a un raccourci de publication et qu'il n'a pas accès à la publication d'origine (multi-emplacements).
Alors le partage des fichiers ne fonctionne pas.
PS : reporduit en 6.4 également
Mis à jour par David Lesimple il y a 10 mois
- Version cible changé de Version 6.4.1 à Version 6.4.2
Mis à jour par David Lesimple il y a 8 mois
Mis à jour par Marc Avenel il y a 7 mois
Sera corrigé en 6.4.2.
C'est çà.
On installera la 6.4.2 car une version par an chez nous
Mis à jour par David Lesimple il y a 5 mois
- Version cible changé de Version 6.4.2 à Version 6.4.3
Mis à jour par Miguel Moquillon il y a 25 jours
- soit une GED G1 pour qui le partage de fichiers est activé pour tous les utilisateurs (par exemple)
- soit un utilisateur U1 qui a accès à cette GED G1 dans laquelle est présente le raccourcis R d'une publication P présente dans une autre GED G2 auquel n'a pas accès cet utilisateur U1
- U1 n'a pas la possibilité de demander, avec R dans G1, à partager ni la publication P1 référencé par R, ni les documents attachés à cette publication
- un autre utilisateur U2 qui a accès à la publication P d'origine dans la GED G2 peut demander, avec R dans G1, à partager la publication P1 référencé par R ou les documents attachés à P1.
- soit personne ne peut partager une publication par son raccourcis
- soit tout le monde ayant le profil d'utilisateurs pour qui le partage est autorisé doit pouvoir partager les publications référencés par les raccourcis
Le 1 est plus sécure en contraignant le partage qu'aux publications originales ; ça évite de la part de la personne à l'origine du raccourcis une perte de contrôle par le biais du mécanisme de partage de publication ou de fichier : il veut donner accès à la publication à des utilisateurs qui n'y ont pas accès mais pas nécessairement à l'extérieur ou à d'autres utilisateurs n'ayant pas accès ni au raccourcis, ni à la publication ; le mécanisme de partage deviendrait alors un moyen de contourner le mécanisme de protection des publications.
Quel est le comportement souhaité ici ?
Mis à jour par Aurore Allibe il y a 25 jours
Mon raisonnement :
Si un utilisateur choisit d'exposer via un raccourcis une publication c'est dans le but qu'elle soit traitée de la même façon que ses publications sœurs au sein de cette ged de destination... ( sur le spectre de la consultation)
Soit comportement 2.
Mis à jour par Miguel Moquillon il y a 25 jours
Aurore Allibe a écrit (#note-10):
Pour précision, les raccourcis ne sont pas vraiment traités de la même manière que les publications. Par exemple :Mon raisonnement :
Si un utilisateur choisit d'exposer via un raccourcis une publication c'est dans le but qu'elle soit traitée de la même façon que ses publications sœurs au sein de cette ged de destination... ( sur le spectre de la consultation)
Soit comportement 2.
- elle ne peut pas être modifiée (autrement dit la publication ne peut pas être modifiée par ses raccourcis)
- elle ne peut pas être supprimée
Mis à jour par Sebastien Vuillet il y a 25 jours
C'est discutable.
A minima bloquer la fonctionnalité de partage sur une publication raccourci.
Mis à jour par David Lesimple il y a 24 jours
Comme le dit Aurore, l'idéal serait que le raccourci offre les mêmes fonctionnalités au lecteur que sur la publication originale (notifier, lire les fichiers, etc et donc partager la publication ou ses fichiers).
Maintenant, je pense qu'il faut aller au plus simple, et le choix 2. ne me gêne pas plus que ça.
En résumé, si la charge de travail est à peu près la même sur les 2 solutions, je préfère la 1.
Sinon, la 2. fera l'affaire aussi, à savoir: Sur une publication accédée en raccourci, le partage de celle-ci et/ou de ses fichiers ne doit pas être autorisé.
Mis à jour par Miguel Moquillon il y a 22 jours
- Statut changé de Feedback à Resolved
Le plus simple a été de réaliser le choix 1 : les raccourcis ne sont pas sujets au partage.
Cf PR https://github.com/Silverpeas/Silverpeas-Core/pull/1396
Mis à jour par Miguel Moquillon il y a 18 jours
- Statut changé de Resolved à Closed
Intégrée dans les branches 6.4.x et master