1. Le module

Un module Kewos déclare. Il ne construit pas d’écran, ne dessine pas de formulaire, n’écrit pas de SQL.

Déclarer un modèle donne, sans une ligne de plus : la table, l’API, les écrans, la recherche, l’audit, les permissions, la traduction et l’export. L’administration découvre tout auprès du serveur, donc ajouter un module ne demande jamais de redéployer l’interface.

Le squelette

Un module est un dossier sous modules/. Le nôtre s’appelle library.

modules/library/
├── manifest.json                ← identité et dépendances
├── __init__.py                  ← le point d'entrée que le noyau appelle
├── icon.svg                     ← l'icône dans le lanceur
├── acl.json                     ← les permissions
├── models/
│   ├── __init__.py
│   ├── title.py                 ← l'œuvre
│   ├── copy.py                  ← l'exemplaire physique
│   ├── member.py                ← l'adhérent
│   ├── loan.py                  ← l'emprunt
│   └── workflow.py              ← le cycle de vie de l'emprunt
├── views/                       ← quatorze écrans, en JSON
└── i18n/
    ├── en.json
    └── fr.json

Les fichiers apparaissent au fil des étapes. Créez pour l’instant le dossier, le manifeste et le point d’entrée.

Le manifeste

{
  "name": "library",
  "depends": ["core"],
  "summary": "Library management: catalogue, copies, members and loans.",
  "version": "0.1.0",
  "category": "operations"
}

Clé	Rôle
name	Le nom technique. Il préfixe toutes vos tables.
depends	Les modules dont le vôtre a besoin. core au minimum.
version	Une version sémantique. Elle sert aux mises à jour et aux migrations.
category	Le rayon du lanceur : sales, assets, operations, hr, finance…
summary	Une phrase, affichée dans la liste des modules.

Le nom des tables n’est pas libre

Le préfixe d’une table est le nom du module : library_title, library_loan. Jamais un nom repris d’un autre progiciel, jamais res_* ni ir_*.

Ce n’est pas une préférence esthétique. Un nom emprunté à un concurrent crée une fausse familiarité : on suppose que le champ se comporte comme là-bas, et il ne le fait pas.

Le point d’entrée

__init__.py, à la racine du module, expose la fonction que le noyau appelle au démarrage.

"""``library`` -- catalogue, copies, members and loans."""

from __future__ import annotations

from pathlib import Path
from typing import TYPE_CHECKING

from kewos.orm import apply_module_acls
from kewos.views import register_views_from_dir

from . import models

if TYPE_CHECKING:
    from kewos.orm.registry import Registry

_MODULE_DIR = Path(__file__).parent


def register(registry: Registry) -> None:
    """Declare the module: models, then permissions, then screens."""
    models.register_models(registry)
    apply_module_acls(registry, _MODULE_DIR / "acl.json")
    register_views_from_dir(_MODULE_DIR / "views")

Trois lignes, dans cet ordre : ce qui existe, qui y a droit, comment ça se montre. C’est l’ordre de lecture d’un module Kewos, et il ne change jamais.

Un module n’importe jamais un autre module

from modules.sales import ... est interdit. Deux modules se parlent par événements et par registres, jamais par import direct.

C’est ce qui permet de retirer un module sans casser les autres, et de livrer un module à un client qui n’a pas les mêmes que vous.

Et ensuite

Les données : déclarer les quatre modèles.