Délégation et gouvernance de la cartographie — quels besoins ?

[dbarzin]

Plusieurs discussions ont mis en évidence un besoin récurrent : le rôle "Cartographe" avait été introduit précisément pour permettre de déléguer la gestion d'une application et de ses objets liés à une personne responsable. Cette fonctionnalité a finalement été abandonnée faute d'un modèle de droits cohérent, mais la question de fond reste entière.

Je voudrais ouvrir un espace de discussion plus large sur le sujet, parce que c'est un vrai enjeu de gouvernance pour les organisations qui utilisent Mercator à grande échelle.

Les besoins que j'entends régulièrement :

1. Délégation de la cartographie
   Plutôt qu'un administrateur unique gérant l'ensemble de la cartographie, certaines organisations souhaitent confier à des responsables métier ou techniques la mise à jour des objets qui les concernent — une application et ses services associés, une zone réseau, un ensemble de serveurs. Comment tu gères ça aujourd'hui ? Tu passes par l'admin, ou tu as contourné le problème autrement ?

2. Processus de revue régulière
   La cartographie vieillit vite. Certains ont besoin d'un mécanisme pour déclencher des revues périodiques des objets (date de dernière vérification, statut "à valider", workflow de validation…). Est-ce que c'est un besoin que tu as ? À quelle fréquence tu devrais revalider tes objets ?

3. Droits d'accès granulaires
   Aujourd'hui les droits dans Mercator sont globaux par type d'objet. Le besoin qui remonte, c'est de pouvoir restreindre ou déléguer l'accès à un sous-ensemble d'objets — par application, par domaine, par entité organisationnelle — en lien avec des rôles ou des utilisateurs spécifiques. Jusqu'où tu penses que cette granularité devrait aller ?

Avant de partir dans une direction sans savoir ce qui correspond vraiment aux usages du terrain. Si tu as un avis, un besoin concret, ou une idée sur comment implémenter ça, partage-le ici.

[Olm666]

Bonjour Didier,
Tout d'abord merci pour le travail que tu effectues sur Mercator. À mon sens, c'est un modèle à suivre !
Nous avons entamé un travail d'intégration de notre SI dans mercator. Si les actifs réseaux, serveurs physiques et virtuels, certificats sont facilement importés depuis notre source de vérité via l'API, il en va autrement pour les applications !
Nous avons soumis un tableau Excel à nos collègues informaticiens pour qu'ils y saisissent les données relatives à leurs applications. Nous allons donc bientôt importer 350 applications qui devront être complétées par leurs référents dans Mercator.

1. En première approche, nous avons créé un rôle assez proche du « Cartographe » qui leur permettra de mettre à jour uniquement certains objets de la vue des applications.
2. Nous avons également prévu de gérer le besoin de revue périodique par des moyens organisationnels. La possibilité de générer des rappels directement dans l'application serait une vraie valeur ajoutée (on peut imaginer des rappels répétés, une procédure d'acquittement…).
3. Nous souhaiterions évidemment pouvoir déléguer la possibilité de modifier une application à ses seuls responsables, sans avoir à leur donner cet accès à toutes les applications !

Merci encore pour cette formidable application ! ❤️

[Fabien-Rocher]

Bonjour Didier,
Je suis un collègue d'Olivier et dans cet échange je plussoie sur ce que dit Olivier mais je me permets de rajouter un élément qui pourrait aider dans l'étude de votre approche.
Comme le disait Olivier nous allons confier à chaque responsable d'application la gestion de la mise à jour de la fiche des applications qu'il a en gestion dans son portefeuille et organiser des campagne de rappel de mise à jour. En outre, nous avons positionné chaque responsable (technique ou fonctionnel) dans le champ "Responsable" de la fiche application. Il serait intéressant que ce champ permette automatiquement d'autoriser ses responsable à en modifier la fiche (en plus des admin bien sûr) ce qui nous assureraient de ne pas avoir de droits de modification sur une application pour laquelle on est pas en responsabilité (sauf à avoir un droit spécifique qui surpasserait cette limitation)
A toi de voir.
Par ailleurs, je ne sais pas si c'est déjà le cas, mais comme responsable de service, je serai intéressé de pouvoir faire une cartographie des applications gérées par chaque responsable afin de répartir les suppléances et les responsabilités, équilibrer un peu mieux la charge de chacun... Est-ce déjà existant et dans ce cas peux-tu m'indiquer la marche à suivre stp. Est-ce que les personnes sont des "objets" Mercator comme les serveurs ou les applications ?
Et sinon est-ce une amélioration envisagée ?
Enfin, bravo pour tout ce travail !

