Skip to main content
Objetos personalizados são novos tipos de registro que o seu app adiciona a um espaço de trabalho — cartão‑postal, fatura, assinatura, qualquer coisa específica do seu domínio. Cada objeto declara seu esquema (campos, relações, valores padrão) e um identificador universal estável que persiste entre sincronizações e implantações.
src/objects/post-card.object.ts

Pontos-chave

  • O universalIdentifier deve ser exclusivo e estável entre implantações.
  • Cada campo requer name, type, label e seu próprio universalIdentifier estável.
  • O array fields é opcional — você pode definir objetos sem campos personalizados.
  • openRecordIn define onde os registros deste objeto são abertos quando clicados: ObjectOpenRecordIn.USER_CHOICE (o padrão, seguindo a preferência de cada membro do workspace em Settings → Experience), ObjectOpenRecordIn.SIDE_PANEL ou ObjectOpenRecordIn.RECORD_PAGE. Fixe em RECORD_PAGE para registros que precisam de uma página inteira para serem utilizáveis, como acontece com fluxos de trabalho e dashboards, ou em SIDE_PANEL para registros que só fazem sentido como um painel rápido, como acontece com eventos de calendário.
  • writability controla quem pode escrever registros do objeto em geral, antes que as permissões de papéis sejam aplicadas: MetadataWritability.OPEN (o padrão — os papéis do workspace determinam), MetadataWritability.APPLICATION (apenas as próprias funções de lógica do seu app podem criar, atualizar ou excluir registros; use isto para objetos de configuração cujos registros determinam o comportamento, de modo que membros do workspace com amplo acesso a registros não possam editá-los por meio da API) ou MetadataWritability.SYSTEM (reservado para dados gerenciados pela plataforma). Leituras não são afetadas — isto é aplicado no lado do servidor, diferentemente de isUIEditable, que apenas oculta elementos da interface. Ele também existe por campo, onde só pode ser mais restritivo do que o nível do objeto.
  • Campos inline definidos aqui não precisam de objectUniversalIdentifier — ele é herdado do objeto pai. Use defineField() para adicionar campos a objetos que não pertencem a você.
  • Você pode criar novos objetos com yarn twenty dev:add object, que orienta você na definição de nomes, campos e relacionamentos. Veja Arquitetura → Scaffolding de entidades.
Os campos base são adicionados automaticamente. Quando você define um objeto personalizado, o Twenty cria campos padrão como id, name, createdAt, updatedAt, createdBy, updatedBy e deletedAt para você. Você não precisa declará‑los no seu array fields — apenas seus campos personalizados. Você pode substituir um campo padrão declarando um com o mesmo nome, mas isso raramente é uma boa ideia.

Tipos de campo

O conjunto completo de valores de FieldType, exportados de twenty-sdk/define: Tipos compostos armazenam vários subcampos (por exemplo, FULL_NAME = primeiro + último nome; CURRENCY = amountMicros + currencyCode). SELECT e MULTI_SELECT exigem um array options, como no exemplo acima.

Valores padrão

Valores padrão de strings literais devem ser colocados entre aspas simples dentro da string — defaultValue: "'Draft'", não defaultValue: "Draft". É por isso que o campo status acima usa `'${PostCardStatus.DRAFT}'`. Strings sem aspas são reservadas para valores padrão computados, avaliados quando um registro é criado:
  • 'uuid' — gera um UUID (para campos UUID)
  • 'now' — o carimbo de data/hora atual (para campos DATE_TIME)
A mesma convenção se aplica a subcampos de string de valores padrão compostos (por exemplo, { source: "'MANUAL'" } em um campo ACTOR) e a valores de SELECT/MULTI_SELECT. Uma string literal padrão deixada sem aspas gera um aviso quando seu app é compilado.

Nulabilidade

isNullable controla se um campo aceita NULL. O valor padrão é true — omita-o para campos opcionais. Defina isNullable: false para tornar um campo obrigatório no nível do banco de dados. Alterações em isNullable são aplicadas em todas as sincronizações, incluindo sincronizações que atualizam um campo existente — assim, você pode alternar a nulabilidade de um campo editando o manifesto e sincronizando novamente.
Tornar um campo existente obrigatório requer um valor padrão. Quando você altera um campo para isNullable: false, também deve fornecer um defaultValue não nulo. O valor padrão preenche retroativamente quaisquer linhas NULL existentes antes de a restrição NOT NULL ser aplicada; sem ele a sincronização falha com Default value cannot be null for non-nullable fields. Campos de relação e campos TS_VECTOR sempre aceitam nulos, portanto isNullable não tem efeito sobre eles.

O que vem depois

  • Conecte este objeto a outros — veja Relações para o padrão de relação bidirecional.
  • Adicione campos a objetos de outros apps — veja Extensão de objetos para defineField().
  • Exibir este objeto na interface do usuário (UI) — consulte Itens do menu de navegação para adicionar uma entrada na barra lateral; consulte Views para adicionar configurações de lista personalizadas.