Verrouillage des activités via API

Objectif de l'article

Cet article explique le fonctionnement du verrouillage granulaire des activités iBAT (modification, suppression, activation), piloté exclusivement via l'API Activities par les clients intégrateurs. Il permet de protéger certaines activités contre des modifications involontaires effectuées par les utilisateurs depuis l'interface front, afin d'éviter les incohérences entre le système tiers de l'intégrateur et iBAT.

Cette fonctionnalité s'adresse principalement aux clients intégrateurs pilotant leurs activités via API et aux utilisateurs ADMIN GROUPE. Les autres utilisateurs de l'interface iBAT sont concernés en tant qu'ils constatent le résultat du verrouillage sur les écrans Société, Direction et Projet.

Au programme de cet article :

• À quoi sert le verrouillage des activités ?
• Profils concernés
• Prérequis
• Comment fonctionne le verrouillage ?
• Ce que voient les utilisateurs dans l'interface
• Bonnes pratiques
• Limites fonctionnelles
• FAQ

🎯 À quoi sert le verrouillage des activités ?

Les clients intégrateurs pilotent la création et la mise à jour de leurs activités depuis leur propre système, via l'API iBAT. Sans mécanisme de verrouillage, rien n'empêche un utilisateur du front iBAT de modifier, supprimer ou (dés)activer une activité gérée depuis le système tiers, ce qui peut créer des incohérences entre les deux systèmes.

Le verrouillage donne aux clients intégrateurs un contrôle fin sur la mutabilité de leurs activités depuis le front, sans qu'il soit nécessaire de développer une interface d'administration dédiée dans iBAT : le pilotage se fait entièrement via l'API.

👥 Profils concernés

✅ Prérequis

Pour poser un verrouillage sur une activité, il faut :

• disposer d'un compte ADMIN GROUPE,
• être authentifié via token pour l'appel API,
• passer par l'API Activities (POST en création ou PATCH en modification).

⚠️ Aucune configuration n'est possible depuis l'interface iBAT : le champ lockedActions n'est pas exposé dans le front, même pour un utilisateur ADMIN GROUPE.

🔒 Comment fonctionne le verrouillage ?

Un champ lockedActions est ajouté à l'API Activities. Il s'agit d'un tableau pouvant contenir une ou plusieurs des valeurs suivantes :

Ces trois verrous sont indépendants les uns des autres : poser un verrou ne bloque pas les actions couvertes par les autres (par exemple, un verrou EDIT seul n'empêche pas l'activation/désactivation).

Par défaut, lockedActions vaut un tableau vide ([]), ce qui correspond au comportement actuel, inchangé, des activités.

Une fois posé, le verrou est appliqué des deux côtés :

• côté back-end : toute tentative de modification (PATCH) sur les champs ou sur le statut d'activation d'une activité verrouillée est refusée (erreur 403) pour tout utilisateur qui n'est pas ADMIN GROUPE ;

• côté front-end : les contrôles correspondants (champs, bouton Supprimer, case Actif, etc.) sont désactivés ou masqués selon l'écran, avec une info-bulle explicative, pour tout utilisateur non-ADMIN GROUPE.

Un utilisateur ADMIN GROUPE (côté interface) n'est jamais impacté par les verrous : tous les contrôles restent actifs pour lui, quel que soit le contenu de lockedActions.

🖥️ Ce que voient les utilisateurs dans l'interface

Le verrouillage s'applique sur les pages Société, Direction et Projet, en vue liste comme en vue création/modification avancée :

Pour un utilisateur non-ADMIN GROUPE, au survol d'un contrôle grisé (vue avancée), une info-bulle affiche : « Vous ne disposez pas des droits suffisants pour effectuer cette action ».

Pour un utilisateur ADMIN GROUPE, aucun rendu de verrouillage n'est affiché : tous les contrôles restent actifs, sans info-bulle.

⚠️ Si lockedActions change côté serveur pendant qu'un utilisateur a déjà chargé une vue, le back refuse l'action tentée et affiche un message d'erreur.

NB : la création manuelle d'une activité depuis le front ne permet pas de positionner lockedActions ; elle reste à [] par défaut.

👍 Bonnes pratiques

✅ Positionner lockedActions de façon cohérente avec l'usage métier : un verrou EDIT seul n'empêche pas l'activation/désactivation, et inversement.

⚠️ Le champ n'étant pilotable que par API, toute demande de verrouillage ou de déverrouillage émanant d'un client doit être redirigée vers son intégrateur technique — aucune action n'est possible côté support ou CSM via l'interface.

⚠️ Un utilisateur non-ADMIN GROUPE qui consulte une activité verrouillée et ne voit pas de bouton « Modifier » ou « Supprimer » ne doit pas interpréter cela comme un bug : il s'agit du comportement attendu.

⛔ Limites fonctionnelles

• Aucune interface d'administration front ne permet de consulter ou modifier lockedActions : le pilotage est exclusivement API.

• Aucun historique ou audit des changements de lockedActions n'est prévu.

❓ FAQ

Un utilisateur ne voit plus le bouton « Modifier » ou « Supprimer » sur une activité, est-ce un bug ? → Non. Si lockedActions contient EDIT ou DELETE pour cette activité, le bouton correspondant est volontairement masqué pour tout utilisateur non-ADMIN GROUPE.

Comment retirer un verrou posé sur une activité ? → Uniquement via un appel API (PATCH) effectué par un utilisateur ADMIN GROUPE. Aucune action n'est possible depuis l'interface iBAT.

Pourquoi un utilisateur ADMIN GROUPE peut-il modifier une activité verrouillée alors qu'un autre utilisateur ne le peut pas ? → Les verrous ne s'appliquent jamais aux utilisateurs ADMIN GROUPE, quel que soit le contenu de lockedActions.

Un verrou EDIT empêche-t-il l'activation/désactivation de l'activité ? → Non, les trois verrous (EDIT, DELETE, ACTIVATE) sont indépendants. Seul un verrou ACTIVATE bloque l'activation/désactivation.

Mots-clés : verrouillage - lockedActions - activité - API - EDIT - DELETE - ACTIVATE - ADMIN GROUPE