[lynch4fr]

Bonjour,
Suite à la Newsletter de ce mois et à l'arrivée prochaine de la fonctionnalité "Cartographe" le retour... :-)
Je voulais ajouter une proposition. Celle de pouvoir recevoir une notification pour l'administrateur quand une fiche "application" est modifiée ? Ou pourquoi pas une chaîne de validation avant que la modification prenne effet, il faudrait que l’administrateur l'approuve ?
Hâte de tester cette nouvelle fonctionnalité. Merci.

[dbarzin]

Voici déjà la documentation. Ce sera disponible dans les prochains jours :

Les Cartographes dans Mercator

Les cartographes sont les responsables de la mise à jour et de la fiabilité de la cartographie du système d'information. Cette documentation explique leur rôle, leurs droits et les outils mis à leur disposition.

Introduction — Qu'est-ce qu'un cartographe ?

Un cartographe est un utilisateur de Mercator à qui l'on a confié la responsabilité d'un ou plusieurs objets de la cartographie : un serveur, une application, un réseau, un site, etc.

Concrètement, être cartographe d'un objet signifie :

• être responsable de la qualité et de l'exactitude des informations qui le décrivent,
• avoir les droits nécessaires pour consulter et modifier cet objet,
• être notifié lorsqu'une mise à jour est attendue.

Le système des cartographes permet de déléguer finement la maintenance de la cartographie aux personnes les plus proches du terrain, sans leur ouvrir l'ensemble de la cartographie du système d'information.

!!! info "Un cartographe n'est pas un administrateur"
Le rôle de cartographe est limité aux objets qui lui sont explicitement assignés. Il ne donne pas accès à l'ensemble de la cartographie ni aux fonctions d'administration de Mercator.

Gestion des cartographes

Qui peut assigner un cartographe ?

Seuls les utilisateurs disposant des permissions de gestion des cartographes au travers d'un rôle spécifique peuvent assigner des cartographes. Cette opération se réalise depuis l'interface de configuration de Mercator.

