Aller au contenu
Kewos

Les options du modèle

Un modèle se déclare avec ses champs, et le reste est une liste d’options. Le parcours en montre l’essentiel au fil des étapes. Huit ne sont nommées nulle part, alors qu’elles changent la visibilité, la navigation ou l’écran.

read_open : la donnée de référence

Un produit, un partenaire, une unité, une devise sont lus par des rôles de tous les modules. Lister chaque rôle dans le droit de lecture est intenable et se casse dès qu’un module arrive (interdiction n°8).

registry.register_model("library_title", module="library", read_open=True, fields=[...])

Exécuté avec un utilisateur qui n’appartient à aucun groupe :

sans read_open :                      avec read_open=True :
  GET /library_title    -> 200 []       GET /library_title    -> 200 [Dune, ...]
  GET /library_title/1  -> 404          GET /library_title/1  -> 200
  POST /library_title   -> 403          POST /library_title   -> 403

Deux choses à retenir de ce tableau :

  • l’écriture ne bouge pas. read_open ouvre la lecture, rien d’autre : créer reste refusé par le droit du modèle ;
  • sans le droit de lire, une liste répond 200 et vide, pas 403. Une fiche précise répond 404, pas 403. Le noyau filtre au lieu de refuser, et ne dit jamais qu’un enregistrement existe à quelqu’un qui n’a pas le droit de le voir. Un module qui attendrait un 403 sur la liste attend la mauvaise chose.

14 modules du produit utilisent cette option.

menu_groups : lisible sans être dans le menu

Par défaut, tout groupe qui peut lire un modèle le voit apparaître dans la navigation. Ce n’est pas toujours souhaitable : un modèle technique doit rester lisible (sinon les listes déroulantes qui pointent vers lui se cassent) sans encombrer le menu de tout le monde.

registry.register_model("library_shelfmark", module="library", menu_groups=("library_librarian",), ...)

La navigation ne le montre qu’aux bibliothécaires ; les droits, eux, ne changent pas. C’est du rangement d’écran, jamais de la sécurité. 12 modules s’en servent.

ui_managed : des fiches qu’on ne crée pas à la main

Certains enregistrements naissent d’un flux contrôlé (l’effet d’une transition d’état, une écriture générée) et jamais d’un bouton « Nouveau ». Avec ui_managed=True, l’interface n’affiche plus les boutons créer / modifier / supprimer, la liste reste visible comme historique, et les droits réels ne changent pas : les écritures du serveur passent toujours.

settings : une configuration, pas des données

Un modèle marqué settings=True est rangé par le frontend dans Réglages au lieu de la navigation métier du module. Purement navigationnel : ni les droits, ni les règles, ni le stockage ne bougent.

create_route : votre propre écran de création

create_route="/forms/new/edit"

Le « Nouveau » générique ne s’ouvre plus : il redirige vers votre écran. Un formulaire construit par assemblage n’a rien à faire dans un formulaire générique à champs. Le reste (droits, API) est inchangé : c’est une option de découverte, pas une porte dérobée.

image_field et image_fallback : la vignette

image_field désigne le champ fichier qui sert de vignette, et c’est ce qui fait apparaître la vue galerie sans aucune configuration. image_fallback prend le relais quand la fiche n’a pas d’image à elle :

image_field="photo", image_fallback=("user_id", "avatar_file")

Un employé sans photo affiche l’avatar de son utilisateur. Une relation, un champ, et aucun if dans l’interface.

path_field : les arborescences

Déclare quel champ stocke le chemin de la chaîne parent, et comment le construire. La session le recalcule pour une fiche déplacée et tous ses descendants, donc il ne dérive jamais. Rendu en lecture seule dans les vues : ce n’est pas une donnée qu’on saisit.

per_website : plusieurs vitrines dans un tenant

Ajoute une colonne website_id et cloisonne les enregistrements par site public. Aucun module métier ne l’utilise aujourd’hui : c’est une option du noyau pour les vitrines multiples, citée ici pour qu’elle cesse d’être invisible.