Laissez Odoo attribuer chaque nouvelle note

1. Ajoutez seulement le propriétaire

Votre modèle du Jour 2 fonctionne déjà. Conservez ce que vous avez écrit et ajoutez seulement user_id après category_id. Si votre fichier n'a pas changé depuis le Jour 2, vous pouvez aussi le remplacer par cette version complète.

from odoo import fields, models


class TrainingNote(models.Model):
    _name = "training.note"
    _description = "note de notre formation"
    _order = "id asc"

    _rec_name = "title"

    title = fields.Char(string="Titre par défaut", required=True)
    body = fields.Text(string="Contenu par défaut")
    category_id = fields.Many2one("training.note.category", string="Catégorie", ondelete="set null")

    user_id = fields.Many2one(
        "res.users",
        string="Propriétaire",
        required=True,
        default=lambda self: self.env.user,
    )

2. Repérez ce qui change par rapport au Jour 2

• user_id est le seul nouveau champ. C'est une relation Many2one vers res.users, le modèle des utilisateurs Odoo.
• string="Propriétaire" est le libellé qui sera affiché plus tard dans les views.
• required=True empêche une note sans propriétaire.
• default=lambda self: self.env.user utilise l'utilisateur courant lorsque le code de création ne fournit pas de propriétaire.
• Il n'y a ni import api, ni @api.model, ni méthode create() ou write() dans cette version.

lambda self: self.env.user est une petite fonction anonyme Python : Odoo l'appelle au moment de créer une note. Elle est proche d'une fonction fléchée JavaScript par sa forme courte, mais ce n'est pas la même syntaxe.

3. Comprenez l'identité portée par env.user

Chaque appel à l'ORM garde notamment la base utilisée et l'utilisateur authentifié. self.env.user est cet utilisateur Odoo ; self.env.user.id est son identifiant.

Une clé d'API identifie un utilisateur pour cet appel. Elle n'ajoute aucun droit et ne contourne aucune règle sur les enregistrements. La route du Jour 4 utilise l'environnement normal de request.env["training.note"], sans élévation de privilèges.

4. Créez sans envoyer de propriétaire

Les formulaires, le composant Owl et le POST présentés dans ce parcours n'envoient pas user_id. Lorsqu'ils créent une note, Odoo utilise donc le défaut et place l'utilisateur de la session ou de la clé API dans le champ.

Le POST du Jour 4 accepte uniquement title et body. Une fois la clé authentifiée, l'appel crée une note sans user_id : la valeur par défaut est donc l'utilisateur de cette clé.

{
  "title": "Contrôle depuis l'API",
  "body": "Odoo connaît déjà l'utilisateur de la clé."
}

5. Redémarrez Odoo et mettez le module à niveau

1. Action qui redémarre Odoo : redémarrez le processus local, puis attendez que les journaux indiquent que le serveur est prêt. Le redémarrage charge la modification Python.
2. Action qui modifie la base d'exercice : dans Applications, ouvrez Hello Odoo et choisissez Mettre à niveau. Cette mise à niveau ajoute la colonne user_id et sa contrainte à la table training_note.

Résultat attendu : le redémarrage et la mise à niveau se terminent sans erreur. Actualiser seulement le navigateur ne suffit pas : vous avez changé du code Python et la structure de la base.

6. Préparez le test à deux utilisateurs

Créez maintenant une nouvelle note dans Odoo, avec le titre Contrôle du propriétaire. À ce stade, la fiche ne montre pas encore le propriétaire : vous l'ajouterez aux vues dans la section 3.

Ne cherchez pas cette valeur dans PostgreSQL. Le test utile arrive dans la section suivante : Alex et Sam créeront chacun une note, puis vous constaterez que chaque note appartient au compte qui l'a créée. C'est cette comparaison qui vérifiera le comportement du modèle dans une vraie session Odoo.