Assigner un cartographe (interface d'administration)

L'assignation se fait depuis le menu Configuration → Cartographes.

Pour assigner un cartographe à un objet :

1. Accéder au menu Administration → Cartographes.
2. Cliquer sur Nouveau.
3. Sélectionner l'utilisateur (ou le rôle) à désigner comme cartographe.
4. Choisir le type d'objet concerné (ex. : Serveur logique, Application, Réseau…).
5. Sélectionner l'objet précis dans la liste.
6. Valider.

Il est possible d'assigner plusieurs cartographes au même objet, et un même utilisateur peut être cartographe de plusieurs objets.

!!! tip "Assigner un rôle plutôt qu'un utilisateur"
Il est possible d'assigner un rôle comme cartographe d'un objet. Tous les utilisateurs ayant ce rôle bénéficieront alors des mêmes droits sur cet objet. Cela facilite la gestion lors des changements d'équipe.

Ce que permet le rôle de cartographe

Accès en lecture à ses objets

Un cartographe peut consulter tous les objets qui lui sont assignés, même si son rôle habituel ne lui donne pas accès à cette catégorie d'objets.

Par exemple, un utilisateur sans accès aux réseaux pourra consulter les fiches des réseaux dont il est cartographe.

Modification de ses objets

Un cartographe peut modifier les fiches des objets qui lui sont assignés : mise à jour des informations, ajout de relations, correction de données…

Les modifications sont tracées dans le journal d'audit de Mercator, comme toute autre modification.

Ce qui reste hors de portée

Le rôle de cartographe ne donne pas accès à :

• la création ou la suppression d'objets (sauf si l'utilisateur dispose d'un rôle le permettant par ailleurs),
• les objets qui ne lui ont pas été explicitement assignés,
• les fonctions d'administration de Mercator (gestion des utilisateurs, des rôles, de la configuration…),
• les rapports et exports globaux réservés aux administrateurs.

Visualiser ses objets assignés

Tableau de bord

Le tableau de bord de Mercator affiche uniquement les objets auxquels l'utilisateur a accès via son rôle, ainsi que les objets dont il est cartographe. Il n'y a pas de vue dédiée aux objets assignés : le tableau de bord reflète naturellement le périmètre du cartographe.

Filtrage dans les listes

Dans les listes d'objets (serveurs, applications, réseaux…), un cartographe ne voit que les objets dont il est cartographe et les objets auxquels il a accès via son rôle.

Recevoir des notifications

Mercator peut envoyer des notifications aux cartographes par e-mail pour les tenir informés de l'état de leurs objets.

Rappels périodiques pour maintenir la cartographie à jour

Un rappel périodique peut être configuré par l'administrateur pour inciter les cartographes à vérifier et mettre à jour leurs fiches. Ce rappel indique :

• les objets dont le cartographe est responsable,
• un lien direct vers chaque fiche dans Mercator.

La fréquence des rappels (hebdomadaire, mensuelle…) et le contenu du message sont définis par l'administrateur dans Administration → Configuration → Notifications.

!!! note "Pas de rappel si aucune configuration n'est définie"
Les rappels ne sont envoyés que si l'administrateur a activé et configuré cette fonctionnalité. En l'absence de configuration, aucun e-mail n'est envoyé.

Notification lors d'une modification par un autre cartographe

Lorsqu'un objet est modifié par un utilisateur autre que vous, Mercator peut vous envoyer une notification pour vous en informer. Cette notification précise :

• quel objet a été modifié,
• quels champs ont changé,
• qui a effectué la modification.

Cela permet à plusieurs cartographes d'un même objet de rester synchronisés.

Bonnes pratiques de cartographie

Maintenir ses fiches à jour

La valeur d'une cartographie repose entièrement sur la fiabilité et la fraîcheur des données. En tant que cartographe, il est recommandé de :

• vérifier régulièrement les informations de ses objets, notamment après un changement en production,
• compléter les champs vides dès que l'information est disponible,
• ne pas attendre le rappel automatique pour effectuer une mise à jour si un changement est connu.

Signaler une anomalie ou un changement

Si un objet dont vous êtes cartographe évolue significativement (décommissionnement, changement de nom, migration…), il est important de :

• mettre à jour la fiche dans Mercator sans délai,
• contacter l'administrateur si une action hors de votre portée est nécessaire (suppression, fusion d'objets, changement de catégorie…).

!!! warning "Un objet obsolète est une fausse information"
Une fiche non mise à jour peut induire en erreur d'autres utilisateurs ou fausser les analyses de sécurité. La mise à jour est une responsabilité à part entière du cartographe.

[oliboub]

Bonjour Didier,

Whoua, quel boulot. Ca semble vraiment très alléchant et complet.

L'affectation par rôle, est vraiment super.

Quelques questions comme ça:

Tableau de bord
Le tableau de bord de Mercator affiche uniquement les objets auxquels l'utilisateur a accès via son rôle, ainsi que les objets dont il est cartographe. Il n'y a pas de vue dédiée aux objets assignés : le tableau de bord reflète naturellement le périmètre du cartographe.

Filtrage dans les listes
Dans les listes d'objets (serveurs, applications, réseaux…), un cartographe peut filtrer l'affichage pour ne voir que ses objets. Ce filtre est accessible en haut de chaque liste via le bouton Mes objets.

Pourquoi ajouter un filtrage, si le cartographe ne peut voir que ses informations?

