Jetzt mit KI-gestütztem Page Building über den MCP-Server

Benutzereigenschaften

Eigene Felder auf deinen Nutzern, zu benannten Eigenschaften gruppiert, mit optionalem schema.org-Mapping für strukturierte Daten.

Modelle beschreiben deine Inhalte. Eigenschaften beschreiben deine Menschen - die eigenen Felder auf Nutzern jenseits von Name und E-Mail.

Du findest sie im Workspace unter Einstellungen → User Properties. Der Screen selbst heißt Custom Properties; dieselbe Funktion, zwei Namen.

Eine Eigenschaft ist eine Gruppe von Feldern

Eine Eigenschaft ist kein einzelnes Feld, sondern eine benannte Gruppe. Genau das erlaubt einem Konzept - Anstellung, Speaker-Profil, Lieferadresse - mehrere zusammengehörige Werte zu halten, ohne sie zu verstreuen.

Jede Eigenschaft hat:

  • Name - was die Redaktion sieht, z. B. Rolle oder Abteilung.
  • Slug - die eindeutige Kennung, auf die du im Code verweist.
  • Beschreibung - wozu sie dient.
  • Mehrere Werte erlauben - ob eine Person mehr als eine Instanz halten darf. Ein Mensch hat ein Geburtsdatum, kann aber mehrere Zertifikate haben.

Darin ein oder mehrere Felder, jeweils mit Label, Key, Typ, optionaler Beschreibung und Pflicht-Flag.

Feldtypen

Dieselbe Palette wie bei Block-Schemas:

  • Text - Text, Rich Text, Markdown, Passwort.
  • Zahlen und Boolean - Zahl, Ja/Nein.
  • Kontakt - E-Mail, URL.
  • Auswahl - Select (eins), Multi-Select (mehrere).
  • Zeit - Datum, Datum und Uhrzeit.
  • Referenzen - Medien, Relation.
  • Strukturiert - Objekt (Gruppe), Liste (Repeater), Tabelle, JSON.

Weil relation verfügbar ist, kann eine Benutzereigenschaft auf deine Model-Records zeigen. Eine Speaker-Eigenschaft kann die Sessions referenzieren, die jemand hält - und diese Sessions bleiben an einer Stelle, statt pro Person neu getippt zu werden.

Schema.org-Mapping

Das ist der Teil, nach dem man bewusst greifen sollte. Jedes Feld kann eine schema.org-Property benennen - author, image, description - und cmssy platziert den Wert damit als JSON-LD in deinen strukturierten Daten.

Der Nutzen ist konkret: eine bloß gerenderte Autoren-Bio ist Text auf einer Seite; dieselbe Bio, auf author gemappt, ist eine maschinenlesbare Aussage darüber, wer den Artikel geschrieben hat. Suchmaschinen und KI-Crawler lesen das Zweite.

Lass es auf None, wenn ein Feld keine sinnvolle öffentliche Entsprechung hat. Ein falsches Mapping ist schlechter als keines - es behauptet etwas Unwahres über deine Inhalte, in einem Format, das auf Vertrauen gebaut ist.

Berechtigungen

Zwei Berechtigungen regeln die Funktion, und die Trennung ist Absicht:

  • properties:view - die Eigenschaftsdefinitionen sehen.
  • properties:manage - eigene Nutzer- und Inhaltseigenschaften definieren.

Eine Eigenschaft zu definieren ist eine Schemaänderung, keine Dateneingabe. Das gehört zu den Leuten, denen die Form der Daten gehört - deshalb steckt es nicht in gewöhnlichen Bearbeitungsrechten.

Löschen entfernt die Daten

Das Löschen einer Eigenschaftsdefinition entfernt dieses Feld bei jedem Nutzer und lässt sich nicht rückgängig machen.

Das ist kein Soft Delete und keine versteckte Spalte. Wurde eine Eigenschaft bei Hunderten Nutzern gefüllt, exportiere vorher, was du brauchst - der Bestätigungsdialog ist der letzte Punkt, an dem diese Daten existieren.

Nächste Schritte

Cmssy