Chapitre 4 : Formulaires et détails — saisir, afficher, en un seul mouvement
Au chapitre précédent, nous avons construit la liste des tickets et saisi quelques données de test grâce à un formulaire simple. Dans ce chapitre, nous améliorons l'expérience du formulaire — disposition des champs du bloc de formulaire, ajout d'un bloc de détails, configuration des règles de liaison, et utilisation de l'historique des modifications pour suivre chaque modification d'un ticket.
La fonctionnalité « Historique des modifications » de la section 4.4 est incluse dans la version Pro. Sauter cette section n'affecte pas la suite du tutoriel.
4.1 Améliorer le formulaire de création de ticket
Au chapitre précédent, nous avons rapidement créé un formulaire fonctionnel. Améliorons-le maintenant — ordre des champs, valeurs par défaut, mise en page. Si vous avez sauté la partie formulaire rapide du chapitre précédent, ce n'est pas grave : nous repartons ici depuis le début.
Ajouter le bouton d'action « Add new »
- Assurez-vous d'être en mode UI Editor (interrupteur en haut à droite activé).
- Sur la page « Liste des tickets », cliquez sur « Actions » au-dessus du bloc de tableau.
- Cochez le bouton « Add new ».
- Un bouton « Add new » apparaît au-dessus du tableau ; au clic, une pop-up s'ouvre.

Configurer le formulaire de la pop-up
-
Cliquez sur « Add new » pour ouvrir la pop-up.
-
Dans la pop-up, cliquez sur « Add block → Data block → Form (Add New) ».
-
Choisissez « Current collection ». La pop-up est déjà liée à la table correspondante via le contexte, inutile de la spécifier manuellement.

-
Dans le formulaire, cliquez sur « Fields » et cochez les champs suivants :

Vous remarquerez que le champ « Titre » est automatiquement marqué d'un astérisque rouge * — parce qu'il a été défini comme obligatoire au chapitre 2. Le formulaire hérite automatiquement des règles obligatoires définies au niveau de la table, sans configuration supplémentaire.

Astuce : si un champ n'est pas obligatoire au niveau de la table mais que vous voulez le rendre obligatoire dans ce formulaire, vous pouvez le configurer individuellement dans les paramètres du champ.

Ajouter le bouton « Submit »
- Sous le bloc de formulaire, cliquez sur « Actions ».
- Cochez le bouton « Submit ».

- Une fois le formulaire rempli, l'utilisateur clique sur Submit pour créer un nouveau ticket.

4.2 Linkage rules : valeurs par défaut et liaison de champs
Certains champs doivent être pré-remplis (statut « En attente »), d'autres doivent évoluer dynamiquement selon les conditions (description obligatoire pour un ticket urgent). La fonctionnalité de valeur par défaut de la 2.0 est encore en évolution ; ce tutoriel utilise systématiquement les linkage rules pour configurer valeurs par défaut et liaisons de champs.
- Cliquez sur les paramètres du block (icône à trois traits) en haut à droite du bloc de formulaire.
- Trouvez « Linkage rules » et cliquez : un panneau de configuration s'ouvre dans la barre latérale.

Définir les valeurs par défaut
Définissons d'abord les valeurs par défaut de « Statut » et « Demandeur » :
- Cliquez sur « Add linkage rule ».
- Ne mettez pas de condition (laissez vide) — une linkage rule sans condition s'exécute immédiatement au chargement du formulaire.

- Configurez les actions :
- Champ Statut → Set default value → En attente
- Champ Demandeur → Set default value → Current user
Attention au choix de la valeur : sélectionnez d'abord « Current form » comme source. Pour les champs relationnels (catégorie, demandeur, assigné, etc., champs many-to-one), choisissez la propriété de l'objet elle-même, et non un sous-champ développé.
Pour choisir une variable (par ex. « Current user »), il faut un clic pour sélectionner la variable, puis un double-clic pour la placer dans le champ de saisie.



