nous avons un soucis avec l’utilisation de la fonctionnalité “Messages partagés”.
Les utilisateurs mettent des infos sur leurs demandes, en pensant que c’est confidentiel et uniquement lié à leur connexion et à ceux qui ont accès à leurs demandes.
Nous voulons donc supprimer cette fonctionnalité.
J’ai vu que le paramètre USE_SOCIAL a disparu, alors qu’il aurait été bien utile.
J’ai l’impression que la seule solution est de supprimer la responsabilité “SOCIAL_USER” aux utilisateurs mais il faut le faire à chaque création de compte et l’automatiser dans le platformHooks avec un removeResponsibility
j’ai testé mais les temps de réponse à la connexion sont de ce fait beaucoup trop long.
quelle est la meilleure solution pour traiter ce point ?
La responsabilité sur le groupe SOCIAl_USER n’est pas donnée “automatiquement” lors de la création d’un user.
Si un user nouvellement créé a accès aux fonctions sociales c’est soit que vous lui donnez explicitement cette responsabilité, soit que ce groupe fait partie du profil d’un autre groupe présent dans ses responsabilités.
Je ne sais pas ce que ça signifie exactement, mais si une responsabilité est ajoutée c’est sans doute lié à ce que vous avez mis en place via platform hook ou via paramétrage (ex: si on parle de Crowd).
@Francois est-ce qu’il y aurait une subtilité par rapport à ce groupe SOCIAL_USER dans la mécanique de synchro de groupes Crowd ?
Il doit donc s’agir de votre configuration de synchro KeyCloak.
Je vais laisser @Francois prendre la main car je ne connais pas bien cette mécanique mais il me semble que c’est une logique de mapping entre un “profil” KeyCloak et une liste de groupes Simplicité, le SOCIAL_USER doit donc être défini à ce niveau (ou alors, comme dit précédement, il est obtenu indirectement via un profil d’un autre groupe ou par héritage de groupe)
PS: @Francois je voulais bien dire “KeyCloack” pas “Crowd” dans ma réponse précédente
Et notamment USER_SYNC_GROUPS_FORCED
qui ajoute des groupes à la création du compte (via keycloak ou toute autre synchro USER_SYNC=true). Il doit contenir SOCIAL_USER, il suffit de l’enlever.
USE_SOCIAL faisait double emploi, ça a été retiré.
mais gardé dans la session pour compat ascendante au logon si jamais du code spécifique en avait besoin :
// Social access: backward compatibility USE_SOCIAL
g.setFlagParameter("USE_SOCIAL",
g.hasResponsibility("SOCIAL_USER") || g.hasResponsibility("SOCIAL_ADMIN"));
il y a un effet de bord est que en supprimant la responsabilité SOCIAL_USER :
je fait des search pour récupérer des données dans l’objet user et ça ne fonctionne plus.
on dirait que supprimer SOCIAL_USER supprime aussi les droits sur user
Je pense que tu perds la lecture seule sur User si elle n’est pas donnée par ailleurs dans un profil métier qui en a besoin. La fonction sociale en a besoin pour chercher/mentionner des users dans les posts.
Ajoute la fonction “USR-L” aux groupes métiers qui ont besoin de chercher des users.
ou ajoute le droit localement juste dans le code qui y accède (via grant.changeAccess).
