i18n - docs translations (#15720)
Created by Github action <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Adds a full French documentation set covering developers (API, webhooks, backend/frontend, self‑hosting) and user guide (CRM essentials, data model, workflows, settings, integrations, pricing, reporting). > > - **Docs (FR i18n)**: > - **Developers**: Add `API`, `Webhooks`, backend (best practices, custom objects, feature flags, architecture, commands, Zapier), frontend (best practices, architecture, commands, hotkeys, style guide, Storybook, Figma), self‑hosting (Docker Compose, upgrade guide, cloud providers), introduction. > - **User Guide**: Add getting started (what is Twenty, create/configure workspace, migration, import/export), CRM essentials (contacts/accounts, pipelines, views), data model (objects, fields, relations, table views), collaboration (emails/calendars, notes, tasks), integrations API (overview, integrations), workflows (getting started, features, credits, internal automations, services), settings (profile, permissions, members, domains, releases, email/calendar setup), pricing (billing/FAQ), reporting overview, resources (GitHub, glossary), introduction. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 9ba8c2457156e8d25bf41c055731acface4b5277. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: github-actions <github-actions@twenty.com> Co-authored-by: Félix Malfait <felix@twenty.com>
This commit is contained in:
github-actions[bot]
committed by
GitHub
GitHub
parent
0fc538ac09
commit
154fb4665e
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Meilleures pratiques
|
||||
image: /images/user-guide/tips/light-bulb.png
|
||||
---
|
||||
|
||||
<Frame>
|
||||
<img src="/images/user-guide/tips/light-bulb.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
Ce document décrit les meilleures pratiques à suivre lors de travaux sur le backend.
|
||||
|
||||
## Suivez une approche modulaire
|
||||
|
||||
Le backend suit une approche modulaire, qui est un principe fondamental lors de l'utilisation de NestJS. Assurez-vous de décomposer votre code en modules réutilisables pour maintenir une base de code propre et organisée.
|
||||
Chaque module doit encapsuler une fonctionnalité particulière et avoir un périmètre bien défini. Cette approche modulaire permet une séparation claire des préoccupations et supprime les complexités inutiles.
|
||||
|
||||
## Exposez des services à utiliser dans les modules
|
||||
|
||||
Créez toujours des services avec une responsabilité claire et unique, ce qui améliore la lisibilité et la maintenabilité du code. Nommez les services de manière descriptive et cohérente.
|
||||
|
||||
Vous devez également exposer les services que vous souhaitez utiliser dans d'autres modules. Exposer des services à d'autres modules est possible grâce au puissant système d'injection de dépendance de NestJS, et favorise un couplage lâche entre les composants.
|
||||
|
||||
## Évitez d'utiliser le type `any`
|
||||
|
||||
Lorsque vous déclarez une variable comme `any`, le vérificateur de type de TypeScript ne procède à aucune vérification, rendant possible l'assignation de n'importe quel type de valeur à la variable. TypeScript utilise l'inférence de type pour déterminer le type d'une variable en fonction de sa valeur. En le déclarant comme `any`, TypeScript ne peut plus deviner le type. Cela rend difficile la détection des erreurs liées aux types pendant le développement, conduisant à des erreurs d'exécution et rendant le code moins maintenable, moins fiable et plus difficile à comprendre pour d'autres.
|
||||
|
||||
C'est pourquoi tout devrait avoir un type. Donc si vous créez un nouvel objet avec un prénom et un nom, vous devriez créer une interface ou un type contenant un prénom et un nom qui définit la forme de l'objet que vous manipulez.
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Objets personnalisés
|
||||
image: /images/user-guide/objects/objects.png
|
||||
---
|
||||
|
||||
<Frame>
|
||||
<img src="/images/user-guide/objects/objects.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
Les objets sont des structures qui vous permettent de stocker des données (enregistrements, attributs et valeurs) spécifiques à une organisation. Twenty fournit à la fois des objets standard et personnalisés.
|
||||
|
||||
Les objets standard sont des objets intégrés avec un ensemble d'attributs disponibles pour tous les utilisateurs. Les exemples d'objets standard dans Twenty incluent Société et Personne. Les objets standard ont des champs standard également disponibles pour tous les utilisateurs de Twenty, comme Company.displayName.
|
||||
|
||||
Les objets personnalisés sont des objets que vous pouvez créer pour stocker des informations uniques à votre organisation. Ils ne sont pas intégrés ; les membres de votre espace de travail peuvent créer et personnaliser des objets personnalisés pour contenir des informations que les objets standard ne conviennent pas.
|
||||
|
||||
## Schéma de haut niveau
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/images/docs/server/custom-object-schema.png" alt="High level schema" />
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
## Comment cela fonctionne
|
||||
|
||||
Les objets personnalisés proviennent de tables de métadonnées qui déterminent la forme, le nom et le type des objets. Toutes ces informations sont présentes dans la base de données des schémas de métadonnées, composée de tables :
|
||||
|
||||
- **DataSource** : Détaille où les données sont présentes.
|
||||
- **Objet** : Décrit l'objet et lie à une DataSource.
|
||||
- **Champ** : Décrit les champs d'un objet et se connecte à l'objet.
|
||||
|
||||
Pour ajouter un objet personnalisé, le workspaceMember interrogera l'API /metadata. Cela met à jour les métadonnées en conséquence et calcule un schéma GraphQL basé sur les métadonnées, en le stockant dans un cache GQL pour une utilisation ultérieure.
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/images/docs/server/add-custom-objects.jpeg" alt="Query the /metadata API to add custom objects" />
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
Pour obtenir des données, le processus implique de faire des requêtes via le point de terminaison /graphql et de les transmettre via le Query Resolver.
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/images/docs/server/custom-object-schema.png" alt="Query the /graphql endpoint to fetch data" />
|
||||
</div>
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Drapeaux de fonctionnalité
|
||||
image: /images/user-guide/table-views/table.png
|
||||
---
|
||||
|
||||
<Frame>
|
||||
<img src="/images/user-guide/table-views/table.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
Les drapeaux de fonctionnalité sont utilisés pour masquer les fonctionnalités expérimentales. Pour Twenty, ils sont définis au niveau de l'espace de travail et non au niveau de l'utilisateur.
|
||||
|
||||
## Ajout d'un nouveau drapeau de fonctionnalité
|
||||
|
||||
Dans `FeatureFlagKey.ts` ajoutez l'indicateur de fonctionnalité :
|
||||
|
||||
```ts
|
||||
type FeatureFlagKey =
|
||||
| 'IS_FEATURENAME_ENABLED'
|
||||
| ...;
|
||||
```
|
||||
|
||||
Ajoutez-le également à l'énumération dans `feature-flag.entity.ts` :
|
||||
|
||||
```ts
|
||||
enum FeatureFlagKeys {
|
||||
IsFeatureNameEnabled = 'IS_FEATURENAME_ENABLED',
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Pour appliquer un drapeau de fonctionnalité sur une fonctionnalité de **backend**, utilisez :
|
||||
|
||||
```ts
|
||||
@Gate({
|
||||
featureFlag: 'IS_FEATURENAME_ENABLED',
|
||||
})
|
||||
```
|
||||
|
||||
Pour appliquer un drapeau de fonctionnalité sur une fonctionnalité de **frontend**, utilisez :
|
||||
|
||||
```ts
|
||||
const isFeatureNameEnabled = useIsFeatureEnabled('IS_FEATURENAME_ENABLED');
|
||||
```
|
||||
|
||||
## Configurer les drapeaux de fonctionnalité pour le déploiement
|
||||
|
||||
Modifiez l'enregistrement correspondant dans la Table `core.featureFlag` :
|
||||
|
||||
| iD | clé | workspaceId | valeur |
|
||||
| --------- | ------------------------ | ----------- | ------ |
|
||||
| Aléatoire | `IS_FEATURENAME_ENABLED` | WorkspaceID | `vrai` |
|
||||
+130
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: Architecture des Dossiers
|
||||
info: Un regard détaillé sur l'architecture des dossiers de notre serveur
|
||||
image: /images/user-guide/fields/field.png
|
||||
---
|
||||
|
||||
<Frame>
|
||||
<img src="/images/user-guide/fields/field.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
La structure du répertoire backend est la suivante :
|
||||
|
||||
```
|
||||
server
|
||||
└───ability
|
||||
└───constants
|
||||
└───core
|
||||
└───database
|
||||
└───decorators
|
||||
└───filters
|
||||
└───guards
|
||||
└───health
|
||||
└───integrations
|
||||
└───metadata
|
||||
└───workspace
|
||||
└───utils
|
||||
```
|
||||
|
||||
## Capacité
|
||||
|
||||
Définit les permissions et inclut des gestionnaires pour chaque entité.
|
||||
|
||||
## Décorateurs
|
||||
|
||||
Définit des décorateurs personnalisés dans NestJS pour des fonctionnalités supplémentaires.
|
||||
|
||||
Voir [décorateurs personnalisés](https://docs.nestjs.com/custom-decorators) pour plus de détails.
|
||||
|
||||
## Filtres
|
||||
|
||||
Inclut des filtres d'exception pour gérer les exceptions qui pourraient se produire dans les points de terminaison GraphQL.
|
||||
|
||||
## Gardes
|
||||
|
||||
Voir [gardiens](https://docs.nestjs.com/guards) pour plus de détails.
|
||||
|
||||
## Santé
|
||||
|
||||
Inclut une API REST disponible publiquement (healthz) qui renvoie un JSON pour confirmer si la base de données fonctionne comme prévu.
|
||||
|
||||
## Métadonnées
|
||||
|
||||
Définit des objets personnalisés et met une API GraphQL à disposition (graphql/metadata).
|
||||
|
||||
## Espace de travail
|
||||
|
||||
Génère et sert un schéma GraphQL personnalisé basé sur les métadonnées.
|
||||
|
||||
### Structure du répertoire de l'espace de travail
|
||||
|
||||
```
|
||||
workspace
|
||||
|
||||
└───workspace-schema-builder
|
||||
└───factories
|
||||
└───graphql-types
|
||||
└───database
|
||||
└───interfaces
|
||||
└───object-definitions
|
||||
└───services
|
||||
└───storage
|
||||
└───utils
|
||||
└───workspace-resolver-builder
|
||||
└───factories
|
||||
└───interfaces
|
||||
└───workspace-query-builder
|
||||
└───factories
|
||||
└───interfaces
|
||||
└───workspace-query-runner
|
||||
└───interfaces
|
||||
└───utils
|
||||
└───workspace-datasource
|
||||
└───workspace-manager
|
||||
└───workspace-migration-runner
|
||||
└───utils
|
||||
└───workspace.module.ts
|
||||
└───workspace.factory.spec.ts
|
||||
└───workspace.factory.ts
|
||||
```
|
||||
|
||||
La racine du répertoire de l'espace de travail inclut le fichier `workspace.factory.ts`, qui contient la fonction `createGraphQLSchema`. Cette fonction génère un schéma spécifique à l'espace de travail en utilisant les métadonnées pour adapter un schéma pour chaque espace de travail. En séparant la construction du schéma et du résolveur, nous utilisons la fonction `makeExecutableSchema`, qui combine ces éléments distincts.
|
||||
|
||||
Cette stratégie n'est pas seulement une question d'organisation, mais aide également à l'optimisation, comme la mise en cache des définitions de type générées pour améliorer les performances et la scalabilité.
|
||||
|
||||
### Constructeur de schéma d'espace de travail
|
||||
|
||||
Génère le schéma GraphQL, et inclut :
|
||||
|
||||
#### Usines :
|
||||
|
||||
Constructeurs spécialisés pour générer des constructions liées à GraphQL.
|
||||
|
||||
- La type.factory traduit les métadonnées de champs en types GraphQL en utilisant le `TypeMapperService`.
|
||||
- La type-definition.factory crée des objets d'entrée ou de sortie GraphQL dérivés de `objectMetadata`.
|
||||
|
||||
#### Types GraphQL
|
||||
|
||||
Inclut des énumérations, des entrées, des objets et des scalaires, et sert de blocs de construction pour la construction du schéma.
|
||||
|
||||
#### Interfaces et définitions d'objets
|
||||
|
||||
Contient les plans pour les entités GraphQL, et inclut à la fois des types prédéfinis et personnalisés comme `MONEY` ou `URL`.
|
||||
|
||||
#### Services
|
||||
|
||||
Contient le service responsable de l'association du FieldMetadataType avec son type scalaire ou modificateur de requête GraphQL approprié.
|
||||
|
||||
#### Stockage
|
||||
|
||||
Inclut la classe `TypeDefinitionsStorage` qui contient des définitions de type réutilisables, empêchant la duplication des types GraphQL.
|
||||
|
||||
### Constructeur de résolveur d'espace de travail
|
||||
|
||||
Crée des fonctions de résolveur pour interroger et modifier le schéma GraphQL.
|
||||
|
||||
Chaque usine de ce répertoire est responsable de la production d'un type de résolveur distinct, comme le `FindManyResolverFactory`, conçu pour une application adaptable à plusieurs tables.
|
||||
|
||||
### Exécuteur de requêtes d'espace de travail
|
||||
|
||||
Exécute les requêtes générées sur la base de données et analyse le résultat.
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: Commandes Backend
|
||||
image: /images/user-guide/kanban-views/kanban.png
|
||||
---
|
||||
|
||||
<Frame>
|
||||
<img src="/images/user-guide/kanban-views/kanban.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
## Commandes utiles
|
||||
|
||||
Ces commandes doivent être exécutées depuis le dossier packages/twenty-server.
|
||||
Depuis n'importe quel autre dossier, vous pouvez exécuter `npx nx <commande> twenty-server` (ou `npx nx run twenty-server:<commande>`).
|
||||
|
||||
### Configuration initiale
|
||||
|
||||
```
|
||||
npx nx database:reset twenty-server # setup the database with dev seeds
|
||||
```
|
||||
|
||||
### Démarrer le serveur
|
||||
|
||||
```
|
||||
npx nx run twenty-server:start
|
||||
```
|
||||
|
||||
### Analyse
|
||||
|
||||
```
|
||||
npx nx run twenty-server:lint # pass --fix to fix lint errors
|
||||
```
|
||||
|
||||
### Test
|
||||
|
||||
```
|
||||
npx nx run twenty-server:test:unit # run unit tests
|
||||
npx nx run twenty-server:test:integration # run integration tests
|
||||
```
|
||||
|
||||
Remarque: vous pouvez exécuter `npx nx run twenty-server:test:integration:with-db-reset` si vous avez besoin de réinitialiser la base de données avant de lancer les tests d'intégration.
|
||||
|
||||
### Réinitialiser la base de données
|
||||
|
||||
Si vous souhaitez réinitialiser et peupler la base de données, vous pouvez exécuter la commande suivante :
|
||||
|
||||
```bash
|
||||
npx nx run twenty-server:database:reset
|
||||
```
|
||||
|
||||
### Migrations
|
||||
|
||||
#### Pour les objets dans les schémas Core/Metadata (TypeORM)
|
||||
|
||||
```bash
|
||||
npx nx run twenty-server:typeorm migration:generate src/database/typeorm/core/migrations/nameOfYourMigration -d src/database/typeorm/core/core.datasource.ts
|
||||
```
|
||||
|
||||
#### Pour les objets de l'Espace de travail
|
||||
|
||||
Il n'y a pas de fichiers de migrations, les migrations sont générées automatiquement pour chaque espace de travail, stockées dans la base de données et appliquées avec cette commande
|
||||
|
||||
```bash
|
||||
npx nx run twenty-server:command workspace:sync-metadata -f
|
||||
```
|
||||
|
||||
<Warning>
|
||||
|
||||
Cette action supprimera la base de données et relancera les migrations et les semences.
|
||||
|
||||
Assurez-vous de sauvegarder toutes les données que vous souhaitez conserver avant d'exécuter cette commande.
|
||||
|
||||
</Warning>
|
||||
|
||||
## Écosystème Tech
|
||||
|
||||
Twenty utilise principalement NestJS pour le backend.
|
||||
|
||||
Prisma a été le premier ORM que nous avons utilisé. Mais pour permettre aux utilisateurs de créer des champs et objets personnalisés, un niveau inférieur avait plus de sens car nous avons besoin d'un contrôle granulaire. Le projet utilise maintenant TypeORM.
|
||||
|
||||
Voici à quoi ressemble maintenant la pile technologique.
|
||||
|
||||
**Noyau**
|
||||
|
||||
- [NestJS](https://nestjs.com/)
|
||||
- [TypeORM](https://typeorm.io/)
|
||||
- [GraphQL Yoga](https://the-guild.dev/graphql/yoga-server)
|
||||
|
||||
**Base de données**
|
||||
|
||||
- [Postgres](https://www.postgresql.org/)
|
||||
|
||||
**Intégrations tierces**
|
||||
|
||||
- [Sentry](https://sentry.io/welcome/) pour suivre les bugs.
|
||||
|
||||
**Tests**
|
||||
|
||||
- [Jest](https://jestjs.io/)
|
||||
|
||||
**Outils**
|
||||
|
||||
- [Yarn](https://yarnpkg.com/)
|
||||
- [ESLint](https://eslint.org/)
|
||||
|
||||
**Développement**
|
||||
|
||||
- [AWS EKS](https://aws.amazon.com/eks/)
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: Application Zapier
|
||||
image: /images/user-guide/integrations/plug.png
|
||||
---
|
||||
|
||||
<Frame>
|
||||
<img src="/images/user-guide/integrations/plug.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
Synchronisez facilement Twenty avec plus de 3000 applications à l'aide de [Zapier](https://zapier.com/). Automatisez les tâches, boostez la productivité et dynamisez vos relations client !
|
||||
|
||||
## À propos de Zapier
|
||||
|
||||
Zapier est un outil qui vous permet d'automatiser des flux de travail en connectant les applications que votre équipe utilise quotidiennement. Le concept fondamental de Zapier est l'automatisation des flux de travail, appelés Zaps, et inclut des déclencheurs et des actions.
|
||||
|
||||
Vous pouvez en savoir plus sur le fonctionnement de Zapier [ici](https://zapier.com/how-it-works).
|
||||
|
||||
## Installation
|
||||
|
||||
### Étape 1 : Installez les packages Zapier
|
||||
|
||||
```bash
|
||||
cd packages/twenty-zapier
|
||||
|
||||
yarn
|
||||
```
|
||||
|
||||
### Étape 2 : Connectez-vous avec le CLI
|
||||
|
||||
Utilisez vos identifiants Zapier pour vous connecter en utilisant le CLI :
|
||||
|
||||
```bash
|
||||
zapier login
|
||||
```
|
||||
|
||||
### Étape 3 : Configurer les variables d'environnement
|
||||
|
||||
Depuis le dossier `packages/twenty-zapier`, exécutez :
|
||||
|
||||
```bash
|
||||
cp .env.example .env
|
||||
```
|
||||
|
||||
Exécutez l'application localement, rendez-vous sur [http://localhost:3000/settings/api-webhooks](http://localhost:3000/settings/api-webhooks) et générez une clé API.
|
||||
|
||||
Remplacez la valeur **YOUR_API_KEY** dans le fichier `.env` par la clé API que vous venez de générer.
|
||||
|
||||
## Développement
|
||||
|
||||
<Warning>
|
||||
|
||||
Assurez-vous d'exécuter `yarn build` avant toute commande `zapier`.
|
||||
|
||||
</Warning>
|
||||
|
||||
### Test
|
||||
|
||||
```bash
|
||||
yarn test
|
||||
```
|
||||
|
||||
### Analyse
|
||||
|
||||
```bash
|
||||
yarn format
|
||||
```
|
||||
|
||||
### Surveillez et compilez pendant que vous éditez le code
|
||||
|
||||
```bash
|
||||
yarn watch
|
||||
```
|
||||
|
||||
### Validez votre application Zapier
|
||||
|
||||
```bash
|
||||
yarn validate
|
||||
```
|
||||
|
||||
### Déployez votre application Zapier
|
||||
|
||||
```bash
|
||||
yarn deploy
|
||||
```
|
||||
|
||||
### Liste de toutes les commandes CLI de Zapier
|
||||
|
||||
```bash
|
||||
zapier
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user