Désormais avec création de pages par IA via le serveur MCP

Compte

Ce que votre offre accorde, quelles limites sont appliquées, et comment les rôles décident qui peut quoi.

Un espace de travail porte une offre, un ensemble de limites et une liste de membres. Les trois sont lisibles par programme, ce qui vaut la peine de les comprendre plutôt que de les découvrir au mauvais moment.

Offre et limites

Chaque espace déclare son offre et les plafonds associés :

{
  "name": "Acme",
  "slug": "acme",
  "plan": "enterprise",
  "limits": {
    "maxPages": 999999,
    "maxMembers": 999999,
    "maxWorkspaces": 999999,
    "maxStorageMb": 999999,
    "maxAiTokensMonth": 999999,
    "maxApiRequestsMonth": 999999999,
    "maxBandwidthGbMonth": 999999,
    "canRemoveBranding": true,
    "canUseCart": true
  }
}

Ces chiffres proviennent d'un espace de travail enterprise, où les plafonds sont fixés assez haut pour être pratiquement illimités. Les offres plus petites renvoient des valeurs réelles - c'est bien pour cela qu'on les lit au lieu de coder une hypothèse en dur.

Deux natures de choses y cohabitent. Les plafonds - pages, membres, stockage, jetons IA, requêtes API, bande passante - sont des quantités épuisables. Les drapeaux de capacité - canRemoveBranding, canUseCart - sont des fonctionnalités actives ou non.

Lisez-les plutôt que de les supposer. Une étape de build qui crée des pages, ou un script qui envoie des médias en masse, devrait connaître le plafond sous lequel il travaille.

La limite de diffusion échoue de façon trompeuse

Dépassez le quota mensuel de diffusion et public.siteConfig cesse de répondre. Votre site se comporte alors exactement comme si le slug de l'espace était faux ou le réseau coupé.

C'est pourquoi le preflight de cmssy link distingue les trois cas au lieu d'un seul « espace injoignable ». Si votre site ne charge soudain plus rien et que rien n'a changé dans la configuration, vérifiez la consommation avant le DNS.

Rôles

Les permissions suivent la forme ressource:action - pages:view, media:upload, forms:submissions:manage, workspace:billing. Un rôle est un paquet nommé de permissions.

Les rôles portent deux drapeaux à connaître :

  • isSystem - intégré et non modifiable. Owner est le rôle système et détient * : toutes les permissions, y compris futures. C'est tout l'intérêt du joker - une nouvelle fonctionnalité n'oblige pas à mettre le rôle à jour.
  • isDefault - le rôle reçu par les nouveaux membres. Définissez-le délibérément : ce qu'il contient est ce qu'accorde une invitation avant toute relecture.

Rôles d'équipe et rôles de membres sont distincts

Un espace peut contenir un rôle sans aucune permission, souvent nommé Customer. Ce n'est pas une erreur de configuration.

Les membres du site qui se connectent à votre site public ne sont pas les personnes qui l'éditent. Un rôle de membre sert à étiqueter et regrouper ces visiteurs ; il n'accorde rien dans l'espace de travail, car un client de votre boutique n'a rien à faire dans votre CMS. Les rôles d'équipe accordent des droits ; les rôles de membres identifient des audiences.

Confondre les deux, c'est ainsi qu'un rôle client obtient discrètement pages:edit.

La granularité est voulue

La liste sépare des choses qu'on attendrait groupées. pages:edit et pages:publish sont distinctes - on peut laisser écrire sans laisser publier. forms:view et forms:submissions:view sont distinctes - construire un formulaire de contact n'exige pas de lire ce que les gens y ont envoyé.

Prenez cette séparation au sérieux en composant vos rôles. La tentation est de distribuer des espaces de noms entiers, et dès lors « peut modifier les textes » et « peut lire les messages clients » deviennent la même attribution.

Étapes suivantes