. Est-ce que les api GET et PUT fonctionnent, en affichant et modifiant que les informations du cartographe?

. Est-ce qu'il existe des rapports et des possibilités de requêtes pour:
. Un cartographe avoir la liste exhaustive des ses objets par catégories

• Un administrateur avoir la liste de tous les objets associés aux cartographes

• Un administrateur, voir la liste des objets non assignés aux cartographes

• Est-ce que les rôles peuvent aussi être administrés par un rôle?
  exemple, un manager défini les personnes de son équipe qui mettront à jour leur périmètre. Donc si une personne arrive ou quitte l'équipe, il a l''autonomie et la responsabilité de gestion.

  Merci
  Olivier

[dbarzin]

Quelques questions comme ça:

Pourquoi ajouter un filtrage, si le cartographe ne peut voir que ses informations?

Ce filtrage dans les listes a finalement été supprimé. Si l'utilisateur peut voir tous les objets, il peut être utile de pouvoir identifier les objets dont il est cartographe. On va sans doute ajouter un sous-menu dans les options pour cela.

. Est-ce que les api GET et PUT fonctionnent, en affichant et modifiant que les informations du cartographe?

Oui, les API vérifient également les droits d'accès des cartographes, comme l'explorateur, l'analyse des dépendances et le moteur de requêtes.

. Est-ce qu'il existe des rapports et des possibilités de requêtes pour: . Un cartographe avoir la liste exhaustive des ses objets par catégories

* Un administrateur avoir la liste de tous les objets associés aux cartographes

Ces informations sont disponibles au travers de la liste des utilisateurs et dans la liste des cartographes.

* Un administrateur, voir la liste des objets non assignés aux cartographes

Ce rapport n'existe pas.

* Est-ce que les rôles peuvent aussi être administrés par un rôle?
  exemple, un manager défini les personnes de son équipe qui mettront à jour leur périmètre. Donc si une personne arrive ou quitte l'équipe, il a l''autonomie et la responsabilité de gestion.

Ce serait possible de l'ajouter.

[dbarzin]

🎉 La gestion des cartographes est disponible dans la branche dev.

Ne pas oublier de faire composer install, php artisan migrate et ajouter dans le fichier .env ces entrées pour Laravel 13 :

SESSION_COOKIE=mercator_session
CACHE_PREFIX=mercator_cache_

[oliboub]

Bonjour Didier,
Merci. Comment préfères tu qu'on te remonte les retours d'expériences ou les modif? Dans ce chat ou un autre?
Ca semble très prometteur, mais ça va nécessiter des tests..

Premiers retours à chaud:

1. Potentiellement, Le role cartographer par défaut devrait être vide par défaut, sinon on peut voir toutes les applications si on l'attache à un utilisateur (ça prête à confusion)

2. Quand on associe un droit sur une cartographie, par exemple un bloc applicatif ou un processus, pourrait-on avoir une case à cocher pour "inheritance" ou arborescence totale? (par exemple) et avec bonus, choisir les types d'objets?

• je sais que ça va etre compliqué..

3. dans la création d'une cartographie, la liste des type d'objets est un peut difficile à appréhender, car ça doit etre un ordre alphabétique basé sur l'anglais? peut-etre recatégoriser

4. J'ai noté que quand on change le role d'un user dans utilisateurs, il faut aussi changer le mot de passe. Ca peut générer des problèmes. à voir.

5. Si on créé un rôle, il prends tous les éléments du type d'objet. Comment filtrer sur une famille comme par exemple RH,

Et un grand merci pour ton travail
Olivier

[dbarzin]

Je prépare la doc api et data model. J'attends votre analyse sur le point de Est-ce qu'il serait envisageable pour cartographie afin d"éviter d'en créer 1 par objet et par role et/ou par user

Option, pour l'api cartographers, et la cohésion d'ensemble, ce serait un plus que chaque cartographie ait un name..

Cette API est déjà disponible.

L'api est disponible, mais il n'y a pas de name ni description pour chaque cartographie. ça aiderait à la gestion.