Si vous voulez qu'un champ ne puisse pas être modifié par le demandeur (par exemple le statut), passez « Display mode » sur « Readonly » dans la configuration du champ.

Trois modes d'affichage : Editable, Readonly (édition désactivée mais apparence du champ conservée), Easy-reading (affichage en texte uniquement).

Description obligatoire pour les tickets urgents
Ajoutons maintenant une linkage rule conditionnelle : quand la priorité est « Urgente », la description devient obligatoire pour rappeler au demandeur de bien décrire la situation.
- Cliquez sur « Add linkage rule ».

- Configurez la règle :
- Condition : Current form / Priorité égal à Urgente
- Actions : Champ Description → Required


- Enregistrez la règle.
Testons : choisissez la priorité « Urgente », un astérisque rouge * apparaît à côté de la description (obligatoire). Pour les autres priorités, le champ redevient facultatif.

Pour finir, ajustez un peu la mise en page selon ce que nous avons appris :

Que peut-on faire d'autre avec les linkage rules ? En plus des valeurs par défaut et de la contrainte d'obligation, vous pouvez contrôler l'affichage / le masquage des champs et faire des affectations dynamiques. Par exemple : masquer le champ « Assigné » quand le statut est « Closed ». Nous verrons d'autres cas plus loin.
4.3 Bloc de détails
Au chapitre précédent, nous avons ajouté un bouton « View » sur chaque ligne, qui ouvre un drawer. Configurons maintenant son contenu.
- Sur une ligne, cliquez sur « View » pour ouvrir le drawer.
- Dans le drawer, cliquez sur « Add block → Data block → Details ».
- Choisissez « Current collection ».

