Cette page fait partie d’une compétence d’agent de code IA et est écrite pour les agents, pas pour les humains. Pour la documentation Base44 lisible par un humain, consultez la documentation développeur.

Créer des entités

Les entités Base44 sont définies localement dans votre projet puis poussées vers le backend Base44.

Critique : nommage des fichiers

Les fichiers d’entités DOIVENT utiliser le kebab-case : {kebab-case-name}.jsonc

Nom d’entité	Nom de fichier
`Task`	`task.jsonc`
`TeamMember`	`team-member.jsonc`
`ActivityLog`	`activity-log.jsonc`

MAUVAIS : TeamMember.jsonc, teamMember.jsonc BON : team-member.jsonc

Table des matières

Créer des entités

Répertoire des entités

Toutes les définitions d’entités doivent être placées dans le dossier base44/entities/ à la racine de votre projet. Chaque entité est définie dans son propre fichier .jsonc. Structure d’exemple :

my-app/
  base44/
    entities/
      user.jsonc
      product.jsonc
      order.jsonc

Comment créer une entité

Créez un nouveau fichier .jsonc dans le répertoire base44/entities/
Définissez le schéma de votre entité en suivant la structure ci-dessous
Poussez les changements vers Base44 avec le CLI

Structure du schéma d’entité

Chaque fichier d’entité suit une structure de type JSON Schema :

{
  "name": "EntityName",       // PascalCase entity name
  "type": "object",           // Always "object"
  "properties": {
    // Define your fields here
  },
  "required": ["field1"]      // Array of required field names
}

Erreur courante : propriété schema imbriquée

MAUVAIS — N’enveloppez PAS les propriétés dans un objet schema :

{
  "name": "Task",
  "description": "A task entity",
  "schema": {                    // ❌ WRONG - don't use nested "schema"
    "type": "object",
    "properties": { ... }
  }
}

CORRECT — Placez type et properties au niveau supérieur :

{
  "name": "Task",
  "description": "A task entity",
  "type": "object",              // ✅ CORRECT - top level
  "properties": { ... }          // ✅ CORRECT - top level
}

C’est une erreur fréquente qui provoque des erreurs « Invalid schema: Schema must have a ‘type’ field » lors du push des entités.

Types de champs pris en charge

String

Champ texte simple :

{
  "title": {
    "type": "string",
    "description": "Task title"
  }
}

Avec un format :

{
  "due_date": {
    "type": "string",
    "format": "date",
    "description": "Due date"
  }
}

Formats disponibles : date, date-time, time, email, uri, hostname, ipv4, ipv6, uuid, file, regex, richtext

String avec Enum

Contrainte à des valeurs précises :

{
  "status": {
    "type": "string",
    "enum": ["todo", "in_progress", "done"],
    "default": "todo",
    "description": "Current status"
  }
}

Number

{
  "position": {
    "type": "number",
    "description": "Position for ordering"
  }
}

Integer

Pour les nombres entiers uniquement :

{
  "quantity": {
    "type": "integer",
    "description": "Item quantity",
    "minimum": 0,
    "maximum": 1000
  }
}

Binary

Pour les données fichiers/blobs :

{
  "attachment": {
    "type": "binary",
    "description": "File attachment"
  }
}

Boolean

{
  "notify_on_change": {
    "type": "boolean",
    "default": true,
    "description": "Enable notifications"
  }
}

Tableau de strings

{
  "labels": {
    "type": "array",
    "items": { "type": "string" },
    "description": "Task labels/tags"
  }
}

Tableau d’objets

{
  "attachments": {
    "type": "array",
    "description": "File attachments",
    "items": {
      "type": "object",
      "properties": {
        "name": { "type": "string" },
        "url": { "type": "string" },
        "type": { "type": "string" }
      }
    }
  }
}

Propriétés des champs

Propriété	Description
`type`	Type de données : `string`, `number`, `integer`, `boolean`, `array`, `object`, `binary`
`description`	Description lisible du champ
`enum`	Tableau des valeurs autorisées (pour les strings)
`enumNames`	Étiquettes lisibles pour les valeurs d’enum (même ordre que `enum`)
`default`	Valeur par défaut si non fournie
`format`	Indication de format : `date`, `date-time`, `time`, `email`, `uri`, `hostname`, `ipv4`, `ipv6`, `uuid`, `file`, `regex`, `richtext`
`items`	Schéma pour les éléments d’un tableau
`properties`	Propriétés imbriquées pour les types objet
`$ref`	Référence vers une autre définition de schéma
`minLength`	Longueur minimale d’une string
`maxLength`	Longueur maximale d’une string
`pattern`	Motif regex pour valider une string
`minimum`	Valeur minimale pour les nombres
`maximum`	Valeur maximale pour les nombres
`rls`	Règles de sécurité au niveau champ (voir la section Field Level Security)

Exemple complet

Voici une définition complète d’entité pour une Task :