Le nom du rôle ou de l'utilisateur suffit à identifier une association dans la table des cartographes — ajouter un name et une description par ligne alourdirait le modèle sans gain réel.

Si le besoin est de regrouper plusieurs objets sous une même "vue cartographique" nommée, ça ressemble davantage à une notion de périmètre ou de groupe — ce serait un objet à part entière, pas un attribut de l'association. C'est une piste qu'on peut creuser si c'est vraiment le besoin sous-jacent. Le modèle pourra encore évoluer par la suite.

[oliboub]

OK, pas de soucis.. je propose ..

[oliboub]

Juste pour rappel, il manque la colonne deleted_at..

[dbarzin]

C'est disponible.

[oliboub]

Merci. ça fonctionne.

[oliboub]

Je continue..

il y a une coquille dans le menu outils sur requetes (en admin):

Sur la partie utilisateur avec un rôle ayant des cartographies e accès aux outils dans le role:
On n'a pas de filtre sur les cartes. Il peut voir toutes les cartes et leur contenus si on a autorisé le list et show dans son rôle.
Alors que pour les requêtes il ne voit que les requêtes partagées.

[dbarzin]

Le label est corrigé.

Peux-tu réexpliquer le second point ?

[oliboub]

Oui, bien sur.
Si je veux que un utilisateur puisse voir uniquement une carte dédiée (dans outils) , je ne peux pas le définir.

• Cartes n'est pas un objet ou un type d'objet
• Cartes est défini par le role outils --> Cartes avec list et show, donc c'est tout ou rien.
  Il faudrait qu'on puisse donner aux équipes , par exemple RH, accès à leur carte si elle existe.
  Donc un granularité aussi sur les outils ( cartes, queries...)
  J'espère etre plus clair..
  Olivier

[dbarzin]

Les outils sont accessibles si l'utilisateur a la permission tools_access.
Les schémas BPMN et les cartes sont accessibles si l'utilisateur a la permission graph_access
L'exploration et les dépendances si explore_access
Les requêtes si query_access
et enfin les rapports si reports_access

[lynch4fr]

carte

Ton idée @oliboub de donner aux équipe uniquement l'accès à leurs cartes est interessante, ce principe peut aussi etre étendu pour les cartes BPMN. Je ne m'y connais pas beaucoup mais le nouvel outil "cartographe" sur un objet "carte" pourrait repondre au besoin. Bonne journée

[lynch4fr]

Bonjour,
J'ai un bug d'affichage " cruds.logicalServer.fields.backups " qui me fait penser au tien. Il se produit quand je souhaite modifier un "Serveur logique"

Merci (je suis en version Open Source Version 2026.05.30 )

[dbarzin]

Corrigé, mais évite de mélanger les sujets.

[oliboub]

DOC:

Dans la doc tu mets Configuration --> Cartographe et dans le menu Configuration --> Cartographie.
Personnellement je préfère cartographe car cartographie prête à confusion..

Il faudrait ajouter une partie sur la règle entre Roles et règle de cartographes.
C'est un OU
Si on sélectionne par exemple applications --> list ; quelque soit les règles de cartographes, on verra toutes les applications.

Donc conseiller un rôle vide par défaut.

Le fait d'avoir une règle par objet c'est pénalisant et ça fait beaucoup de lignes: exemples si beaucoup d'opérations ou de process pour un métier. (mais je l'ai déjà remonté)

---

Il faudrait ajouter, pour le moment, que ces règles ne s'applique que aux objets et types d'objets, pas aux outils.. (sauf si vous trouvez une manière de filtrer)

Globalement, ça marche bien. J'ai testé aussi l'api, et toutes mes règles sont maintenant créées à partir d'un json..
Je n'ai pas testé les notifications, j'ai toujours des soucis avec les mails..

[oliboub]

Point droits d'accès:

Il faudrait ajouter, pour le moment, que ces règles ne s'applique que aux objets et types d'objets, pas aux outils.. (sauf si vous trouvez une manière de filtrer)

Cela s'applique également aux outils: exploration, dépendance et requêtes respectent les filtres en place.

