Gestion des collaborateurs

Invitez des collaborateurs, modifiez leurs droits métier ou révoquez leur accès en conservant leur historique.

Ces routes exigent une clé API autorisée. Une clé gérée doit posséder toutes les autorisations ; settings.write seul ne suffit pas. Les anciennes clés restent acceptées avec les mêmes protections.

Le dernier administrateur, le créateur de l’établissement et les profils protégés ne peuvent pas être supprimés ou privés de leurs droits par ces routes.

Ajouter un utilisateur

requestId est un paramètre POST facultatif de 32 caractères hexadécimaux. Conservez-le pour réessayer la même demande sans créer une autre invitation. L’ancien champ data[password] reste toléré mais est ignoré : aucun mot de passe n’est créé ni envoyé.

La réponse réserve un ID numérique et indique invitationID, state: invited, delivery et version. delivery vaut sent ou failed ; pending peut être retourné lors de la reprise d’une demande interrompue avant l’envoi. Le profil reste inactif jusqu’à confirmation de l’identité et acceptation de l’invitation. Le lien expire après sept jours. La clé à l’origine de l’invitation doit rester active et autorisée jusqu’à son acceptation.

{"success":true,"result":"OK","ID":123,"invitationID":"0123456789abcdef0123456789abcdef","state":"invited","delivery":"sent","version":"1"}

Si delivery vaut failed ou pending, l’invitation existe. Répéter le même requestId retrouve son résultat sans renvoyer le courriel. Après vérification dans la gestion des collaborateurs, utilisez un nouveau requestId pour demander un nouvel envoi. Aucun secret d’acceptation n’est retourné par l’API.

Editer un utilisateur

version est un paramètre POST facultatif permettant de refuser une modification concurrente. Les seuls champs modifiables sont le nom, les droits, le code-barres et l’image. Un mot de passe non vide ou un courriel différent est refusé avec identity_management_required ; un courriel identique est toléré sans modification. Les moyens de connexion se modifient dans la gestion de l’identité.

Un changement de droits invalide les autorisations antérieures du seul profil concerné et incrémente sa version d’accès.

getUsers conserve par défaut ses quatre colonnes : id, nom, droits et codeBarre. codeBarre est toujours une chaîne vide : aucun identifiant de badge NFC ou code-barres de connexion n’est retourné, avec une clé historique ou gérée, en JSON, CSV ou HTML. Utilisez id pour référencer le profil. Les badges déjà émis restent valables et leur ajout ou modification autorisée reste possible avec data[barcode].

Ajoutez includeAccess=1 en GET ou POST pour obtenir aussi state et version sur les profils actifs retournés. Les profils suspendus, en changement, en provisionnement et les invitations non acceptées sont masqués. Les invitations en attente et les accès révoqués se consultent dans la gestion des collaborateurs.

Supprimer un utilisateur

version est un paramètre POST facultatif permettant de détecter une modification concurrente. La réponse indique revoked : le profil est conservé pour l’historique et ses autorisations de connexion sont invalidées.

Les erreurs protected_profile et last_administrator refusent une mutation protégée. En cas de team_changed, rechargez les informations avant de demander une nouvelle validation. Les mutations sont journalisées sans mot de passe ni secret de clé API.

Exemple JavaScript

async function editUser(shopID, key, id, version) { const body = new URLSearchParams({  shopID,  key,  id,  version,  'data[name]': 'Vendeur',  'data[rights]': 'user' }); const res = await fetch('https://kash.click/workers/editUser.php', {  method: 'POST',  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },  body }); const payload = await res.json(); if (!res.ok || !payload.success) throw new Error(payload.error || 'Modification refusée'); return payload;}

Conservez la clé dans votre serveur d’intégration ; ne la publiez pas dans une page accessible à vos clients.