Propiedades de usuario

Los modelos describen tu contenido. Las propiedades describen a tus personas: los campos personalizados guardados en los usuarios más allá del nombre y el correo.

Las encontrarás en el workspace bajo Ajustes → User Properties. La pantalla se titula Custom Properties; la misma función, dos nombres.

Una propiedad es un grupo de campos

Una propiedad no es un campo suelto, es un grupo con nombre. Eso permite que un concepto -Empleo, Perfil de ponente, Dirección de envío- sostenga varios valores relacionados sin dispersarlos.

Cada propiedad tiene:

• Nombre: lo que ven los editores, p. ej. Rol o Departamento.
• Slug: el identificador único al que apuntas desde el código.
• Descripción: para qué sirve.
• Permitir varios valores: si un usuario puede tener más de una instancia. Una persona tiene una fecha de nacimiento, pero puede tener varias certificaciones.

Dentro, uno o más campos, cada uno con etiqueta, clave, tipo, descripción opcional e indicador de obligatorio.

Tipos de campo

La misma paleta que conoces de los esquemas de bloque:

• Texto: texto, texto enriquecido, markdown, contraseña.
• Numérico y booleano: número, sí/no.
• Contacto: email, URL.
• Elección: select (uno), multi-select (varios).
• Tiempo: fecha, fecha y hora.
• Referencias: medios, relación.
• Estructurado: objeto (grupo), lista (repeater), tabla, JSON.

Como relation está disponible, una propiedad de usuario puede apuntar a tus registros de modelos. Una propiedad Ponente puede referenciar las sesiones que imparte alguien, y esas sesiones se quedan en un solo sitio en vez de reescribirse por usuario.

Mapeo a schema.org

Esta es la parte que conviene aprovechar a propósito. Cada campo puede nombrar una propiedad de schema.org -author, image, description- y cmssy coloca el valor en tus datos estructurados como JSON-LD.

El valor es concreto: una bio de autor que solo se renderiza es texto en una página; la misma bio mapeada a author es una afirmación legible por máquina sobre quién escribió el artículo. Los buscadores y los crawlers de IA leen la segunda.

Déjalo en None cuando un campo no tenga equivalente público con sentido. Un mapeo erróneo es peor que ninguno: afirma algo falso sobre tu contenido en un formato construido para ser creído.

Permisos

Dos permisos gobiernan la función, y la división es deliberada:

• properties:view: ver las definiciones de propiedades.
• properties:manage: definir propiedades personalizadas de usuario y contenido.

Definir una propiedad es un cambio de esquema, no introducir datos. Corresponde a quienes son dueños de la forma de tus datos, y por eso no va incluido en los derechos de edición corrientes.

Borrar elimina los datos

Borrar una definición de propiedad elimina ese campo de todos los usuarios, y no se puede deshacer.

No es un borrado suave ni una columna oculta. Si una propiedad se ha rellenado en cientos de usuarios, exporta lo que necesites antes de quitarla: el diálogo de confirmación es el último punto en el que esos datos existen.

Siguientes pasos

• Autenticación de miembros: los usuarios de los que cuelgan estas propiedades.
• Miembros y roles: quién recibe properties:manage.
• Modelos de datos: la misma idea, para contenido en vez de personas.