Bug #9194
fermé
L'abonnement d'un utilisateur n'est pas supprimé si ce dernier n'a plus les droits d'accès à l'application
Ajouté par David Lesimple il y a environ 7 ans. Mis à jour il y a environ 5 ans.
100%
Description
Scénario :
1. L'utilisateur est par exemple lecteur d'une application Actualités et s'abonne à celle-ci
2. L'administrateur de cette application lui enlève les droits de lecture
3. Si une actualité est crée dans l'application, alors l'utilisateur reçoit quand même une notification liée à son abonnement
mais ne peut accéder à l'actualité crée faut d'avoir les droits d'accès suffisant.
Reproduit en 5.15.6 et 6.0-SNAPSHOT
Mis à jour par Miguel Moquillon il y a plus de 5 ans
- Statut changé de New à In progress...
- Assigné à mis à Miguel Moquillon
- Version cible mis à Version 6.1
Ce bug touche un certain nombre d'applications autre que QuickInfo.
Dans Kmelia, le bogue n'est pas reproduit. Toutefois, la personne dont les droits d'accès ont été retiré est toujours cité parmi les abonnés à la GED ou au dossier.
Mis à jour par Miguel Moquillon il y a plus de 5 ans
- Statut changé de In progress... à Resolved
Mis à jour par Nicolas Eysseric il y a plus de 5 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Nicolas Eysseric il y a plus de 5 ans
- Statut changé de Integration in progress... à Assigned
Mis à jour par Miguel Moquillon il y a plus de 5 ans
- Statut changé de Assigned à Resolved
Mis à jour par Yohann Chastagnier il y a environ 5 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Yohann Chastagnier il y a environ 5 ans
- Statut changé de Integration in progress... à Assigned
Mis à jour par Yohann Chastagnier il y a environ 5 ans
- Statut changé de Assigned à In progress...
Mis à jour par Yohann Chastagnier il y a environ 5 ans
Lors de l'analyse des PRs à l'intégration, des problématiques fonctionnelles ont été soulevées.
Le travail qui a été réalisé dans les PRs de la note 3 consiste à supprimer les abonnements d'un utilisateur ou d'un groupe sur une instance de composant (application) ou sur des nœuds de l'instance de composant (dossiers de l'application) lorsqu'il n'existe plus de rôle pour l'utilisateur ou le groupe.
Dès lors qu'un rôle est retiré à un utilisateur (ou un groupe), le ou les abonnements de ce dernier liés à l'instance de composant (ou au noeud) sont supprimés.
Par ailleurs, un autre problème a été corrigé dans le cadre de ce REDMINE : les droits d'un utilisateur sur les noeuds d'une instance de composant n'étaient pas supprimés lorsque l'utilisateur n'avaient plus aucun droit au niveau de l'instance de composant.
La logique de ces corrections qui semblent justes au premier abord, posent en réalité quelques problèmes fonctionnels dans Silverpeas, du fait de son actuelle gestion des droits.
Prenons un exemple.
Un utilisateur A a un rôle Rédacteur sur une GED et il a spécifiquement le rôle de Lecteur sur une dizaine de dossier de cette GED.
Par ailleurs, A s'est abonné à une multitude de dossier dans cette GED.
- dans le cas où il affecte dans un premier temps le rôle Publieur à l'utilisateur et qu'il lui retire ensuite celui de Rédacteur, il n'y a pas de problème en particuliers, car à l'instant T, l'utilisateur aura toujours un rôle sur la GED et rien ne sera supprimé au niveau des nœuds ou des abonnements
- dans le cas où il retire d'abord le rôle Rédacteur à l'utilisateur et qu'il lui affecte ensuite celui de Publieur, il y a alors un problème. Entre ces deux actions, le système va considérer que l'utilisateur n'a plus de rôle sur la GED et va supprimer tous les rôles spécifiques sur les dossiers de celle-ci et supprimer tous les abonnements liés de l'utilisateur. Cela ne correspond malheureusement pas à ce qu'est attendu par l'administrateur.
Il n'est pas concevable d'imaginer qu'un administrateur d'une plate-forme Silverpeas soit au fait de cette finesse de gestion.
Le problème soulevé découle finalement de la gestion transactionnelle de l'affectation des droits actuellement en place dans Silverpeas.
En effet, pour passer un utilisateur d'un rôle à un autre, il faut 2 transactions fonctionnelles : un ajout et une suppression. Selon l'ordre dans lequel sont enchaînées ces dernières, des dommages collatéraux peuvent survenir.
Pour palier à cela, il faudrait que la gestion des rôles sur une instance d'un composant ou sur un nœud soit matricielle de sorte qu'il n'existe qu'une seule transaction pour prendre en compte tous les changements de rôle.
Cela représente cependant, notamment dans le cadre d'un BUG et dans le cadre de la version 6.1, un volume de travail trop conséquent et devra être réalisé pour une autre version.
- le service des abonnements sera en mesure de fournir les abonnements utilisateur ou de groupe pour lesquels l'instance de composant (ou ses nœuds) sont réellement accessibles par l'utilisateur ou le groupe.
- lors de l'affectation d'un rôle sur une instance de composant, ou sur un nœud d'une instance de composant, un batch de traitement des modifications des droits est enregistré pour être exécuté dans un délai N (de même pour un rôle retiré). Lorsqu'un tel batch est déjà enregistré et que des rôles sont de nouveau modifiés, le délai est de nouveau repositionné à N. Après un délai N sans modification d'affection de rôle, le système exécute le batch de traitement des modification des droits. Ce dernier permet au différents modules de Silverpeas de pouvoir réajuster l'état de ses données vis-à-vis de l'état des droits. Cela permettra notamment :
- au service de gestion des droits lui-même de supprimer les droits sur les dossiers si nécessaire
- au service des abonnements de supprimer les abonnements pour lesquels l'utilisateur ou le groupe n'a plus accès à la ressource en question.
Mis à jour par Miguel Moquillon il y a environ 5 ans
- Statut changé de In progress... à Resolved
Au regard de la complexité du code à produire nécessaire pour corriger le bug, du fait de la façon dont sont gérés les droits côté IHM, il a été décidé de résoudre le problème différemment, en appréhendant les choses différemment.
La vraie résolution nécessite en fait de mettre en conformité la gestion des droits d'un espace, d'une application ou d'une ressource d'une application (en général un nœud représentant un dossier, une catégorie, ...) dans l'IHM avec le mécanisme de gestion des droits dans le code métier. Ceci sera le cadre d'une prochaine feature pour une version ultérieure de Silverpeas 6.
En attendant, le solution repose sur la vérification des droits de l'abonné (utilisateur ou groupe d'utilisateurs) à accéder à la ressource abonnée aussi bien lors de l'envoie de la notification aux abonnés qu'au niveau de l'affichage des abonnements d'un utilisateur dans son espace personnel. Ainsi, si l'abonné ne peut plus accéder à la ressource pour laquelle il est abonnée lors de la notification aux abonnés, celle-ci ne lui sera pas envoyé. De même, lors de l'affichage de ses abonnements, un abonnement à une ressource qu'il ne peut plus accéder sera grisé et non cliquable ; toutefois, il pourra supprimer celui-ci s'il le souhaite. L'avantage de cette solution est que l'abonnement d'un utilisateur pourra être automatiquement et de façon transparente réactivée dès qu'il a accès à nouveau à la ressource abonnée sans avoir à s'abonner à nouveau. L'inconvénient, et non des moindres, est que ces abonnements inactifs polluent la base de données de Silverpeas et ralentissent la notification des abonnés et l'affichage des abonnements d'un utilisateur. Aussi, il est probable qu'à terme, une fois la feature sur une meilleur gestion des droits côté IHM soit réalisée, ce fonctionnement soit retiré ; les abonnements d'un utilisateur ou d'un groupe pour lequel les droits d'accès ont été retirés seront alors tout simplement supprimés.
Mis à jour par Yohann Chastagnier il y a environ 5 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Marc Avenel il y a environ 5 ans
- GED : CORPORATE > COMMUNICATION > Publications (https://v6.akwel.net/silverpeas/Rkmelia/kmelia1641/Main)
- Dossier : TEST MARC
- Publication: "coucou Marc est ce que ça marche ?" créé le 14/10/2019 et accessible le 15/10/2019
- Abonnement forcé: Marc AVENEL
Mais aussi à l'ensemble des acteurs de la GED
- Ceci est-ce du que la GED est paramétrée de la manière suivante: Notification : Active
Mis à jour par David Lesimple il y a environ 5 ans
Marc Avenel a écrit :
La modification a été apportée Vendredi sur notre serveur "https://v6.akwel.net/silverpeas/admin/jsp/silverpeas-main.jsp"Aujourd'hui : notification a été adressé à Marc AVENEL
- GED : CORPORATE > COMMUNICATION > Publications (https://v6.akwel.net/silverpeas/Rkmelia/kmelia1641/Main)
- Dossier : TEST MARC
- Publication: "coucou Marc est ce que ça marche ?" créé le 14/10/2019 et accessible le 15/10/2019
- Abonnement forcé: Marc AVENEL
Mais aussi à l'ensemble des acteurs de la GED
- Ceci est-ce du que la GED est paramétrée de la manière suivante: Notification : Active
Vous vous êtes trompé de ticket je pense.. ce ne serait pas plutot #10671 ?
Mis à jour par Yohann Chastagnier il y a environ 5 ans
- Statut changé de Integration in progress... à Closed
- % réalisé changé de 0 à 100
Validé et intégré en 6.x