Console équipe et installations

Deux espaces et deux identités

app.kelna.fr est l’application des restaurants. console.kelna.fr est réservée à l’équipe Kelna. Les comptes, audiences de session, cookies et permissions plateforme sont séparés des accès gérants. Un compte équipe ne devient pas membre client.

L’API console n’expose aucune route de salle ou de jumelage public. Les routes /api/platform/* existent seulement sur le serveur console. Les routes communes /api/account et /api/auth/* y utilisent l’audience plateforme ; l’activation d’un lien équipe doit se faire sur la console.

Préparer un restaurant

1. Activer le compte équipe sur invitation de l’opérateur serveur, puis configurer la double authentification et conserver les codes de secours.
2. Préparer un lien gérant dans la console. Le remettre par un canal privé ; aucun e-mail n’est envoyé automatiquement. Le gérant active son compte et MFA dans l’application.
3. Créer le client avec ce Propriétaire et son premier établissement. Ajouter les autres établissements du groupe si nécessaire.
4. Importer un plan JSON (64 Kio maximum) et ses seuils. Vérifier son contenu avant publication. Les dispositions fictives servent uniquement aux essais.
5. Créer un code tablette ou passe et le saisir sur l’appareil concerné. Pour deux vues sur un ordinateur, utiliser deux profils de navigateur distincts.

Permissions et journal

Chaque lecture ou modification de données client est journalisée. Les écritures exigent une session de moins de quinze minutes : se reconnecter quand la console le demande. Les actions sont limitées par platform.read, platform.provision, platform.plans, platform.devices et platform.invite.

Les liens et codes restent en mémoire du navigateur, sans stockage local ni journalisation. Le rôle API n’a pas d’accès direct aux comptes plateforme. Leur attribution relève de l’opérateur serveur.

Versions et réponses perdues

Créer un client ou un établissement avec un UUID fourni par l’appelant. L’import de plan utilise id, expectedVersion et plan. Après une réponse perdue, reprendre le même identifiant et le même contenu ; un identifiant repris pour une autre demande est refusé.

Un conflit de version impose de relire le dernier plan et de vérifier le brouillon. Un service ouvert conserve son plan et ses seuils ; la nouvelle version s’applique au suivant. Les reprises de lien gérant et de code appareil émettent un nouveau secret, avec leur durée de validité propre.

Plusieurs VM, une API centrale

Préparer un client fictif par restaurant à isoler et une VM distincte par restaurant. Les VM servent de postes clients et n’hébergent pas une copie de la base Kelna. Utiliser un profil pour la tablette et un autre pour le passe ; chaque profil est associé par son propre code.

Ouvrir des services simultanés, vérifier que les actions restent dans leur restaurant, couper le réseau d’une seule VM et révoquer un seul appareil. En phase 1, le passe ouvert conserve son dernier état en mémoire avec le badge hors ligne ; les nouvelles actions attendent le réseau. Le boîtier et les caméras ne sont pas nécessaires.

La console prépare ces scénarios ; elle ne crée ni n’administre les machines virtuelles. L’instance actuelle reste réservée aux données fictives.