i18n - docs translations (#23087)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23087?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> Co-authored-by: github-actions <github-actions@twenty.com>
This commit is contained in:
github-actions[bot]
committed by
GitHub
GitHub
parent
26227eff31
commit
5a9a7bd40f
@@ -84,6 +84,52 @@ export default defineView({
|
||||
`getFieldUniversalIdentifier` يُبقي مرجعك صحيحًا حتى إذا تغيّرت تلك المُدخلات، ويتجنّب الانحراف إذا تطوّر أسلوب الاشتقاق في أي وقت.
|
||||
</Note>
|
||||
|
||||
## حقول العلاقات الخاصة بالنظام
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` متوفر في `twenty-sdk`
|
||||
بدءًا من الإصدار 2.23، ويتطلب خادم Twenty بالإصدار 2.23 أو أحدث.
|
||||
</Note>
|
||||
|
||||
بالإضافة إلى حقول النظام البدائية المذكورة أعلاه، يوفِّر الخادم أيضًا أربعة **حقول علاقات للنظام** على كل كائن: `timelineActivities` و`attachments` و`noteTargets` و`taskTargets`، يشير كلٌّ منها إلى كائن العلاقة القياسي المطابِق.
|
||||
|
||||
لا يتم حلّ هذه الحقول باستخدام `getFieldUniversalIdentifier`، إذ يتم اشتقاق معرّفها **بدون الاعتماد على الاسم**، من الكائن المستضيف للحقل والكائن الذي يشير إليه الحقل. وبهذه الطريقة، فإن إعادة تسمية كائن ما لا تغيِّر مطلقًا معرّفات حقول العلاقات الخاصة به.
|
||||
|
||||
استخدم `getSystemRelationFieldUniversalIdentifier` لحلّها:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` هو الكائن الذي **يستضيف** الحقل.
|
||||
* `relationTargetObjectUniversalIdentifier` هو الكائن الذي **يشير إليه** الحقل.
|
||||
|
||||
يتم ترميز الاتجاه من خلال ترتيب الوسيطات. لحلّ الجانب العكسي (مثلًا `attachment.targetRocket`، حقل morph الذي يُنشِئه الخادم على كائن العلاقة القياسي)، قم بمبادلة الاثنين:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
كما هو الحال مع حقول النظام القياسية (scalar)، يعمل المعرّف الناتج في أي موضع يُتوقَّع فيه `fieldMetadataUniversalIdentifier`.
|
||||
|
||||
## الكائنات القياسية في Twenty
|
||||
|
||||
بالنسبة إلى كائن Twenty **قياسي** (Person، Company، Opportunity، …)، لا تحتاج إلى اشتقاق أي شيء: فمعرّفات الحقول النظامية هي ثوابت مُسبقة الحساب يمكنك استيرادها مباشرة.
|
||||
|
||||
@@ -163,8 +163,8 @@ yarn twenty app:publish --private
|
||||
|
||||
**ماذا يفعل:**
|
||||
|
||||
1. يتحقق من تطبيقك، ويُعد Node.js، ويُحدِّث npm (يتطلّب النشر الموثوق npm 11.5.1 أو أحدث).
|
||||
2. يشغّل `yarn twenty app:publish`، الذي يبني التطبيق وينشر `.twenty/output` إلى npm. في بيئة CI يضيف تلقائيًا `--provenance` و`--access public`، لذا لا حاجة للرايات داخل سير العمل.
|
||||
1. يجلب شيفرة تطبيقك، ويُعد Node.js، ويُحدِّث npm (يتطلّب النشر الموثوق npm 11.5.1 أو أحدث).
|
||||
2. يشغّل `yarn twenty app:publish`، الذي يبني التطبيق وينشر `.twenty/output` إلى npm. في بيئة CI يضيف تلقائيًا `--provenance` و`--access public`، لذا لا حاجة إلى أي أعلام في سير العمل.
|
||||
|
||||
**إعداد لمرة واحدة:**
|
||||
|
||||
@@ -254,7 +254,7 @@ yarn twenty dev:catalog-sync
|
||||
|
||||
### النشر عبر CI
|
||||
|
||||
ينشر سير عمل `publish.yml` المُنشأ تلقائيًا والموصوف أعلاه إلى npm تلقائيًا عند علامات الإصدارات، مع بيانات provenance. نظرًا لأن `yarn twenty app:publish` يضيف `--provenance` و`--access public` نيابةً عنك عند تشغيله في CI، فلا يحتاج سير العمل إلى أي رايات npm — فقط إعداد الناشر الموثوق لمرة واحدة.
|
||||
ينشر سير عمل `publish.yml` المُنشأ تلقائيًا والموصوف أعلاه إلى npm تلقائيًا عند علامات الإصدارات، مع بيانات provenance. نظرًا لأن `yarn twenty app:publish` يضيف `--provenance` و`--access public` نيابةً عنك عند تشغيله في CI، فلا يحتاج سير العمل إلى أي أعلام npm — فقط إعداد الناشر الموثوق لمرة واحدة.
|
||||
|
||||
بالنسبة لأنظمة CI الأخرى (GitLab CI وCircleCI وغيرها)، شغّل `yarn install` ثم `yarn twenty app:publish`. يُصدِر بيانات provenance عندما تتمكّن البيئة من إصدار رمز OIDC، ويتم تخطيه تلقائيًا خلاف ذلك.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -86,6 +86,52 @@ Tentýž odvozený identifikátor funguje všude tam, kde se očekává `fieldMe
|
||||
vstupy změní, a předchází odchylkám, pokud se samotný způsob odvozování někdy změní.
|
||||
</Note>
|
||||
|
||||
## Systémová relační pole
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` je k dispozici od verze `twenty-sdk`
|
||||
2.23 a vyžaduje server Twenty ve verzi 2.23 nebo novější.
|
||||
</Note>
|
||||
|
||||
Kromě výše uvedených skalárních systémových polí server také na každém objektu poskytuje čtyři **systémová relační pole**: `timelineActivities`, `attachments`, `noteTargets` a `taskTargets`, z nichž každé ukazuje na odpovídající standardní relační objekt.
|
||||
|
||||
Tato pole nejsou řešena pomocí `getFieldUniversalIdentifier`: jejich identifikátor je odvozen **bez ohledu na název** z objektu, který pole obsahuje, a z objektu, na který pole odkazuje. Tím pádem přejmenování objektu nikdy nezmění identifikátory jeho relačních polí.
|
||||
|
||||
Použijte `getSystemRelationFieldUniversalIdentifier` k jejich vyřešení:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` je objekt, který toto pole **obsahuje**.
|
||||
* `relationTargetObjectUniversalIdentifier` je objekt, na který toto pole **ukazuje**.
|
||||
|
||||
Směr je zakódovaný pořadím argumentů. Pro vyřešení opačné strany (např. `attachment.targetRocket`, morph pole, které server vytvoří na standardním relačním objektu), je prohoďte:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
Stejně jako u skalárních systémových polí funguje vyřešené ID všude tam, kde je očekáváno `fieldMetadataUniversalIdentifier`.
|
||||
|
||||
## Standardní objekty Twenty
|
||||
|
||||
U **standardního** objektu Twenty (Person, Company, Opportunity, …) nemusíte nic odvozovat: identifikátory systémových polí jsou předpočítané konstanty, které můžete přímo importovat.
|
||||
|
||||
@@ -163,7 +163,7 @@ Publikuje vaši aplikaci na npm s doloženým původem, když odešlete tag verz
|
||||
|
||||
**K čemu slouží:**
|
||||
|
||||
1. Zkontroluje vaši aplikaci, nastaví Node.js a aktualizuje npm (důvěryhodné publikování vyžaduje npm 11.5.1 nebo novější).
|
||||
1. Načte repozitář vaší aplikace, nastaví Node.js a aktualizuje npm (důvěryhodné publikování vyžaduje npm 11.5.1 nebo novější).
|
||||
2. Spustí `yarn twenty app:publish`, který sestaví aplikaci a publikuje `.twenty/output` na npm. V CI automaticky přidá `--provenance` a `--access public`, takže ve workflowu nejsou potřeba žádné přepínače.
|
||||
|
||||
**Jednorázové nastavení:**
|
||||
@@ -254,7 +254,7 @@ Pokud vaše aplikace nedefinuje `aboutDescription` v `defineApplication()`, trž
|
||||
|
||||
### Publikování pomocí CI
|
||||
|
||||
Vygenerované workflow `publish.yml` popsané výše publikuje na npm automaticky při verzovacích tazích (tagách), s provenance. Protože `yarn twenty app:publish` při běhu v CI přidá `--provenance` a `--access public` za vás, workflow nepotřebuje žádné přepínače npm — pouze jednorázové nastavení důvěryhodného vydavatele.
|
||||
Vygenerované workflow `publish.yml` popsané výše publikuje na npm automaticky při verzovacích tagách, s provenance. Protože `yarn twenty app:publish` při běhu v CI přidá `--provenance` a `--access public` za vás, workflow nepotřebuje žádné přepínače npm — pouze jednorázové nastavení důvěryhodného vydavatele.
|
||||
|
||||
Pro jiné CI systémy (GitLab CI, CircleCI atd.) spusťte `yarn install` a poté `yarn twenty app:publish`. Provenance se vydává, pokud prostředí umí vytvořit token OIDC, a v opačném případě se automaticky vynechá.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -85,6 +85,51 @@ Dieselbe aufgelöste ID funktioniert überall dort, wo ein `fieldMetadataUnivers
|
||||
Eingaben ändern, und verhindert Abweichungen, falls sich die Ableitung jemals weiterentwickelt.
|
||||
</Note>
|
||||
|
||||
## System-Relationsfelder
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` ist ab Version 2.23 von `twenty-sdk` verfügbar und erfordert einen Twenty-Server in Version 2.23 oder höher.
|
||||
</Note>
|
||||
|
||||
Zusätzlich zu den oben genannten skalaren Systemfeldern stellt der Server für jedes Objekt vier **System-Relationsfelder** bereit: `timelineActivities`, `attachments`, `noteTargets` und `taskTargets`, die jeweils auf das passende Standard-Relationsobjekt verweisen.
|
||||
|
||||
Diese Felder werden nicht mit `getFieldUniversalIdentifier` aufgelöst: Ihre Kennung wird **namenunabhängig** abgeleitet, aus dem Objekt, das das Feld enthält, und dem Objekt, auf das das Feld verweist. Auf diese Weise ändert das Umbenennen eines Objekts niemals die Kennungen seiner Relationsfelder.
|
||||
|
||||
Verwende `getSystemRelationFieldUniversalIdentifier`, um sie aufzulösen:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` ist das Objekt, das das Feld **enthält**.
|
||||
* `relationTargetObjectUniversalIdentifier` ist das Objekt, auf das das Feld **zeigt**.
|
||||
|
||||
Die Richtung wird durch die Reihenfolge der Argumente codiert. Um die umgekehrte Seite aufzulösen (z. B. `attachment.targetRocket`, das Morph-Feld, das der Server auf dem Standard-Relationsobjekt erstellt), vertausche die beiden:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
Wie bei skalaren Systemfeldern funktioniert die aufgelöste ID überall dort, wo ein `fieldMetadataUniversalIdentifier` erwartet wird.
|
||||
|
||||
## Standardobjekte von Twenty
|
||||
|
||||
Für ein **Standard**-Twenty-Objekt (Person, Company, Opportunity, …) müssen Sie nichts ableiten: Die Systemfeld-Kennungen sind vorab berechnete Konstanten, die Sie direkt importieren können.
|
||||
|
||||
@@ -163,7 +163,7 @@ Veröffentlicht Ihre App mit Herkunftsnachweis auf npm, wenn Sie ein Versions-Ta
|
||||
|
||||
**Was sie macht:**
|
||||
|
||||
1. Checkt eure App aus, richtet Node.js ein und aktualisiert npm (Trusted Publishing erfordert npm 11.5.1 oder neuer).
|
||||
1. Checken Sie Ihre App aus, richten Sie Node.js ein und aktualisieren Sie npm (Trusted Publishing erfordert npm 11.5.1 oder neuer).
|
||||
2. Führt `yarn twenty app:publish` aus, wodurch die App gebaut und `.twenty/output` auf npm veröffentlicht wird. In CI werden automatisch `--provenance` und `--access public` hinzugefügt, sodass im Workflow keine Flags benötigt werden.
|
||||
|
||||
**Einmalige Einrichtung:**
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -86,6 +86,52 @@ El mismo id resuelto funciona en cualquier lugar donde se espere un `fieldMetada
|
||||
entradas cambian, y evita desviaciones si la derivación evoluciona en algún momento.
|
||||
</Note>
|
||||
|
||||
## Campos de relación del sistema
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` está disponible desde `twenty-sdk`
|
||||
2.23 en adelante y requiere un servidor Twenty en la versión 2.23 o posterior.
|
||||
</Note>
|
||||
|
||||
Además de los campos escalares del sistema mencionados arriba, el servidor también aprovisiona cuatro **campos de relación del sistema** en cada objeto: `timelineActivities`, `attachments`, `noteTargets` y `taskTargets`, cada uno apuntando al objeto de relación estándar correspondiente.
|
||||
|
||||
Estos campos no se resuelven con `getFieldUniversalIdentifier`: su identificador se deriva **sin nombre**, a partir del objeto que aloja el campo y del objeto al que apunta el campo. De este modo, cambiar el nombre de un objeto nunca modifica los identificadores de sus campos de relación.
|
||||
|
||||
Use `getSystemRelationFieldUniversalIdentifier` para resolverlos:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` es el objeto que **aloja** el campo.
|
||||
* `relationTargetObjectUniversalIdentifier` es el objeto al que el campo **apunta**.
|
||||
|
||||
La dirección se codifica mediante el orden de los argumentos. Para resolver el lado inverso (por ejemplo, `attachment.targetRocket`, el campo morph que el servidor crea en el objeto de relación estándar), intercambie ambos:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
Como con los campos de sistema escalares, el id resuelto funciona en cualquier lugar donde se espere un `fieldMetadataUniversalIdentifier`.
|
||||
|
||||
## Objetos estándar de Twenty
|
||||
|
||||
Para un objeto **estándar** de Twenty (Persona, Compañía, Oportunidad, …), no necesitas derivar nada: los identificadores de los campos de sistema son constantes precalculadas que puedes importar directamente.
|
||||
|
||||
@@ -163,7 +163,7 @@ Publica tu aplicación en npm con procedencia cuando haces push de una etiqueta
|
||||
|
||||
**Qué hace:**
|
||||
|
||||
1. Revisa tu aplicación, configura Node.js y actualiza npm (la publicación de confianza requiere npm 11.5.1 o posterior).
|
||||
1. Hace checkout de tu aplicación, configura Node.js y actualiza npm (la publicación de confianza requiere npm 11.5.1 o posterior).
|
||||
2. Ejecuta `yarn twenty app:publish`, que compila la aplicación y publica `.twenty/output` en npm. En CI agrega automáticamente `--provenance` y `--access public`, por lo que no se necesitan banderas en el flujo de trabajo.
|
||||
|
||||
**Configuración única:**
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -86,6 +86,52 @@ Le même id résolu fonctionne partout où un `fieldMetadataUniversalIdentifier`
|
||||
entrées changent, et évite les divergences si la dérivation évolue un jour.
|
||||
</Note>
|
||||
|
||||
## Champs de relation système
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` est disponible dans `twenty-sdk`
|
||||
à partir de la version 2.23 et nécessite un serveur Twenty en version 2.23 ou ultérieure.
|
||||
</Note>
|
||||
|
||||
Outre les champs système scalaires ci-dessus, le serveur met également à disposition quatre **champs de relation système** sur chaque objet : `timelineActivities`, `attachments`, `noteTargets` et `taskTargets`, chacun pointant vers l’objet de relation standard correspondant.
|
||||
|
||||
Ainsi, ces champs ne sont pas résolus avec `getFieldUniversalIdentifier` : leur identifiant est dérivé **indépendamment du nom**, à partir de l’objet qui héberge le champ et de l’objet vers lequel le champ pointe. De cette façon, renommer un objet ne modifie jamais les identifiants de ses champs de relation.
|
||||
|
||||
Utilisez `getSystemRelationFieldUniversalIdentifier` pour les résoudre :
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` est l’objet qui **héberge** le champ.
|
||||
* `relationTargetObjectUniversalIdentifier` est l’objet vers lequel le champ **pointe**.
|
||||
|
||||
La direction est encodée par l’ordre des arguments. Pour résoudre le côté inverse (par exemple `attachment.targetRocket`, le champ morph que le serveur crée sur l’objet de relation standard), inversez les deux :
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
Comme pour les champs système scalaires, l’id résolu fonctionne partout où un `fieldMetadataUniversalIdentifier` est attendu.
|
||||
|
||||
## Objets standard de Twenty
|
||||
|
||||
Pour un objet Twenty **standard** (Person, Company, Opportunity, …), vous n'avez rien à dériver : les identifiants des champs système sont des constantes pré-calculées que vous pouvez importer directement.
|
||||
|
||||
@@ -254,7 +254,7 @@ Si votre application ne définit pas de `aboutDescription` dans `defineApplicati
|
||||
|
||||
### Publication via CI
|
||||
|
||||
Le workflow `publish.yml` préconfiguré décrit ci-dessus publie automatiquement sur npm lors des tags de version, avec provenance. Comme `yarn twenty app:publish` ajoute `--provenance` et `--access public` pour vous lorsqu’il s’exécute en CI, le workflow n’a besoin d’aucun indicateur npm — seulement de la configuration unique du trusted publisher.
|
||||
Le workflow `publish.yml` préconfiguré décrit ci-dessus publie automatiquement sur npm lors des tags de version, avec provenance. Comme `yarn twenty app:publish` ajoute `--provenance` et `--access public` pour vous lorsqu’il s’exécute en CI, le workflow n’a besoin d’aucune option npm — seulement de la configuration unique de Trusted Publisher.
|
||||
|
||||
Pour d’autres systèmes de CI (GitLab CI, CircleCI, etc.), exécutez `yarn install` puis `yarn twenty app:publish`. La provenance est émise lorsque l’environnement peut générer un jeton OIDC et est ignorée automatiquement dans le cas contraire.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -86,6 +86,52 @@ Lo stesso id risolto funziona ovunque ci si aspetti un `fieldMetadataUniversalId
|
||||
input cambiano ed evita discrepanze se la modalità di derivazione dovesse mai evolvere.
|
||||
</Note>
|
||||
|
||||
## Campi di relazione di sistema
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` è disponibile da `twenty-sdk`
|
||||
2.23 in poi e richiede un server Twenty dalla versione 2.23 o successiva.
|
||||
</Note>
|
||||
|
||||
Oltre ai campi scalari di sistema sopra indicati, il server fornisce anche quattro **campi di relazione di sistema** su ogni oggetto: `timelineActivities`, `attachments`, `noteTargets` e `taskTargets`, ciascuno dei quali punta al corrispondente oggetto di relazione standard.
|
||||
|
||||
Questi campi non vengono risolti con `getFieldUniversalIdentifier`: il loro identificatore è derivato **in modo indipendente dal nome**, dall'oggetto che ospita il campo e dall'oggetto a cui il campo punta. In questo modo, rinominare un oggetto non modifica mai gli identificatori dei suoi campi di relazione.
|
||||
|
||||
Usa `getSystemRelationFieldUniversalIdentifier` per risolverli:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` è l'oggetto che **ospita** il campo.
|
||||
* `relationTargetObjectUniversalIdentifier` è l'oggetto a cui il campo **punta**.
|
||||
|
||||
La direzione è codificata dall'ordine degli argomenti. Per risolvere il lato inverso (ad esempio `attachment.targetRocket`, il campo morph che il server crea sull'oggetto di relazione standard), scambia i due:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
Come per i campi di sistema scalari, l'id risolto funziona ovunque ci si aspetti un `fieldMetadataUniversalIdentifier`.
|
||||
|
||||
## Oggetti standard di Twenty
|
||||
|
||||
Per un oggetto **standard** di Twenty (Person, Company, Opportunity, …), non hai bisogno di derivare nulla: gli identificatori dei campi di sistema sono costanti pre-calcolate che puoi importare direttamente.
|
||||
|
||||
@@ -163,7 +163,7 @@ Pubblica la tua app su npm con attestazione di provenienza quando esegui il push
|
||||
|
||||
**Cosa fa:**
|
||||
|
||||
1. Clona la tua app, configura Node.js e aggiorna npm (la pubblicazione con attendibilità richiede npm 11.5.1 o versioni successive).
|
||||
1. Clona la tua app, configura Node.js e aggiorna npm (la pubblicazione attendibile richiede npm 11.5.1 o versioni successive).
|
||||
2. Esegue `yarn twenty app:publish`, che crea la build dell'app e pubblica `.twenty/output` su npm. In CI aggiunge automaticamente `--provenance` e `--access public`, quindi non sono necessari flag nel workflow.
|
||||
|
||||
**Impostazione una tantum:**
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -83,6 +83,52 @@ export default defineView({
|
||||
id は解決して、ハードコードしないでください。 サーバーはその値をアプリケーション id、オブジェクト id、フィールド名から導出するため、`getFieldUniversalIdentifier` を呼び出すことで、それらの入力が変更された場合でも参照を正しい状態に保ち、導出方法が将来変わった場合のずれも防ぐことができます。
|
||||
</Note>
|
||||
|
||||
## システムリレーションフィールド
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` は `twenty-sdk`
|
||||
2.23 以降で利用可能であり、バージョン 2.23 以降の Twenty サーバーが必要です。
|
||||
</Note>
|
||||
|
||||
上記のスカラー型システムフィールドに加えて、サーバーはすべてのオブジェクトに対して 4 つの**システムリレーションフィールド**を提供します。`timelineActivities`、`attachments`、`noteTargets`、`taskTargets` であり、それぞれが対応する標準リレーションオブジェクトを参照します。
|
||||
|
||||
これらのフィールドは `getFieldUniversalIdentifier` では解決されません。フィールドを保持しているオブジェクトと、そのフィールドが参照するオブジェクトから、**名前に依存せず**識別子が導出されます。 この方法により、オブジェクトの名称を変更しても、そのリレーションフィールドの識別子は決して変わりません。
|
||||
|
||||
それらを解決するには、`getSystemRelationFieldUniversalIdentifier` を使用します。
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` は、そのフィールドを **保持している** オブジェクトです。
|
||||
* `relationTargetObjectUniversalIdentifier` は、そのフィールドが **参照している** オブジェクトです。
|
||||
|
||||
方向は引数の順序によってエンコードされます。 逆方向（例: `attachment.targetRocket`。これは、標準リレーションオブジェクト上でサーバーが作成する morph フィールド）を解決するには、2 つを入れ替えます。
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
スカラーのシステムフィールドと同様に、解決された ID は `fieldMetadataUniversalIdentifier` が想定されるあらゆる場所で使用できます。
|
||||
|
||||
## 標準の Twenty オブジェクト
|
||||
|
||||
**標準** の Twenty オブジェクト（Person、Company、Opportunity など）の場合、何も導出する必要はありません。システムフィールドの識別子はあらかじめ計算された定数として用意されており、直接インポートできます。
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -84,6 +84,52 @@ export default defineView({
|
||||
`getFieldUniversalIdentifier`를 호출하면 이 입력값들이 변경되더라도 참조를 올바르게 유지할 수 있고, 도출 방식이 바뀌더라도 드리프트를 방지할 수 있습니다.
|
||||
</Note>
|
||||
|
||||
## 시스템 관계 필드
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier`는 `twenty-sdk`
|
||||
2.23부터 사용 가능하며, Twenty 서버 버전 2.23 이상이 필요합니다.
|
||||
</Note>
|
||||
|
||||
위에 언급된 스칼라 시스템 필드 외에도 서버는 모든 객체에 `timelineActivities`, `attachments`, `noteTargets`, `taskTargets`라는 네 개의 **시스템 관계 필드**를 제공하며, 각각은 해당하는 표준 관계 객체를 가리킵니다.
|
||||
|
||||
이 필드는 `getFieldUniversalIdentifier`로는 해결되지 않습니다. 이들의 식별자는 필드를 호스팅하는 객체와 필드가 가리키는 객체에서 **이름과 무관하게** 도출됩니다. 이 방식이면 객체의 이름을 변경해도 해당 객체의 관계 필드 식별자는 변경되지 않습니다.
|
||||
|
||||
이들을 해결하려면 `getSystemRelationFieldUniversalIdentifier`를 사용하세요:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier`는 필드를 **호스팅하는** 객체입니다.
|
||||
* `relationTargetObjectUniversalIdentifier`는 필드가 **가리키는** 객체입니다.
|
||||
|
||||
방향은 인수의 순서에 의해 인코딩됩니다. 반대쪽(예: `attachment.targetRocket`, 서버가 표준 관계 객체에 생성하는 morph 필드)을 해결하려면 두 인수의 순서를 바꾸면 됩니다:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
스칼라 시스템 필드와 마찬가지로, 해결된 ID는 `fieldMetadataUniversalIdentifier`가 필요한 곳이면 어디서든 사용할 수 있습니다.
|
||||
|
||||
## 표준 Twenty 객체
|
||||
|
||||
**표준** Twenty 객체(Person, Company, Opportunity 등)의 경우 어떤 것도 도출할 필요가 없습니다. 시스템 필드 식별자는 미리 계산된 상수이므로 바로 import해서 사용할 수 있습니다.
|
||||
|
||||
@@ -164,15 +164,15 @@ yarn twenty app:publish --private
|
||||
**하는 일:**
|
||||
|
||||
1. 앱을 체크아웃하고 Node.js를 설정한 다음 npm을 업데이트합니다(신뢰할 수 있는 게시 기능을 사용하려면 npm 11.5.1 이상이 필요합니다).
|
||||
2. `yarn twenty app:publish`를 실행하여 앱을 빌드하고 `.twenty/output`를 npm에 게시합니다. CI에서는 자동으로 `--provenance` 및 `--access public`를 추가하므로, 워크플로에는 플래그가 필요하지 않습니다.
|
||||
2. `yarn twenty app:publish`를 실행하여 앱을 빌드하고 `.twenty/output`를 npm에 게시합니다. CI에서는 자동으로 `--provenance` 및 `--access public`을 추가하므로, 워크플로에는 플래그가 필요하지 않습니다.
|
||||
|
||||
**일회성 설정:**
|
||||
**한 번만 설정:**
|
||||
|
||||
npmjs.com에서 패키지를 연 다음 **Settings → Trusted Publisher**로 이동하여 이 저장소를 `publish.yml` 워크플로에 등록하세요([npm trusted publishing 문서](https://docs.npmjs.com/trusted-publishers)를 참고하세요). provenance와 함께 게시하면 어떤 GitHub 리포지터리가 패키지를 빌드했는지 증명되며, 이는 Twenty 마켓플레이스에서 앱 소유권을 주장하는 방법이기도 합니다.
|
||||
npmjs.com에서 패키지를 연 다음 **Settings → Trusted Publisher**로 이동하여 이 저장소를 `publish.yml` 워크플로에 등록하세요([npm trusted publishing 문서](https://docs.npmjs.com/trusted-publishers)를 참고하세요). provenance와 함께 게시하면 어떤 GitHub 저장소가 패키지를 빌드했는지 증명되며, 이는 Twenty 마켓플레이스에서 앱 소유권을 주장하는 방법이기도 합니다.
|
||||
|
||||
### 재사용 가능한 액션 고정하기
|
||||
|
||||
`ci.yml` 및 `cd.yml` 워크플로는 `@main`의 재사용 가능한 액션을 참조하므로, `twentyhq/twenty` 리포지터리의 액션 업데이트가 자동으로 반영됩니다. 결정적 빌드를 원한다면, 각 `uses:` 줄에서 `@main`을 커밋 SHA 또는 릴리스 태그로 바꾸세요.
|
||||
`ci.yml` 및 `cd.yml` 워크플로는 `@main`의 재사용 가능한 액션을 참조하므로, `twentyhq/twenty` 저장소의 액션 업데이트가 자동으로 반영됩니다. 결정적 빌드를 원한다면, 각 `uses:` 줄에서 `@main`을 커밋 SHA 또는 릴리스 태그로 바꾸세요.
|
||||
|
||||
## npm에 게시
|
||||
|
||||
@@ -254,7 +254,7 @@ yarn twenty dev:catalog-sync
|
||||
|
||||
### CI 게시
|
||||
|
||||
위에서 설명한 스캐폴딩된 `publish.yml` 워크플로는 버전 태그에 따라 provenance와 함께 npm에 자동으로 게시합니다. `yarn twenty app:publish`는 CI에서 실행될 때 `--provenance` 및 `--access public`를 자동으로 추가하므로, 워크플로에는 npm 플래그가 전혀 필요하지 않고 한 번만 설정하는 trusted-publisher만 있으면 됩니다.
|
||||
위에서 설명한 스캐폴딩된 `publish.yml` 워크플로는 버전 태그에 따라 provenance와 함께 npm에 자동으로 게시합니다. `yarn twenty app:publish`는 CI에서 실행될 때 `--provenance` 및 `--access public`을 자동으로 추가하므로, 워크플로에는 npm 플래그가 전혀 필요하지 않고 Trusted Publisher를 한 번만 설정하면 됩니다.
|
||||
|
||||
다른 CI 시스템(GitLab CI, CircleCI 등)에서는 `yarn install`을 실행한 다음 `yarn twenty app:publish`를 실행하세요. 환경에서 OIDC 토큰을 생성할 수 있을 때는 provenance가 생성되고, 그렇지 않은 경우에는 자동으로 건너뜁니다.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -86,6 +86,51 @@ O mesmo id resolvido funciona em qualquer lugar onde se espera um `fieldMetadata
|
||||
entradas mudem, e evita divergências se a derivação evoluir no futuro.
|
||||
</Note>
|
||||
|
||||
## Campos de relação do sistema
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` está disponível a partir da versão 2.23 do `twenty-sdk` e requer um servidor Twenty na versão 2.23 ou posterior.
|
||||
</Note>
|
||||
|
||||
Além dos campos escalares de sistema acima, o servidor também provisiona quatro **campos de relação de sistema** em cada objeto: `timelineActivities`, `attachments`, `noteTargets` e `taskTargets`, cada um apontando para o objeto de relação padrão correspondente.
|
||||
|
||||
Dessa forma, esses campos não são resolvidos com `getFieldUniversalIdentifier`: seu identificador é derivado de forma **independente de nome**, a partir do objeto que hospeda o campo e do objeto para o qual o campo aponta. Dessa forma, renomear um objeto nunca altera os identificadores de seus campos de relação.
|
||||
|
||||
Use `getSystemRelationFieldUniversalIdentifier` para resolvê-los:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` é o objeto que **hospeda** o campo.
|
||||
* `relationTargetObjectUniversalIdentifier` é o objeto para o qual o campo **aponta**.
|
||||
|
||||
A direção é codificada pela ordem dos argumentos. Para resolver o lado inverso (por exemplo, `attachment.targetRocket`, o campo morph que o servidor cria no objeto de relação padrão), inverta os dois:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
Assim como acontece com campos de sistema escalares, o id resolvido funciona em qualquer lugar em que um `fieldMetadataUniversalIdentifier` é esperado.
|
||||
|
||||
## Objetos Padrão do Twenty
|
||||
|
||||
Para um objeto **padrão** do Twenty (Person, Company, Opportunity, …), você não precisa derivar nada: os identificadores de campos de sistema são constantes pré-computadas que você pode importar diretamente.
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -86,6 +86,51 @@ Același id calculat funcționează oriunde este așteptat un `fieldMetadataUniv
|
||||
intrări se schimbă și evită divergența dacă metoda de derivare evoluează vreodată.
|
||||
</Note>
|
||||
|
||||
## Câmpuri de relație de sistem
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` este disponibil începând cu versiunea 2.23 a `twenty-sdk` și necesită un server Twenty pe versiunea 2.23 sau o versiune ulterioară.
|
||||
</Note>
|
||||
|
||||
Pe lângă câmpurile scalare de sistem de mai sus, serverul mai pune la dispoziție patru **câmpuri de relație de sistem** pentru fiecare obiect: `timelineActivities`, `attachments`, `noteTargets` și `taskTargets`, fiecare indicând către obiectul de relație standard corespunzător.
|
||||
|
||||
Aceste câmpuri nu sunt rezolvate cu `getFieldUniversalIdentifier`: identificatorul lor este derivat **independent de nume**, din obiectul care găzduiește câmpul și obiectul către care indică acest câmp. Astfel, redenumirea unui obiect nu modifică niciodată identificatorii câmpurilor sale de relație.
|
||||
|
||||
Folosește `getSystemRelationFieldUniversalIdentifier` pentru a le rezolva:
|
||||
|
||||
```ts
|
||||
import {
|
||||
getSystemRelationFieldUniversalIdentifier,
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
|
||||
} from 'twenty-sdk/define';
|
||||
|
||||
// rocket.attachments — the relation field hosted on your custom object
|
||||
const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
relationTargetObjectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` este obiectul care **găzduiește** câmpul.
|
||||
* `relationTargetObjectUniversalIdentifier` este obiectul către care **indică** câmpul.
|
||||
|
||||
Direcția este codificată prin ordinea argumentelor. Pentru a rezolva partea inversă (de ex. `attachment.targetRocket`, câmpul morfic pe care serverul îl creează pe obiectul de relație standard), inversează-le pe cele două:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
const attachmentTargetRocketFieldId =
|
||||
getSystemRelationFieldUniversalIdentifier({
|
||||
applicationUniversalIdentifier: APPLICATION_UNIVERSAL_IDENTIFIER,
|
||||
objectUniversalIdentifier:
|
||||
STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.attachment.universalIdentifier,
|
||||
relationTargetObjectUniversalIdentifier: ROCKET_OBJECT_UNIVERSAL_IDENTIFIER,
|
||||
});
|
||||
```
|
||||
|
||||
Ca și în cazul câmpurilor de sistem scalare, id-ul rezolvat funcționează oriunde este așteptat un `fieldMetadataUniversalIdentifier`.
|
||||
|
||||
## Obiecte standard Twenty
|
||||
|
||||
Pentru un obiect Twenty **standard** (Person, Company, Opportunity, …), nu trebuie să derivezi nimic: identificatorii câmpurilor de sistem sunt constante pre-calculate pe care le poți importa direct.
|
||||
|
||||
@@ -163,16 +163,16 @@ Publică aplicația pe npm, cu proveniență, când împingi un tag de versiune
|
||||
|
||||
**Ce face:**
|
||||
|
||||
1. Face checkout pentru aplicația ta, configurează Node.js și actualizează npm (publicarea de încredere necesită npm 11.5.1 sau o versiune ulterioară).
|
||||
2. Rulează `yarn twenty app:publish`, care construiește aplicația și publică `.twenty/output` în npm. În CI adaugă automat `--provenance` și `--access public`, astfel încât nu sunt necesari indicatori în workflow.
|
||||
1. Face checkout al aplicației tale, configurează Node.js și actualizează npm (publicarea de încredere necesită npm 11.5.1 sau o versiune ulterioară).
|
||||
2. Rulează `yarn twenty app:publish`, care construiește aplicația și publică `.twenty/output` în npm. În CI adaugă automat `--provenance` și `--access public`, astfel încât nu sunt necesare flaguri în fluxul de lucru.
|
||||
|
||||
**Configurare unică:**
|
||||
|
||||
Pe npmjs.com deschide pachetul tău > **Settings → Trusted Publisher** și înregistrează acest repository cu workflow-ul `publish.yml` (vezi [documentația npm trusted publishing](https://docs.npmjs.com/trusted-publishers)). Publicarea cu provenance certifică ce repository GitHub a construit pachetul, ceea ce este, de asemenea, modul în care îți revendici proprietatea asupra aplicației tale într-un marketplace Twenty.
|
||||
Pe npmjs.com deschide pachetul tău > **Settings → Trusted Publisher** și înregistrează acest repozitoriu cu fluxul de lucru `publish.yml` (vezi [documentația npm trusted publishing](https://docs.npmjs.com/trusted-publishers)). Publicarea cu provenance certifică ce repozitoriu GitHub a construit pachetul, ceea ce este, de asemenea, modul în care îți revendici proprietatea asupra aplicației tale într-un marketplace Twenty.
|
||||
|
||||
### Fixarea acțiunilor reutilizabile
|
||||
|
||||
Workflows `ci.yml` și `cd.yml` fac referire la acțiuni reutilizabile la `@main`, astfel încât actualizările acțiunilor din repo-ul `twentyhq/twenty` sunt preluate automat. Dacă dorești builduri deterministe, înlocuiește `@main` cu un SHA de commit sau cu un tag de release pe fiecare linie `uses:`.
|
||||
Fluxurile de lucru `ci.yml` și `cd.yml` fac referire la acțiuni reutilizabile la `@main`, astfel încât actualizările acțiunilor din repo-ul `twentyhq/twenty` sunt preluate automat. Dacă dorești builduri deterministe, înlocuiește `@main` cu un SHA de commit sau cu un tag de release pe fiecare linie `uses:`.
|
||||
|
||||
## Publicarea pe npm
|
||||
|
||||
@@ -254,7 +254,7 @@ Dacă aplicația ta nu definește un `aboutDescription` în `defineApplication()
|
||||
|
||||
### Publicare CI
|
||||
|
||||
Workflow-ul generat `publish.yml` descris mai sus publică automat în npm la etichetele de versiune, cu provenance. Deoarece `yarn twenty app:publish` adaugă `--provenance` și `--access public` pentru tine când rulează în CI, workflow-ul nu are nevoie de indicatori npm — doar de configurarea unică a trusted-publisher.
|
||||
Fluxul de lucru generat `publish.yml` descris mai sus publică automat pe npm la etichetele de versiune, cu provenance. Deoarece `yarn twenty app:publish` adaugă `--provenance` și `--access public` pentru tine când rulează în CI, fluxul de lucru nu are nevoie de flaguri npm — doar de configurarea unică a Trusted Publisher.
|
||||
|
||||
Pentru alte sisteme CI (GitLab CI, CircleCI etc.), rulează `yarn install` apoi `yarn twenty app:publish`. Provenance este emisă atunci când mediul poate genera un token OIDC și este omisă automat în caz contrar.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ yarn twenty plan
|
||||
Building manifest...
|
||||
Computing metadata plan (read-only, nothing will be applied)...
|
||||
|
||||
# fieldMetadata "timelineActivities" will be created
|
||||
# fieldMetadata "crewCapacity" will be created
|
||||
+ ...
|
||||
|
||||
Plan: 1 to add, 1 to change, 0 to destroy.
|
||||
|
||||
@@ -84,18 +84,17 @@ Aynı çözümlenen id, bir `fieldMetadataUniversalIdentifier` beklendiği her y
|
||||
türettiği için, `getFieldUniversalIdentifier` çağrısı, bu girdiler değişse bile referansınızı doğru tutar ve türetme zaman içinde gelişirse sapmayı önler.
|
||||
</Note>
|
||||
|
||||
## System relation fields
|
||||
## Sistem ilişki alanları
|
||||
|
||||
<Note>
|
||||
`getSystemRelationFieldUniversalIdentifier` is available from `twenty-sdk`
|
||||
2.23 onward and requires a Twenty server on 2.23 or later.
|
||||
`getSystemRelationFieldUniversalIdentifier` 2.23 sürümünden itibaren `twenty-sdk` içinde kullanılabilir ve Twenty sunucusunun 2.23 veya daha yeni bir sürümünü gerektirir.
|
||||
</Note>
|
||||
|
||||
Besides the scalar system fields above, the server also provisions four **system relation fields** on every object: `timelineActivities`, `attachments`, `noteTargets` and `taskTargets`, each pointing at the matching standard relation object.
|
||||
Yukarıdaki skaler sistem alanlarının yanı sıra, sunucu her nesne üzerinde dört **sistem ilişki alanı** da sağlar: `timelineActivities`, `attachments`, `noteTargets` ve `taskTargets`. Bunların her biri, karşılık gelen standart ilişki nesnesini işaret eder.
|
||||
|
||||
These fields are not resolved with `getFieldUniversalIdentifier`: their identifier is derived **name-free**, from the object hosting the field and the object the field points to. That way renaming an object never changes the identifiers of its relation fields.
|
||||
Bu alanlar `getFieldUniversalIdentifier` ile çözümlenmez: tanımlayıcıları, alanı barındıran nesne ve alanın işaret ettiği nesneden **isimden bağımsız** olarak türetilir. Bu sayede bir nesnenin adını değiştirmek, ilişki alanlarının tanımlayıcılarını asla değiştirmez.
|
||||
|
||||
Use `getSystemRelationFieldUniversalIdentifier` to resolve them:
|
||||
Bunları çözümlemek için `getSystemRelationFieldUniversalIdentifier` kullanın:
|
||||
|
||||
```ts
|
||||
import {
|
||||
@@ -112,10 +111,10 @@ const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
});
|
||||
```
|
||||
|
||||
* `objectUniversalIdentifier` is the object **hosting** the field.
|
||||
* `relationTargetObjectUniversalIdentifier` is the object the field **points to**.
|
||||
* `objectUniversalIdentifier`, alanın **barındırıldığı** nesnedir.
|
||||
* `relationTargetObjectUniversalIdentifier`, alanın **işaret ettiği** nesnedir.
|
||||
|
||||
The direction is encoded by the argument order. To resolve the reverse side (e.g. `attachment.targetRocket`, the morph field the server creates on the standard relation object), swap the two:
|
||||
Yön, argüman sırasına göre kodlanır. Ters tarafı çözümlemek için (örneğin, `attachment.targetRocket`, sunucunun standart ilişki nesnesi üzerinde oluşturduğu morph alanı), ikisini değiştirin:
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
@@ -128,7 +127,7 @@ const attachmentTargetRocketFieldId =
|
||||
});
|
||||
```
|
||||
|
||||
As with scalar system fields, the resolved id works anywhere a `fieldMetadataUniversalIdentifier` is expected.
|
||||
Skaler sistem alanlarında olduğu gibi, çözümlenen kimlik, `fieldMetadataUniversalIdentifier` beklendiği her yerde çalışır.
|
||||
|
||||
## Standart Twenty nesneleri
|
||||
|
||||
|
||||
@@ -112,7 +112,7 @@ Nihai denetim sunucudadır — hem tarball yüklemesinde hem de çalışma alan
|
||||
|
||||
## Otomatik CI/CD (hazır şablonlu iş akışları)
|
||||
|
||||
`create-twenty-app` ile oluşturulan uygulamalar, kutudan çıktığı gibi `.github/workflows/` altında üç GitHub Actions iş akışıyla gelir. CI herhangi bir kurulum gerektirmez, CD tek bir gizli bilgi gerektirir ve npm'e yayınlama, bir kerelik npm trusted-publisher kurulumu gerektirir.
|
||||
`create-twenty-app` ile oluşturulan uygulamalar, kutudan çıktığı gibi `.github/workflows/` altında üç GitHub Actions iş akışıyla gelir. CI herhangi bir kurulum gerektirmez, CD tek bir secret gerektirir ve npm’e yayımlamak tek seferlik bir npm Trusted Publisher kurulumu gerektirir.
|
||||
|
||||
### CI — `ci.yml`
|
||||
|
||||
@@ -157,18 +157,18 @@ Varsayılan `TWENTY_DEPLOY_URL` olan `http://localhost:3000` bir yer tutucudur
|
||||
|
||||
Bir çekme isteğine `deploy` etiketini ekleyin. `cd.yml` içindeki `if:` koruması, ilgili PR için işi PR'in head commit'ini kullanarak çalıştırır; böylece birleştirmeden önce hedef sunucuda değişikliği doğrulayabilirsiniz.
|
||||
|
||||
### Yayınla — `publish.yml`
|
||||
### Yayımla — `publish.yml`
|
||||
|
||||
Uygulamanızı, bir sürüm etiketi (ör. `v1.0.0`) gönderdiğinizde veya Actions sekmesinden iş akışını manuel olarak çalıştırdığınızda, kanıt zinciri (provenance) ile npm'e yayınlar.
|
||||
Bir sürüm etiketi (örn. `v1.0.0`) gönderdiğinizde veya Actions sekmesinden iş akışını manuel olarak çalıştırdığınızda, uygulamanızı provenance ile npm’e yayımlar.
|
||||
|
||||
**Ne yapar:**
|
||||
|
||||
1. Uygulamanızı alır, Node.js’i kurar ve npm’i günceller (güvenilir yayımlama için npm 11.5.1 veya üstü gereklidir).
|
||||
2. `yarn twenty app:publish` komutunu çalıştırır; bu komut uygulamayı derler ve `.twenty/output` içeriğini npm’e yayımlar. CI ortamında otomatik olarak `--provenance` ve `--access public` ekler; bu nedenle iş akışında hiçbir bayrağa gerek yoktur.
|
||||
2. `yarn twenty app:publish` komutunu çalıştırır; bu komut uygulamayı der ve `.twenty/output`’u npm’e yayımlar. CI ortamında otomatik olarak `--provenance` ve `--access public` ekler; bu nedenle iş akışında hiçbir bayrağa gerek yoktur.
|
||||
|
||||
**Tek seferlik kurulum:**
|
||||
|
||||
npmjs.com’da paketinizin sayfasını açın > **Settings → Trusted Publisher** bölümüne gidin ve bu deposunu `publish.yml` iş akışıyla kaydedin ([npm trusted publishing belgelerine](https://docs.npmjs.com/trusted-publishers) bakın). Provenance ile yayımlama, paketi hangi GitHub deposunun oluşturduğunu doğrular; ayrıca Twenty pazaryerinde uygulamanızın sahipliğini bu şekilde talep edersiniz.
|
||||
npmjs.com’da paketinizin sayfasını açın > **Settings → Trusted Publisher** bölümüne gidin ve bu depoyu `publish.yml` iş akışıyla kaydedin ([npm trusted publishing belgelerine](https://docs.npmjs.com/trusted-publishers) bakın). Provenance ile yayımlama, paketi hangi GitHub deposunun oluşturduğunu doğrular; ayrıca Twenty pazaryerinde uygulamanızın sahipliğini bu şekilde talep edersiniz.
|
||||
|
||||
### Yeniden kullanılabilir eylemleri sabitleme
|
||||
|
||||
@@ -254,7 +254,7 @@ Uygulamanız `defineApplication()` içinde bir `aboutDescription` tanımlamıyor
|
||||
|
||||
### CI üzerinden yayımlama
|
||||
|
||||
Yukarıda açıklanan, iskeleti oluşturulmuş `publish.yml` iş akışı sürüm etiketlerinde, provenance ile birlikte npm’e otomatik olarak yayımlar. `yarn twenty app:publish`, CI içinde çalıştığında sizin için `--provenance` ve `--access public` eklediği için, iş akışının herhangi bir npm bayrağına ihtiyacı yoktur — yalnızca tek seferlik güvenilir yayımlayıcı kurulumuna ihtiyaç duyar.
|
||||
Yukarıda açıklanan, şablon olarak sağlanan `publish.yml` iş akışı sürüm etiketlerinde provenance ile npm’e otomatik olarak yayımlar. `yarn twenty app:publish`, CI içinde çalıştığında sizin için `--provenance` ve `--access public` eklediği için, iş akışının herhangi bir npm bayrağına ihtiyacı yoktur — yalnızca tek seferlik güvenilir yayımlayıcı kurulumuna ihtiyaç duyar.
|
||||
|
||||
Diğer CI sistemleri (GitLab CI, CircleCI vb.) için önce `yarn install`, ardından `yarn twenty app:publish` komutunu çalıştırın. Ortam bir OIDC jetonu oluşturabildiğinde provenance üretilir, aksi durumda ise otomatik olarak atlanır.
|
||||
|
||||
|
||||
@@ -259,4 +259,4 @@ Bu, uygulamanızın `tsconfig.json` dosyasına göre `tsc --noEmit` komutunu ça
|
||||
|
||||
İskelet oluşturucu, `.github/workflows/ci.yml` konumunda kullanıma hazır bir iş akışı üretir. `main` dalına yapılan her itmede ve her çekme isteğinde, çalıştırıcı içinde geçici bir Twenty sunucusu başlatır (`twentyhq/twenty/.github/actions/spawn-twenty-app-dev-test` eylemi aracılığıyla) ve ardından `yarn lint`, `yarn typecheck`, `yarn test:unit` ve `yarn test` komutlarını, `TWENTY_API_URL` / `TWENTY_API_KEY` bu sunucuyu işaret edecek şekilde çalıştırır. Herhangi bir gizli bilgi gerekmez ve iş akışının en üstündeki `TWENTY_VERSION` ortam değişkeni aracılığıyla sunucu sürümünü sabitleyebilirsiniz.
|
||||
|
||||
Üç iskelet iş akışının (npm yayınlama için `ci.yml`, `cd.yml` dağıtım hattı ve `publish.yml`) eksiksiz adım adım anlatımı için [Yayınlama → Otomatik CI/CD](/l/tr/developers/extend/apps/operations/publishing#automated-cicd-scaffolded-workflows) bölümüne bakın.
|
||||
Üç iskelet iş akışının (`ci.yml`, `cd.yml` dağıtım hattı ve npm yayınlama için `publish.yml`) eksiksiz adım adım anlatımı için [Yayınlama → Otomatik CI/CD](/l/tr/developers/extend/apps/operations/publishing#automated-cicd-scaffolded-workflows) bölümüne bakın.
|
||||
|
||||
@@ -93,7 +93,7 @@ export default defineView({
|
||||
|
||||
除了上面的标量系统字段之外，服务器还会在每个对象上预置四个**系统关系字段**：`timelineActivities`、`attachments`、`noteTargets` 和 `taskTargets`，它们各自指向相应的标准关系对象。
|
||||
|
||||
这些字段不会通过 `getFieldUniversalIdentifier` 解析：它们的标识符是**与名称无关**地，从承载该字段的对象以及该字段指向的对象中派生出来的。 通过这种方式，重命名对象永远不会改变其关系字段的标识符。
|
||||
这些字段不会通过 `getFieldUniversalIdentifier` 解析：其标识符不依赖名称，而是由承载该字段的对象和该字段指向的对象推导而来。 通过这种方式，重命名对象永远不会改变其关系字段的标识符。
|
||||
|
||||
使用 `getSystemRelationFieldUniversalIdentifier` 来解析它们：
|
||||
|
||||
@@ -115,7 +115,7 @@ const rocketAttachmentsFieldId = getSystemRelationFieldUniversalIdentifier({
|
||||
* `objectUniversalIdentifier` 是**承载**该字段的对象。
|
||||
* `relationTargetObjectUniversalIdentifier` 是该字段**指向**的对象。
|
||||
|
||||
方向由参数的顺序编码。 要解析反向端（例如 `attachment.targetRocket`，即服务器在标准关联对象上创建的 morph 字段），交换这两个参数：
|
||||
方向由参数的顺序编码。 要解析反向端（例如 `attachment.targetRocket`，即服务器在标准关系对象上创建的 morph 字段），交换这两个参数：
|
||||
|
||||
```ts
|
||||
// attachment.targetRocket — the reverse morph field on Attachment
|
||||
|
||||
Reference in New Issue
Block a user