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

Propriétés utilisateur

Des champs personnalisés stockés sur vos utilisateurs, groupés en propriétés nommées, avec un mappage schema.org optionnel.

Les modèles décrivent vos contenus. Les propriétés décrivent vos personnes - les champs personnalisés stockés sur les utilisateurs au-delà du nom et de l'e-mail.

Vous les trouverez dans l'espace de travail sous Paramètres → User Properties. L'écran lui-même s'intitule Custom Properties ; même fonction, deux noms.

Une propriété est un groupe de champs

Une propriété n'est pas un champ unique, c'est un groupe nommé. C'est ce qui permet à un concept - Emploi, Profil d'intervenant, Adresse de livraison - de porter plusieurs valeurs liées sans les éparpiller.

Chaque propriété a :

  • Nom - ce que voient les éditeurs, par ex. Rôle ou Département.
  • Slug - l'identifiant unique référencé dans le code.
  • Description - à quoi elle sert.
  • Autoriser plusieurs valeurs - si une personne peut en détenir plusieurs instances. On a une seule date de naissance, mais possiblement plusieurs certifications.

À l'intérieur, un ou plusieurs champs, chacun avec un libellé, une clé, un type, une description optionnelle et un indicateur d'obligation.

Types de champs

La même palette que dans les schémas de blocs :

  • Texte - texte, texte riche, markdown, mot de passe.
  • Numérique et booléen - nombre, oui/non.
  • Contact - e-mail, URL.
  • Choix - select (un), multi-select (plusieurs).
  • Temps - date, date et heure.
  • Références - média, relation.
  • Structuré - objet (groupe), liste (repeater), tableau, JSON.

Comme relation est disponible, une propriété utilisateur peut pointer vers vos enregistrements de modèles. Une propriété Intervenant peut référencer les sessions animées, et ces sessions restent à un seul endroit au lieu d'être ressaisies par personne.

Mappage schema.org

Voilà la partie à exploiter délibérément. Chaque champ peut nommer une propriété schema.org - author, image, description - et cmssy place alors la valeur dans vos données structurées en JSON-LD.

L'intérêt est concret : une bio d'auteur simplement affichée est du texte sur une page ; la même bio mappée sur author est une affirmation lisible par machine sur qui a écrit l'article. Les moteurs de recherche et les crawlers IA lisent la seconde.

Laissez None quand un champ n'a pas d'équivalent public pertinent. Un mauvais mappage est pire qu'aucun : il affirme quelque chose de faux sur votre contenu, dans un format conçu pour être cru.

Permissions

Deux permissions régissent la fonction, et la séparation est voulue :

  • properties:view - voir les définitions de propriétés.
  • properties:manage - définir des propriétés personnalisées d'utilisateur et de contenu.

Définir une propriété est un changement de schéma, pas de la saisie. Cela relève des personnes qui possèdent la forme de vos données - d'où le fait que ce ne soit pas inclus dans les droits d'édition ordinaires.

Supprimer efface les données

Supprimer une définition de propriété retire ce champ de tous les utilisateurs, et c'est irréversible.

Ce n'est pas une suppression douce ni une colonne masquée. Si une propriété a été remplie chez des centaines d'utilisateurs, exportez ce dont vous avez besoin avant de la retirer : la boîte de confirmation est le dernier moment où ces données existent.

Étapes suivantes