Je ne pense pas, car on n'a pas de type d'objet requete ou carte. La seule manière d'y accéder c'est par les permissions des roles, donc tout ou rien.
Docnporu ces 2 cas de figures, on n'a pas la possibilité de granularité. à chosir la ou les cartes visibles , ou la ou les requêtes

Pour les reqsuetes, on peu tle smetre publique sou privées, c'est déjà une possibilité, masi globale.

Pour exploration ou dépendances c'est pas grave , car on n' a pas de listes sauvegardées à l'inverse de cartes et de requetes.

[oliboub]

Bonjour Didier,
Merci pour la prise en compte des variables:

Dans le champs de corp du mail de notification de changement, peut-on avoir des variables du type log ou json avec :
{
"object_type" : "{object_type},
"name: "{name}",
"Description": "{Description}",
"champ modifié" : [ "avant", ""après"]
"user": "user"
}

Enfin c'est un exemple, mais avec possibilité de choisir les champs et le format?

C'est un détail, dans le résultat, je pense qu'l manque les retours à la ligne pour le mail:
Configuration:

Résultat ( mailtrap)
Name: RH-Solution User: toto Mail: carto_rh@gmail.com Objet modifié: Application object_id: 6 URL de l'objet: http://localhost:8081/admin/applications/6 URL de l'historique: http://localhost:8081/admin/audit-logs/history/App%5CModels%5CApplication/6 Modifications: name Date et heure de la modification: :timestamp

Et: :timestamp n'est pas transposé.

[dbarzin]

Le mail est au format HTML, il faut ajouter des <br> pour avoir des retours à la ligne.

[oliboub]

Merci, je m'en doutais un peut.. Mais c'est bien de l'avori écrit.

[dbarzin]

Pour le champ timestamp, c'est corrigé.

[oliboub]

Et en enhancement:
Prévoir une vue cartographe, car vu le nombre d'entréés dans la liste, ça va être difficile à gérer
exemple incomplet sur un role ( démo)

Merci
Olivier

[dbarzin]

Il est possible de filtrer avec le champ "search" et de trier le résultat.

[oliboub]

Merci, j'ai vu.
J'étais passé à coté. Peut-etre aussi l'ajouter dans la documentation pour éviter des questions..

[oliboub]

one more:
J'ai affecté des entités à un cartographe, Pour les voir dans la vue Entités, il faut ajouter dans le roles: Relations :list et show, car ce n'est pas un objet.
(peut-etre à ajouter dans la doc)

D'autre part, dans la vue Ecosystème on ne voit pas les icones:

J'ai ajouté les roles documents list et show au cas ou, mais c'est pareil..

Dans les lignes, sous le graph, on voit toutes les relations, même si elle n'apparaissent pas dans le graph, car les objets ne sont pas visibles..

[dbarzin]

one more: J'ai affecté des entités à un cartographe, Pour les voir dans la vue Entités, il faut ajouter dans le roles: Relations :list et show, car ce n'est pas un objet. (peut-etre à ajouter dans la doc)

Les relations ont été ajoutées dans les objets cartographiés.

D'autre part, dans la vue Ecosystème on ne voit pas les icones:

C'est corrigé.

J'ai ajouté les roles documents list et show au cas ou, mais c'est pareil..

Dans les lignes, sous le graph, on voit toutes les relations, même si elle n'apparaissent pas dans le graph, car les objets ne sont pas visibles..

[oliboub]

Merci. C'est OK.

[oliboub]

Petit point supplémentaire:

Les relations ont été ajoutées dans les objets cartographiés.
On a bien les relations dans la vue Ecosystème, c'est parfait.

Mais ça affiche le menu Relations à l'utilisateur
Si on clique dessus on a une erreur 403

[oliboub]

Petite demande d'enhancement:
Possibilité de dupliquer les roles?

Si on défini un role par défaut pour les cartographes, avec par exemples : documents, relations, ce serait bien de pouvoir s'en servir comme template pour créer les autres..

ce serait bien aussi d'avoir l'api "permission_roles" (avec la liste des 334 permisisons :) )