- Dans le bloc de détails, « Fields », mise en page proposée :
Comment placer un grand titre ?
Choisissez Fields > markdown > éditer le markdown > dans la zone d'édition, choisissez la variable > Current record > Titre
Le titre de l'enregistrement est ainsi inséré dynamiquement dans le bloc markdown.
Supprimez le texte par défaut et utilisez la syntaxe markdown pour transformer le contenu en titre de niveau 2 (préfixe ## + espace).


Le champ titre original peut être retiré ; ajustez la mise en page du formulaire de détails.

Astuce : plusieurs champs peuvent être disposés sur la même ligne par glisser-déposer pour une mise en page plus compacte.
- Dans « Actions » du bloc de détails, cochez « Edit », pour pouvoir basculer en édition directement depuis les détails.

Configurer le formulaire d'édition
Au clic sur « Edit », une nouvelle pop-up s'ouvre — où il faut placer un formulaire d'édition. Les champs sont presque identiques à ceux du formulaire de création ; faut-il tout reconfigurer ?
Non. Souvenez-vous du formulaire de création — sauvegardons-le comme template, le formulaire d'édition pourra le référencer.
Étape 1 : revenir au formulaire de création et enregistrer comme template
- Fermez la pop-up actuelle, retournez à la liste des tickets, cliquez sur « Add new » pour ouvrir le formulaire de création.
- Dans les paramètres du block (icône à trois traits) du bloc de formulaire, trouvez « Save as template ».

- Cliquez pour enregistrer ; le mode par défaut est « Reference » — tous les formulaires qui référencent ce template partagent la même configuration ; modifier l'un les modifie tous.


Notre formulaire de tickets reste simple ; le mode « Reference » centralise la maintenance. Avec « Duplicate », chaque formulaire reçoit une copie indépendante, modifiable séparément.
Étape 2 : référencer le template dans la pop-up d'édition
- Retournez au drawer de détails ou à la colonne d'actions du tableau, cliquez sur « Edit » pour ouvrir la pop-up d'édition.
Vous pourriez vous dire : il suffit d'utiliser « Add block → Other blocks → Block template » ? Si vous essayez, vous verrez que cela crée un formulaire d'ajout et que les champs ne sont pas pré-remplis. C'est un piège classique.

La bonne méthode est :
- Dans la pop-up, cliquez sur « Add block → Data block → Form (Edit) » pour créer normalement un bloc de formulaire d'édition.
- Dans le formulaire d'édition, cliquez sur « Fields → Field templates », choisissez le template enregistré.
- Tous les champs sont remplis en un clic, identiques à ceux du formulaire de création.
- N'oubliez pas d'ajouter le bouton « Submit » pour permettre d'enregistrer les modifications.


À l'avenir, pour ajouter un champ : modifiez une seule fois le template, les formulaires de création et d'édition se mettent à jour ensemble.
Quick editing : modifier les données sans ouvrir de pop-up
Outre l'édition par pop-up, NocoBase prend en charge la quick editing dans le tableau — pas de pop-up à ouvrir, il suffit de survoler la cellule pour la modifier.
L'activation se fait à deux endroits :
- Au niveau du bloc de tableau : cliquez sur les paramètres du block (icône à trois traits), trouvez « Quick editing » ; une fois activée, tous les champs du tableau prennent en charge la quick editing.
- Au niveau d'un champ : cliquez sur la configuration d'une colonne, trouvez « Quick editing », pour activer ou non champ par champ.

Une fois activé, en survolant une cellule, une petite icône crayon apparaît ; un clic ouvre l'éditeur du champ, et la modification est enregistrée automatiquement.

Pour quels scénarios ? La quick editing est très adaptée aux modifications massives de statut, d'assigné, etc. Par exemple, en parcourant la liste des tickets, un administrateur peut directement passer un ticket de « En attente » à « En cours » en cliquant sur la colonne « Statut », sans ouvrir de pop-up un par un.
4.4 Activer l'historique des modifications
« Record History » est un plugin de la version Pro de NocoBase et nécessite une licence commerciale. Si vous utilisez la version communautaire, vous pouvez sauter cette section sans incidence sur la suite.
Pour un système de tickets, le point essentiel est le suivant : qui a changé quoi à quel moment doit être traçable. Le plugin « Record History » de NocoBase enregistre automatiquement chaque modification.
Configurer l'historique des modifications
- Allez dans Settings → Plugin manager, vérifiez que le plugin « Record History » est activé.

- Sur la page de configuration du plugin, cliquez sur « Add collection », choisissez « Tickets ».
- Sélectionnez les champs à suivre : Titre, Statut, Priorité, Assigné, Description, etc.

Conseil : il n'est pas nécessaire de tout suivre. Les champs comme ID ou date de création, qui ne sont pas modifiés manuellement, n'ont pas besoin d'être suivis. Ne suivez que les champs métiers significatifs.
- Revenez à la configuration et cliquez sur « Synchronize history snapshots » : le plugin crée automatiquement la première entrée d'historique pour chaque ticket existant ; chaque modification ultérieure ajoute une entrée.


Consulter l'historique sur la page de détails
- Retournez sur le drawer de détails du ticket (cliquez sur « View » sur une ligne).
- Dans le drawer, cliquez sur « Add block → Record History ».
- Choisissez « Current collection » et data « Current record ».
- Une chronologie apparaît en bas du drawer, montrant clairement chaque modification : qui, quand, quel champ, valeur avant / après.


Ainsi, même si plusieurs personnes traitent un ticket, toutes les modifications sont parfaitement traçables.
Récapitulatif
Dans ce chapitre, nous avons couvert tout le cycle de vie de la donnée :
- Formulaire — l'utilisateur peut soumettre un nouveau ticket, avec valeurs par défaut et validations
- Linkage rules — un ticket urgent oblige à remplir la description
- Bloc de détails — afficher clairement l'enregistrement complet
- Record History — suivi automatique de chaque modification, audit serein (plugin commercial, optionnel)
De « voir » à « saisir », puis à « retrouver » — notre système de tickets est désormais utilisable.
Ressources associées
- Bloc de formulaire — configuration détaillée
- Bloc de détails — configuration du bloc de détails
- Linkage rules — règles de liaison de champs