{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "Task title"
    },
    "description": {
      "type": "string",
      "description": "Task description"
    },
    "status": {
      "type": "string",
      "enum": ["todo", "in_progress", "done"],
      "default": "todo",
      "description": "Current status of the task"
    },
    "board_id": {
      "type": "string",
      "description": "Board this task belongs to"
    },
    "assignee_email": {
      "type": "string",
      "description": "Email of assigned user"
    },
    "priority": {
      "type": "string",
      "enum": ["low", "medium", "high"],
      "default": "medium",
      "description": "Task priority"
    },
    "due_date": {
      "type": "string",
      "format": "date",
      "description": "Due date"
    },
    "labels": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Task labels/tags"
    }
  },
  "required": ["title"]
}

Conventions de nommage

Nom d’entité : utilisez PascalCase avec des caractères alphanumériques uniquement (par exemple, Task, TeamMember, ActivityLog)
- Doit correspondre au motif : /^[a-zA-Z0-9]+$/
- Valides : Task, TeamMember, Order123
- Invalides : Team_Member, Team-Member, Team Member
Nom de fichier : utilisez le kebab-case correspondant à l’entité (par exemple, task.jsonc, team-member.jsonc, activity-log.jsonc)
Noms des champs : utilisez snake_case (par exemple, board_id, user_email, due_date)

Relations entre entités

Pour créer des relations entre entités, utilisez des champs de référence par ID :

{
  "board_id": {
    "type": "string",
    "description": "Board this task belongs to"
  },
  "team_id": {
    "type": "string",
    "description": "Associated team ID"
  }
}

Row Level Security (RLS)

Le Row Level Security (RLS) contrôle les enregistrements auxquels les utilisateurs peuvent accéder selon leur identité et leurs attributs. Les règles RLS sont définies par entité dans le champ rls du schéma. Important : si aucune RLS n’est définie, tous les enregistrements sont accessibles à tous les utilisateurs.

Opérations RLS

RLS prend en charge cinq opérations :

Opération	Description
`create`	Contrôle qui peut ajouter de nouveaux enregistrements
`read`	Contrôle qui peut voir les enregistrements
`update`	Contrôle qui peut modifier les enregistrements
`delete`	Contrôle qui peut retirer les enregistrements
`write`	Raccourci pour `create`, `update` et `delete` combinés

Valeurs de permission

Chaque opération accepte l’une des valeurs suivantes :

true — autoriser tous les utilisateurs (y compris anonymes/non authentifiés)
false — bloquer tous les utilisateurs
Objet de condition — autoriser les utilisateurs qui correspondent à la condition

Variables de template

Utilisez les variables de template pour référencer les attributs de l’utilisateur actuel :

Template	Description
`{{user.id}}`	L’ID de l’utilisateur
`{{user.email}}`	L’e-mail de l’utilisateur
`{{user.role}}`	Le rôle de l’utilisateur
`{{user.data.field_name}}`	Champ personnalisé de l’objet `data` de l’utilisateur

Attributs intégrés d’entité

Chaque enregistrement d’entité dispose de ces attributs intégrés pour les règles RLS :

Attribut	Description
`id`	Identifiant unique de l’enregistrement
`created_date`	Horodatage de la création de l’enregistrement
`updated_date`	Horodatage de la dernière mise à jour
`created_by`	E-mail de l’utilisateur qui a créé l’enregistrement

Types de règles

Il existe deux types de conditions utilisables : 1. Comparaison entité vers utilisateur — comparer les champs d’un enregistrement aux valeurs de l’utilisateur actuel :

{
  "created_by": "{{user.email}}"
}

2. Vérification de condition utilisateur — vérifier les propriétés utilisateur directement avec user_condition :

{
  "user_condition": { "role": "admin" }
}

Notes importantes :

user_condition ne prend en charge que l’égalité simple (par exemple, { "role": "admin" })
Le filtrage sur les champs d’entité nécessite le préfixe data. : utilisez { "data.fieldname": value } pour filtrer par valeur de champ d’entité
Pour les comparaisons sur les champs data.*, vous pouvez utiliser les opérateurs : $in, $nin, $ne, $all
Les opérateurs logiques $or, $and, $nor sont disponibles pour combiner les conditions

⚠️ Pour les modèles RLS avancés et des exemples, consultez rls-examples.md

Exemples RLS

Accès propriétaire uniquement :

{
  "created_by": "{{user.email}}"
}

Accès basé sur le département :

{
  "data.department": "{{user.data.department}}"
}

Accès admin uniquement :

{
  "user_condition": { "role": "admin" }
}

Configuration RLS complète :

{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "Task title"
    },
    "status": {
      "type": "string",
      "enum": ["todo", "in_progress", "done"],
      "default": "todo"
    }
  },
  "required": ["title"],
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Modèles RLS courants

Création publique, gestion admin uniquement (par exemple, formulaires de contact, listes d’attente) :