[dbarzin]

Petite demande d'enhancement: Possibilité de dupliquer les roles?

C'est disponible.

Si on défini un role par défaut pour les cartographes, avec par exemples : documents, relations, ce serait bien de pouvoir s'en servir comme template pour créer les autres..

ce serait bien aussi d'avoir l'api "permission_roles" (avec la liste des 334 permisisons :) )

Une API renvoie la liste des permissions et il est possible d'assigner des permissions aux rôles via l'API des rôles.

[oliboub]

[ Petite demande d'enhancement: Possibilité de dupliquer les roles?

C'est disponible.

**Merci. **, ça foncitonne.
Il faudrait peut-être l'ajouter dans la doc, car il faut rentrer dans le rôle que l'on veut copier, pour pouvoir le copier. Ce n'est pas dans les boutons de la liste ( afficher, modifier, suppprimer)

[oliboub]

Pour l'api je vais re tester, et si besoin j'ouvrirais une nouvelle discussion à part.

[oliboub]

Bonjour,

Sur les GET api endpoints:
Si je fais un get sur un type d'objet ou j'ai le droit sur *UN ou plusieurs objets, il me renvoi TOUS les objets.

TOKEN=$(curl -s -X POST http://localhost:8081/api/login -H "Content-Type: application/json" -d '{"login": "rh_toto", "password": "toto"}' | jq -r '.access_token') ; echo $TOKEN

curl -s -X GET http://localhost:8081/api/entities  -H "Authorization: Bearer ${TOKEN}" | jq | grep name
    "name": "Mon Entité",
    "name": "CLOUD-PROVIDER-X",
    "name": "LOGISTIX-PARTNER",
    "name": "SOC-EXTERNAL",
    "name": "SAP",
    "name": "Ressources Humaines",
    "name": "Ressources Humaines France",
    "name": "Ressources Humaines Espagne",
    "name": "Ressources Humaines Allemagne",
    "name": "Finance",
    "name": "Achats et Logistique",
    "name": "Production",
    "name": "DSI",
    "name": "RSSI",
    "name": "Filiales Europe",
    "name": "Filiale - Allemagne",
    "name": "Filiale - Espagne",

[dbarzin]

Sur les GET api endpoints: Si je fais un get sur un type d'objet ou j'ai le droit sur *UN ou plusieurs objets, il me renvoi TOUS les objets.

Le filtre sur les objets cartographiés a été ajouté.

[oliboub]

Merci, ça fonctionne.

[oliboub]

Bonjour,

Je détecte un soucis de mise à jour de la date de modification.
Si je créé une entrée dans cartographie par API:
Faite le 06/06 à 8h43
curl -s -X POST http://localhost:8081/api/cartographers -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" -d '{"cartographiable_type": "App\Models\Process", "cartographiable_id": 2, "user_id": 2 }'

La date de mise à jour est hier soir.

Idem si je le créé à la main8h47 :

Idée: La date semble être figée à la date de création de la base?

[dbarzin]

La date affichée dans cette liste est la date de mise à jour de l'objet, pas la date de mise à jour du droit de cartographie.

[oliboub]

OK, merci pour l'info, c'est logique une fois dit. Etant concentré dans la création et la recherche des droits, j'étais focus sur les règles.. Peut-etre le mettre dans le titre de la colonne: dernière modification d'objet.

[dbarzin]

Fait

[oliboub]

Merci. c'est top.

[oliboub]

Bonjour,
J'ai un soucis avec la toute dernière versions de dev, mais ça peut être de mon coté.
Le test des mails fonctionnent mais aucun envoi n'est fait en cas de modification par un cartographe
J'ai bien activé l'envoi d'alerte

D'après les tests d'hier, j'en avais bien reçu 1.
Mais comme j'avais mis du texte dans la description, je n'avais pas les infos décrites dans la doc.

Peux-tu vérifier ceci par rapport à la doc?

Notification lors d'une modification par un autre cartographe
Lorsqu'un objet est modifié par un utilisateur autre que vous, Mercator peut vous envoyer une notification pour vous en informer. Cette notification précise :

quel objet a été modifié,
quels champs ont changé,
qui a effectué la modification.
Cela permet à plusieurs cartographes d'un même objet de rester synchronisés.

Merci

[dbarzin]

Ce problème est corrigé. Exécute php artisan cache:clear après la mise à jour du code.

[oliboub]

Bonjour Didier,
Merci, ça fonctionne nickel..

[oliboub]

Hello,

Un nouveau petit soucis .
Sur le role carto j'ai mis:

mais sur les cartes on n'a pas le bouton créer:

Et une remarque:
Il n'y pas de règles pour BPMN. Il est mis par défaut si on active outils..

[oliboub]

Bonjour DIdier,
Je ne sais pas si tu l'as vu celui ci:
Sur les cartes on n'a pas le bouton créer:
Malgré List, show, create, edit sur outils / Cartes

[dbarzin]

Ce problème est corrigé : a0038da

[oliboub]

Merci, c'est OK..

[oliboub]

Une autre proposition d'enhancement, mais à voir.
Maintenant qu'il va y avoir des utilisateurs de mercator, il faudrait peut-être un moyen d’avoir les infos de l'utilisateur pour l'ouvertture d'un ticket au jhelp desk.
Les infos: login, user, user mail, roles, cartographe

Soit dans le menu aide, info
Ou un bouton au dessus de la version mercator ( en bas à gauche) qui ouvre une fenêtre avec les infos utilisateur.

[dbarzin]

On va ajouter une page "info" avec des informations sur Mercator, l'environnement et l'utilisateur sans dévoiler des informations techniques sensibles, comme les versions de dépendances, les chemins du système de fichiers ou la configuration serveur, afin de ne pas offrir de surface d'attaque supplémentaire à un attaquant ayant accès à l'interface.

[oliboub]

Excellent. Merci

[dbarzin]

🎉 La délégation est disponible dans Mercator !

[oliboub]

👏👏👏👏👏

[dbarzin]

L'écran d'assignation de la gestion de la cartographie aux rôles et utilisateurs a été amélioré.

[oliboub]

Bonjour Didier,

Merci, c'est plus facile à gérer, mais la iste reste longue..
Est-ce que à l'affichage de la liste, au lieu d'avoir une ligne par droit, tu ne pourrais pas faire comme pour la liste des roles? tous les objets dans un champs? comme maintenant on peut modifier tousles objets d'un cartographe au meme endroit?

Par contre les roles exploration, dépendances, requetes et rapports ont disparus à la création.

Nouvelle idée: dans exploration, comme on peut ajouter et supprimer objet par objet,on pourrait avoir une exploration d'un perimètre défini et avoir un bouton pour ajouter l'ensemble affiché dans un cartographe. Ca permet aussi de visualiser le résultat de ce que l'on partage.

[dbarzin]

Merci, c'est plus facile à gérer, mais la liste reste longue.. Est-ce que à l'affichage de la liste, au lieu d'avoir une ligne par droit, tu ne pourrais pas faire comme pour la liste des roles? tous les objets dans un champs? comme maintenant on peut modifier tousles objets d'un cartographe au meme endroit?

J'ai pensé à cela mais alors on ne peut plus voir la date et heure de dernière modification de l'objet, ni avoir un lien vers l'historique.

**Par contre les roles exploration, dépendances, requetes et rapports ont disparus à la création.

Ce sera corrigé rapidement.

Nouvelle idée: dans exploration, comme on peut ajouter et supprimer objet par objet,on pourrait avoir une exploration d'un perimètre défini et avoir un bouton pour ajouter l'ensemble affiché dans un cartographe. Ca permet aussi de visualiser le résultat de ce que l'on partage.

Bonne idée, on retient cela.

[dbarzin]

Les permissions manquantes lors de la création d'un rôle ont été ajoutées : 7349605

[oliboub]

Merci, pour l'explication et la correction.