Saltar al contenido principal

​
Resumen

Las Custom Relationships te permiten definir y gestionar links entre cualquier par de object types —Contacts, Content Instances, Documents, Orders y más— sin escribir código ni cambiar schemas. Una relationship es una sola definición con dos lados, cada uno con su propio título, alias, object type, scope opcional y cardinalidad. A partir de esos dos lados CXF deriva el tipo de cardinalidad y expone el link en ambos objetos. Para el modelo mental, consulta Conceptos básicos. Las relationships son bidireccionales: cada lado se direcciona por su propio alias, así el mismo link se lee de forma natural desde cualquiera de los objetos.

​
Dónde encontrarlo

Las definiciones de relationship se administran desde los Templates y Profiles. Una vez definidas, adjuntas y desadjuntas los objetos relacionados desde el tab de Relationships de un registro.

​
Properties

Una definición contiene ambos lados, con sufijos _1 y _2:
PropertyTipoRequeridoDescripción
title_1 / title_2stringSíEtiqueta legible de cada lado.
alias_1 / alias_2stringSíIdentificador de cada lado (snake_case) — cómo lo direccionas. Único entre relationships, y los dos lados deben diferir.
object_type_1 / object_type_2enumSíEl object type de cada lado.
cardinality_1 / cardinality_2enumSíone o many en cada lado — juntos forman el tipo de cardinalidad.
content_type_1 / content_type_2stringCondicionalRequerido cuando el object type de ese lado es content_instances.
template_id_1 / template_id_2referenceNoRestringe el lado a un Template (ver Scoping).
profile_id_1 / profile_id_2referenceNoRestringe el lado a un Profile.
pivot_fields_configarrayNoCampos extra tipados sobre el link — solo many_many (ver Pivot fields).

​
Cardinalidad

Cada lado es one o many; el par forma el tipo de cardinalidad de la relationship:
cardinality_1cardinality_2TipoEjemplo
oneoneone_oneUn Contact ↔ un único registro de Profile
onemanyone_manyUn Customer → muchas Orders
manyonemany_oneMuchas Orders → un Customer
manymanymany_manyStudents ↔ Courses
Solo estas cuatro combinaciones son válidas.

​
Pivot fields

Una relationship many_many puede llevar pivot fields — valores extra guardados en el link mismo (no en ninguno de los objetos). Cada uno se define con un slug y un type (text, number o boolean), y se valida al adjuntar o actualizar un link.
Los pivot fields se permiten solo en relationships many_many.

​
Scoping

Cada lado es global o scoped:
  • Global — template_id y profile_id no están definidos; el lado aplica a todos los registros de su object type.
  • Scoped — restringido a un Template o Profile específico, así solo esos registros pueden participar.

​
Adjuntar y desadjuntar

Vinculas registros adjuntándolos a una relationship por su alias, y los desvinculas desadjuntándolos. Para los lados content_instances y documents también provees el Template correspondiente. Adjuntar y desadjuntar disparan los eventos relationship.added y relationship.removed (events) y escriben logs, así las automations pueden reaccionar cuando se forman o rompen los links.

​
Filtrar por relationship

Las relationships se pueden consultar en Views y Segments: filtra registros según si tienen o no tienen una relationship dada, y según los atributos de los objetos relacionados (queries anidadas).

​
System vs custom relationships

  • Las system relationships vienen integradas en CXF. Están marcadas con is_system_relationship y no se pueden editar ni eliminar.
  • Las custom relationships son las definidas por el usuario que se describen aquí.

​
Comportamiento y reglas

  • Solo cardinalidad válida — cardinality_1 y cardinality_2 deben ser cada uno one o many, formando uno de los cuatro tipos de arriba.
  • Los aliases deben ser únicos entre relationships, y los dos lados no pueden compartir alias.
  • content_type es requerido cuando el object type de un lado es content_instances.
  • Los pivot fields se rechazan en cualquier cosa que no sea many_many.
  • El template_id de un lado scoped debe referenciar un Template existente.
  • Como el alias se resuelve dinámicamente, un alias que colisione con un método o scope integrado queda sombreado por él — elige aliases distintos.

​
Seeds

Las definiciones de relationship viajan entre entornos como Seeds estructurales (no son instancias de template). Cada una es un ítem relationships que contiene ambos lados: 
[
  {
    "object_type": "relationships",
    "data": {
      "title_1": "Customer",
      "alias_1": "customer",
      "object_type_1": "contacts",
      "cardinality_1": "one",
      "title_2": "Orders",
      "alias_2": "orders",
      "object_type_2": "orders",
      "cardinality_2": "many"
    }
  }
]

​
Gobernanza y permisos

  • Solo un super admin o un Master puede crear, editar y eliminar custom relationships.
  • Las system relationships (is_system_relationship) no se pueden editar ni eliminar.

​
Acceso por API

Las definiciones de relationship se gestionan por la API, y hay endpoints dedicados para adjuntar, desadjuntar y actualizar los pivot fields de un link. Consulta la API reference.

​
Relacionado

Object types

Los object types que una relationship puede conectar.

Views

Filtra registros por sus relationships.