0.Que devions-nous faire pour commencer notre projet ?
0.Faire fonctionner Odoo via Docker :
0.Installer et lancer Docker
0.Via une fenêtre de terminal, entrer les commandes suivantes :
0.docker run -d -e POSTGRES_USER=odoo -e POSTGRES_PASSWORD=odoo -e POSTGRES_DB=postgres -p 5436:5432 --name dbProjet postgres:13
⁃Cette commande utilise Docker pour créer et exécuter un conteneur pour une DB
⁃‘-d’ indique que le conteneur doit se détacher du terminal exécutant la commande
⁃ '-e' est utilisé pour passer des variables d'environnement à un conteneur
⁃POSTGRES_USER=odoo définit le nom d’utilisateur à ‘Odoo’ via la variable d’environnement POSTGRES_USER. L’utilisateur se connectant à la DB utilisera ‘odoo’ pour se connecter à la DB
⁃POSTGRES_PASSWORD=odoo pareil que pour POSTGRES_USER mais au niveau du mdp
⁃POSTGRES_DB=postgres est utilisée pour définir le nom de la base de données à laquelle se connecter une fois connecté à l'instance PostgreSQL. Lorsque l'utilisateur se connectera à l'instance PostgreSQL en utilisant les identifiants définis dans les variables d'environnements, il sera connecté automatiquement à la DB nommée ‘postgres’
⁃-p est utilisé pour utiliser les ports d'un conteneur. Il permet de rediriger les requêtes entrantes sur un port spécifique de l'hôte vers un port spécifique dans le conteneur. Dans cette commande, le port 5436 sur l'hôte est lié au port 5432 dans le conteneur. Cela signifie que toutes les requêtes entrantes sur le port 5436 de l'hôte seront transmises au port 5432 dans le conteneur. Cela permet de se connecter à la base de données PostgreSQL nommée ‘postgres’ plus tard.
⁃--name dbProjet permet de nommer le conteneur
⁃postgres:13 indique l'image à utiliser pour créer le conteneur. "postgres" est le nom de l'image et "13" identifie la version à utiliser de cette image. L'image "postgres:13" est l’image officielle de PostgreSQL version 13. En utilisant cette image, la commande va télécharger l'image depuis le dépôt Docker Hub si elle n'est pas déjà présente sur l'hôte, puis créer un conteneur à partir de cette image pour exécuter une instance de PostgreSQL version 13.
⁃Maintenant, en ouvrant Docker, l’image existe et est lançable
0.docker run -v /Users/leopoldmols/Desktop/ESI/3emeB/Q1/ERPG5/Projet/code:/mnt/extra-addons -p 8069:8069 --platform linux/x86_64 --name odooProjet --link dbProjet:db -t odoo:14
⁃Cette commande utilise Docker pour exécuter un conteneur pour une instance d'Odoo version 14.
⁃-v permet de monter un volume de données de l'hôte vers le conteneur
⁃Le chemin ‘/Users/leopoldmols/Desktop/ESI/3emeB/Q1/ERPG5/Projet/code’ sera monté sous ‘/mnt/extra-addons’, ce qui permet d'accéder aux fichiers dans ce répertoire depuis le conteneur.
⁃-p utilise le port 8069 du conteneur sur le port 8069 de l'hôte, ce qui permet de se connecter à l'instance d'Odoo via un navigateur en utilisant l'URL http://localhost:8069
⁃--platform indique que le conteneur doit être exécuté sur une plateforme linux/x86_64, selon mon architecture d’ordinateur, donc.
⁃--name donne un nom au conteneur "odooProjet"
⁃--link permet de lier le conteneur nommé ‘odooProjet’ à un autre conteneur qui est déjà en cours d'exécution : ‘dbProjet’, d’où le fait de lancer le conteneur de la DB avant de lancer le conteneur d’Odoo.
⁃-t permet de lancer le conteneur en mode terminal pour pouvoir, par exemple, voir les logs.
⁃odoo:14 indique l'image à utiliser pour créer le conteneur. Ici c'est une image officielle d'Odoo version 14. En utilisant cette image, la commande va télécharger l'image depuis le dépôt Docker Hub si elle n'est pas déjà présente sur l'hôte, puis créer un conteneur à partir de cette image pour exécuter une instance d'Odoo version 14.
0.Constater, dans Docker, la présence de 2 images qui permettront de lancer Odoo et qu’Odoo aille chercher ses informations dans une DB nommée par l’autre conteneur.
0.Créer un projet exécutable dans Odoo :
0.docker exec -ti odoo odoo scaffold realtor /mnt/extra-addons
⁃docker exec exécute une commande à l'intérieur d'un conteneur déjà en cours d'exécution : odooProject
⁃la commande passée à docker exec est ‘odoo scaffold realtor /mnt/extra-addons’
⁃Cette commande va créer un squelette (structure de répertoires et des fichiers de base) pour un nouveau module Odoo (qui peut ensuite être personnalisé pour ajouter les fonctionnalités) avec le nom spécifié ‘realtor’ dans le répertoire /mnt/extra-addons qui est le répertoire qui a été monté dans le conteneur lors de la commande précédente, soit ‘/Users/leopoldmols/Desktop/ESI/3emeB/Q1/ERPG5/Projet/code’.
⁃-ti permet de lancer la commande en mode interactif et TTY (internet : ‘Le mode interactif et TTY permettent d'interagir directement avec la console d'un conteneur en cours d'exécution. Le mode interactif permet à l'utilisateur de saisir des commandes et de recevoir des résultats en temps réel, tandis que le mode TTY (terminal virtuel) permet à l'utilisateur de saisir des commandes en utilisant un terminal comme s'il était connecté directement à un système d'exploitation. Le mode TTY gère les entrées et les sorties standard et les erreurs pour un processus, ce qui permet de conserver le formatage de sortie et de saisie, et de gérer les opérations comme le défilement ou la saisie au clavier. Lorsque l'on utilise les options -ti ensemble, cela permet de lancer le conteneur en mode interactif et TTY, cela permet de saisir des commandes et de les exécuter directement dans le conteneur.’).
0.Visiter l’adresse ‘http://127.0.0.1:8069/' pour constater que le projet fonctionne correctement via une DB. Il est déjà possible d’installer le module ‘realtor’ en se rendant dans ‘Applications’, puis, en le recherchant.
0.Dès ce stade atteint, nous avons pu commencer notre projet.
0.Comment aborder notre projet ?
0.Savoir supposer l’origine d’une erreur : corriger notre code, oui, mais :
⁃Si une modification des seeder (demo.xml) ne s’applique pas, il faut réinstaller le module et surtout la DB via les commandes vues plus haut car le demo.xml doit être relu.
⁃Si une modification de la vue ne s’applique pas, il suffit de désinstaller et réinstaller le module sur l’interface web
⁃Si un ajout d’une donnée depuis notre business object n’est pas appliqué, alors, il faut simplement corriger notre code et recharger la page
0.Ajouter une vue ou un menu ? Ajouter le chemin relatif de la vue dans le fichier __manifest__.py
0.Ajouter un modèle ? Ajouter l’import correspondant dans le fichier model/__init__.py
0.Changer les permissions ? Gérer le fichier security/ir.model.access.csv
⁃id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink : c’est une entrée dans le fichier CSV qui définit les droits d'accès pour un modèle spécifique pour un groupe d'utilisateurs spécifique pour un module Odoo
⁃access_realtor_realtor,realtor.realtor,model_realtor_apartment,base.group_user,1,1,1,1
⁃le nom de l'entrée est "access_realtor_realtor" et le modèle visé est « realtor.realtor »
⁃Le groupe visé est "base.group_user"
⁃Les champs perm_read, perm_write, perm_create, et perm_unlink indiquent si le groupe a respectivement les droits de lecture, écriture, création et suppression sur ce modèle. Dans ce cas, le groupe "base.group_user" a tous les droits sur le modèle "realtor.apartment"
⁃Ces droits sont définis par la valeur 1. Si c’était la valeur 0, alors, les droits ne seraient pas alloués.
0.Les fonctionnalités seront reprises avec les exemples de codes pour éviter de réexpliquer le code.
0.Le projet
0.Le business object : FAIRE UNE DEMO D’UN ENREGISTREMENT D’UN APPARTEMENT
⁃class Apartment(models.Model): hérite de la classe "models.Model"
⁃_name = 'realtor.apartment'
⁃nom technique du modèle, ce qui permet de le référencer dans d’autre classes
⁃_description = "Modèle d'un appartement"
⁃fournir une description lisible du modèle et de son but par les humains
⁃name = fields.Char(string="Nom de l'appartement", required=True)
⁃champs de char utilisé pour stocker le nom de l'appartement
⁃Nécessaire d’être rempli avant de sauvegarder l’appart grâce à ‘required=True’
⁃description = fields.Char(string="Description de l'apartment")
⁃pareil mais pas nécessaire grâce à l’absence d’un ‘r’equired
⁃image = fields.Binary(string='Image')
⁃pour stocker l’image d’un appartement
⁃fields.Binary() est utilisée pour créer un champ binaire dans Odoo : pour stocker des images, des fichiers audio ou vidéo, ou tout autre type de fichier
⁃‘string’ est utilisé pour définir l'étiquette du champ qui sera affichée dans l'interface utilisateur
⁃expected_price = fields.Integer(string="Prix attendu", required=True)
⁃fields.Integer() est utilisée pour créer un champ entier dans Odoo pour stocker des nombres entiers uniquement
⁃apartment_area = fields.Integer(string="Surface de l'appartement", required=True)
⁃terrace_area = fields.Integer(string="Surface de la terrasse", required=True)
⁃total_area = fields.Integer(string="Surface totale", compute='_compute_total_area')
⁃best_offer_price = fields.Integer(string="Meilleure offre", compute='_compute_min_price', readonly=False)
⁃disponibility = fields.Boolean(string="Disponible ?", default=False)
⁃fields.Boolean() est utilisée pour créer un champ booléen dans Odoo.
⁃'default' est utilisé pour spécifier une valeur par défaut (False) pour ce champ.
⁃date_creation = fields.Date(string="Date de création de l'appartement", default=datetime.today(), readonly=True)
⁃fields.Date() est utilisée pour créer un champ de date dans Odoo
⁃date_disponibility = fields.Date(string="Date de disponibilité de l'appartement", default=datetime.today() + relativedelta(months=3))
⁃
⁃# Supplier ne devrait pas être dans la vue apartment car il peut être précisé lors de la livraison pour savoir qui est la personne qui livre (ici, ce sera 'Immobilier ESI')
⁃# Le chemin pour faire une livraison est Inventaire -> Opérations -> Transferts -> Créer -> Sélectionner Immmobilier ESI comme contact -> Sélectionner le produit -> Sélectionner la quantité -> Choisir le type d'opération -> Marquer à faire -> Valider, malgré le petit warning
⁃supplier = fields.Many2one('res.partner', string="Fournisseur") #, default=lambda self : self.env['res.partner'].search([('name', '=', 'Immobilier ESI')], limit=1)) # Limit=1 car il faut ne chercher qu'un seul fournisseur
⁃fields.Many2one() est utilisée pour créer un champ de relation de type many-to-one dans Odoo
⁃supplier’ est lié au modèle ‘res.partner’ d’Odoo
⁃buyer = fields.Char(string="Acheteur potentiel")
⁃# Les 2 fields suivants permettent, avec les fonctions 'compute_for_only_one_apartment' et 'asset_inverse_for_one_product' d'empêcher qu'un product soit associé à plusieurs apartment et inversement
⁃Ses fonctions associées :
⁃@api.constrains('date_creation', 'date_disponibility')
⁃def _check_dates(self):
⁃validation de contrainte pour le modèle Apartment
⁃déclenchée lorsque les valeurs de date_creation et date_disponibility sont modifiées
⁃@api.constrains('date_creation', 'date_disponibility') permet de déclencher la fonction lorsque les valeurs de ces champs sont modifiées.
⁃@api.constrains('expected_price')
⁃def _check_expected_price(self):
⁃Check que le prix n’est pas plus petit que 1
⁃@api.constrains('apartment_area')
⁃def _check_apartment_area(self):
⁃Pareil pour la surface de l’appart
⁃@api.constrains('terrace_area')
⁃def _check_terrace_area(self):
⁃Pareil pour la surface de la terrasse
⁃@api.constrains('total_area')
⁃@api.depends('apartment_area', 'terrace_area')
⁃def _check_total_area(self):
⁃Check que la surface totale doit être la somme des 2 autres surfaces
⁃@api.constrains('total_area') permet de déclencher la fonction lorsque la valeur de ce champ est modifiée
⁃@api.depends('apartment_area', 'terrace_area') indique que cette fonction dépend des valeurs de ces deux champs, cela permet de mettre à jour automatiquement la valeur de total_area en fonction des changements de ces deux champs.
⁃@api.depends('apartment_area', 'terrace_area')
⁃def _compute_total_area(self):
⁃Calcule la surface totale en faisant la somme des 2 autres surfaces
⁃@api.depends('expected_price', 'best_offer_price')
⁃def _compute_min_price(self):
⁃Check que le prix minimum est bien de minimum 90% du prix attendu
⁃@api.constrains('disponibility')
⁃def _check_disponibility(self):
⁃Check que la disponibilité de l’appart es bien de 3 mois après sa date de création
2.Les vues
1.apartment_view
⁃Expliquer ‘model="ir.ui.view"’, '<field name="model »’, ‘tree’ et ‘form’
⁃L.51 : <!— This is not really a form. It just shows the different apartment that a Team is responsible for -->
⁃Ce commentaire est faux. Cette balise gère le formulaire et son affichage en groupes
2.apartment_menu
⁃<record model="ir.actions.act_window" id="apartment_list_items">
⁃ <field name="name">Appartements</field>
⁃ <field name="res_model">realtor.apartment</field>
⁃ <field name="view_mode">tree,form</field>
⁃</record>
⁃ir.actions.act_window : action héritée d’Odoo
⁃res_model : modèle vers où rediriger une fois le menu item cliqué
3.product_view
⁃<!-- Permet d'ajouter un champs à la vue d'Odoo -->
⁃<xpath expr="//field[@name='categ_id']" position="after">
⁃ <field name="apartment_id" />
⁃</xpath>
⁃Attribut ‘expr' est utilisé pour spécifier l'emplacement du champ existant (categ_id)
⁃tag "field" est utilisé pour définir les propriétés du nouveau champ
⁃Attribut "name" est utilisé pour donner un nom au nouveau champ (apartment_id)
4.stock_view
⁃Rien de bien spécial à expliquer après mes explications