le problème que je rencontre est peut-être lié à nos mauvaises pratiques antérieures (dont l’usage du user designer pour développer) mais je constate que depuis l’upgrade en v5 d’une instance, je n’ai plus la main sur les éléments de configuration réalisés par un ancien membre de l’équipe qui est parti depuis.
La seule solution que j’ai trouvée consiste à forcer en base un UPDATE de la colonne created_by de tous les records associés à son login (ou au user designer) avec mon propre login.
Ce problème n’est évidemment pas rencontré si je suis loggué en tant que designer mais uniquement lorsque je me connecte avec mon propre login.
Ce n’est a priori pas un problème d’habilitation (j’ai les responsabilités ADMIN, APP_ADMIN, APP_DESIGNER et DESIGNER ainsi que le paramètre utilisateur ADMIN_SYSTEM=yes et pas de MODULE_FILTER positionné).
Comment est-ce censé fonctionner ? (notamment en cas de turnover dans l’équipe)
ADMIN me semble suffisant sur un user pour lui permettre de tout voir
sans filtrage de module actif
avec ADMIN_SYSTEM=yes pour les érudits pour modifier le socle
donc retirer les autres qui entrent en conflit
Certains groupes que vous avez sur votre profil ont peut être des fonctions avec des règles de visibilité basées sur le “owner” = created by = user login
Par défaut il y a des fonctions qui terminent par “-V” qui limitent la visibilité, mais de mémoire c’est au niveau de l’organisation APP_DESIGNER (tous les users de ce groupe peuvent modifier leur paramétrage uniquement) et pas du Owner :
Avoir des droits ADMIN + APP_DESIGNER n’a pas de sens à mon avis, car les règles de visibilités s’appliquent et designer n’est pas dans le groupe APP_DESIGNER, juste ADMIN.
Bonjour François,
merci beaucoup pour ton retour rapide.
En effet, je vois tout mais les champs de formulaires étaient grisés et les boutons d’actions (save ou autre) n’étaient pas affichés jusqu’à ce que j’update le created_by des éléments de configuration concernés (listes, attributs ou autres codes et traductions) avec mon login.
Une règle de visibilité est soit une search-spec, soit un accès limité à create/update/delete associé à une fonction CRUD de groupe. On s’en sert peu car on préfère souvent coder les search-spec ou les isUpdateEnabled…
Si vous avez mélangé du paramétrage fait par un designer de ADMIN, c’est normal que quelqu’un de APP_DESIGNER ne puissent pas y toucher (cf visibilité des fonctions de ce groupe sur Update et Delete).
Retire tous les groupes à scope réduit de ton user sauf ADMIN.
ou alors (XOR) ne met que APP_DESIGNER = on ne peut modifier ou supprimer qu’une entité créée par quelqu’un de APP_DESIGNER = dans ce cas il faut remettre tous les created_by de votre module sur qq’un de ce groupe
L’option 1) est plus simple si vous avez changé de stratégie en cours de route.
C’était bien ça (mix ADMIN / APP_xxx).
Depuis que j’ai tout retiré sauf ADMIN ça semble OK partout.
Merci beaucoup.
Je vais prendre le temps de vérifier tout ça à tête reposée pour mieux comprendre ces mécanismes et les utiliser correctement.
Nous avons un nouveau cas d’usage de plateforme multi-métier qui fera cohabiter sur le même instance plusieurs équipes avec un besoin de cloisonner logiquement leur éléments de configuration (d’où mes expérimentations hasardeuses).
C’est pareil au niveau des visibilités, il y avait surement une différence de qui a créé quoi par batch/import module et/ou de responsabilité.
Quand on commence à jouer avec les visibilités des fonctions, il faut bien rendre étanche/exclusif les groupes, car si on les cumule il devient compliqué de savoir quelles règles s’appliquent à la fin.
C’est pourquoi on préfère maintenant donner un droit ADMIN et utiliser le filtrage de module pour limiter ce qu’on voit quand on paramètre et éviter les erreurs.
Ok. J’ai vérifié et réaligné tous les éléments de configuration d’un autre module et réaffecté ceux créés par ‘designer’ au dev en charge et ça fonctionne comme attendu (et maintenant je comprends pourquoi). Ce qui bloquait était donc bien lié à l’usage précédent du user designer et au fait que ‘designer’ était owner des éléments de configuration produits avec ce compte.
Tous les dev sur la plateforme devront désormais ne plus utiliser designer (c’est mal) mais uniquement leur propre compte sur lequel j’aurai défini un scope (MODULE_FILTER) qu’ils ne pourront pas changer (ou en tout cas je dois trouver un moyen de limiter ceux qu’ils peuvent choisir). C’était bien le schéma envisagé.
pourquoi). Ce qui bloquait était donc bien lié à l’usage précédent du user designer et au fait que ‘designer’ était owner des éléments de configuration produits avec ce compte.