{
  "rls": {
    "create": true,
    "read": { "user_condition": { "role": "admin" } },
    "update": { "user_condition": { "role": "admin" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

Accès propriétaire uniquement :

{
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Utilisateurs connectés uniquement :

{
  "rls": {
    "create": { "user_condition": { "id": "{{user.id}}" } },
    "read": true,
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Limitations

user_condition en égalité uniquement : user_condition ne prend en charge que la correspondance exacte (par exemple, { "role": "admin" }) — pas d’opérateurs
Pas d’opérateurs de comparaison sur user_condition : $gt, $lt, $regex, $expr, $where NE sont PAS pris en charge pour les conditions utilisateur
Pas de templates profondément imbriqués : des templates comme {{user.data.profile.department}} peuvent ne pas fonctionner

Opérateurs pris en charge :

Opérateurs logiques : $or, $and, $nor pour combiner plusieurs conditions
Opérateurs de champ (pour les champs data.* uniquement) : $in, $nin, $ne, $all
Filtrage sur les champs d’entité : utilisez le préfixe data. pour filtrer par valeur de champ d’entité (par exemple, { "data.status": "published" } ou { "data.completed": true })

⚠️ Consultez rls-examples.md pour des modèles et exemples RLS complets

Modèles d’accès complexes

Pour les modèles d’accès complexes qui nécessitent plusieurs conditions (par exemple, « propriétaire OU admin »), vous avez plusieurs options :

Utiliser l’UI du tableau de bord Base44 — le tableau de bord permet d’ajouter plusieurs règles par opération avec une logique OU
Utiliser des entités séparées — répartir les données dans plusieurs entités avec des règles d’accès différentes
Utiliser des fonctions backend — implémenter une logique d’accès personnalisée dans des fonctions backend

Field Level Security (FLS)

La Field Level Security permet de contrôler l’accès à des champs individuels d’une entité. Les règles FLS sont définies dans le schéma de chaque champ via la propriété rls.

Opérations FLS

FLS prend en charge les mêmes opérations que la RLS au niveau entité :

Opération	Description
`create`	Contrôle qui peut définir ce champ à la création d’enregistrements
`read`	Contrôle qui peut voir ce champ
`update`	Contrôle qui peut modifier ce champ
`delete`	Contrôle qui peut effacer ce champ
`write`	Raccourci pour `create`, `update` et `delete` combinés

Exemple FLS

{
  "name": "Employee",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Employee name"
    },
    "salary": {
      "type": "number",
      "description": "Employee salary",
      "rls": {
        "read": { "user_condition": { "role": "hr" } },
        "update": { "user_condition": { "role": "hr" } }
      }
    },
    "department": {
      "type": "string",
      "description": "Department name"
    }
  },
  "required": ["name"]
}

Dans cet exemple, seuls les utilisateurs avec le rôle hr peuvent lire ou mettre à jour le champ salary. Tous les utilisateurs ayant accès à l’entité peuvent lire/mettre à jour les autres champs.

Notes FLS

Si aucune RLS n’est définie au niveau champ, le champ hérite des règles RLS au niveau entité
Les règles FLS suivent le même format de conditions que la RLS au niveau entité
Utilisez FLS pour les champs sensibles comme salaire, SSN ou notes internes

Pousser les entités

La commande entities push pousse toutes les entités présentes dans le dossier base44/entities.

npx base44 entities push

Pour plus de détails sur la commande push, consultez entities-push.md.

Cette page a été traduite à l’aide de l’IA. Pour les informations les plus précises et à jour, consultez la version anglaise.

​Créer des entités

​Critique : nommage des fichiers

​Table des matières

​Répertoire des entités

​Comment créer une entité

​Structure du schéma d’entité

​Erreur courante : propriété schema imbriquée

​Types de champs pris en charge

​String

​String avec Enum

​Number

​Integer

​Binary

​Boolean

​Tableau de strings

​Tableau d’objets

​Propriétés des champs

​Exemple complet

​Conventions de nommage

​Relations entre entités

​Row Level Security (RLS)

​Opérations RLS

​Valeurs de permission

​Variables de template

​Attributs intégrés d’entité

​Types de règles

​Exemples RLS

​Modèles RLS courants

​Limitations

​Modèles d’accès complexes

​Field Level Security (FLS)

​Opérations FLS

​Exemple FLS

​Notes FLS

​Pousser les entités

Créer des entités

Critique : nommage des fichiers

Table des matières

Répertoire des entités

Comment créer une entité

Structure du schéma d’entité

Erreur courante : propriété schema imbriquée

Types de champs pris en charge

String

String avec Enum

Number

Integer

Binary

Boolean

Tableau de strings

Tableau d’objets

Propriétés des champs

Exemple complet

Conventions de nommage

Relations entre entités

Row Level Security (RLS)

Opérations RLS

Valeurs de permission

Variables de template

Attributs intégrés d’entité

Types de règles

Exemples RLS

Modèles RLS courants

Limitations

Modèles d’accès complexes

Field Level Security (FLS)

Opérations FLS

Exemple FLS

Notes FLS

Pousser les entités