Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1

Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1
Réalisé par : Ait-Mlouk Addi
Blog : http://aitmlouk-addi.blogspot.com
Site web : http://www.odoo-services.esy.es/
Laboratoire ETRI
aitmlouk@gmail.com

Plan
Prise en main
Configuration et paramétrage
Modules personnalisé
Introduction
Conclusion
Développement spécifique
Prise en main et paramétrage d’odoo
(OpenERP)

•Prise en main complet d’odoo
•Configuration complète
•Caractéristiques techniques complète
•Savoir crée un module personnalisé
•Savoir développer un module spécifique
2
Prise en main complet d’odoo
Configuration complète
Module personnalisé
Module spécifique
Conclusion
Prise en main et paramétrage d’OpenERP

Configuration OdooPartie 1: Prise en main
Module spécifique
Conclusion

•Démarrer le serveur
•Créer une nouvelle base de données formation, mot de passe admin
•Se connecter à la nouvelle base
de donnée
Module spécifique
Conclusion

•Activer les menus de la configuration avancée :
•Configuration -> Utilisateurs -> Modifier l’utilisateur -> Onglet droits d’accès
•Cocher Caractéristiques techniques
•Administration -> sélectionner l’option Configuration
•Actualiser la page
•Installer des modules
Module spécifique
Conclusion

Module spécifique
Conclusion

Module spécifique
Conclusion
Pour une simple modification au niveau d’un module sous odooon peut passez tous simplement par Des objets et vues personnaliser et en crée les objets comme suite :
•Configuration -> structure de la base de donnée -> Modèle puis crée un objet

Module spécifique
Conclusion
Apres la définition de l’objet il reste a définir les champs comme suite :

Module spécifique
Conclusion
Et les menus comme suite :

Module spécifique
Conclusion
Apres que nous terminons notre module personnalisé on enregistre le module en question et on rafraichir la page pour que les modification soit apparaitre comme suite :

Module spécifique
Conclusion
Le mode développeur
Le mode développeur permet de debugger les modules afin d’identifier les objet , champs, vues, menus … techniquement Il est utiliser par un développeur pour identifier plus de détailles sur les objets … qui servira a paramétrer et a modifier les modules stocker dans la base de donnée et pas dans le code source. Pour activer le mode développeur on procède comme suite :
Administrator-> Aproposde l’OpenERP

Module spécifique
Conclusion
Pour debugger un module ou un objet on passe par le menu Déboguer et en choisie l’action qui convient.

Module spécifique
Conclusion
Développement spécifique d’un module
Les différents phase d’un ERP
UnERPpossèdegénéralementtroisphasesdetravail:

Module spécifique
Conclusion
Architecture modulaire sous odoo(openerp)
•Tous les modules d’OpenERP sont créés au-dessous du répertoire
openerp7/openerp/addons

Module spécifique
Conclusion
Architecture modulaire sous odoo
•Structure standard d’un module sous odoo

Module spécifique
Conclusion
Structure d’un module Odoo
•Les étapes suivantes sont nécessaires pour créer un nouveau module:
•Créer un package python dans le répertoire /addonsportant le nom de votre module (required)
•Créer un fichier de description du module: __openerp__.py (required)
•Créer le fichier Python contenant les modèles (Classes + Méthodes) (required)
•Créer des fichiers .XML pour définir les menus, les vues et les actions (required)
•Créer des fichiers .XML qui téléchargent des données de démonstration
•Créer éventuellement des rapports, des assistants (Wizard) ou des flux de travail (Workflow).

Module spécifique
Conclusion
Obligatoires
__init__.py
InitialisationdupackagePython
__openerp__.py
Lafichedescriptivedumodule
module.py
LesclassesPython,lesobjetsdumodule
module_view.xml
Lesvues(Formulaires,listes,graph,…),menusetactions
Optionnels
demo
Donnéesdetestetdedémonstration
i18n
Fichiersdetraduction–Internationalisation
report
Définitiondesrapports
security
Déclarationdesgroupesetdesdroitsd’accès
workflow
Définitiondesworkflow
wizard
Définitiondesassistants

Module spécifique
Conclusion
__init__.py
•C'est le fichier qui permet a OpenERPde charger notre module. Le contenu de ce fichier est très simple:
importnom_module

Module spécifique
Conclusion
__openerp__.py
•name:le nom de votre module;
•version:la version du module;
•category:la catégorie dans laquelle vous classez votre module;
•sequence:c'est un nombre qui permet de définir l’ordre de votre module dans la liste des modules. 1, il sera en haut, 100 il sera en bas
•author:l'auteur du module;
•description:la description complète du module;
•depends:les dépendances votre module;
•data:les fichiers à charger;
•installable:si votre module est installable ou non;
•application:laissez à False. Votre module ne sera pas reconnu comme une application. C'est OpenERPqui délivre les certificats qui qualifient votre module d'application;
•auto_install:laissez à False, nous l'installerons à la main.

Module spécifique
Conclusion
# -*-coding: utf-8 -*-
{
'name' :"nom de module",
'author' : "auteur",
'version' :"0.1",
'description' :"description…",
'website' :"site web ou blog si il existe …",
'category' :"catégorie de module",
'summary' :"les mots clef de description",
'sequence' : 0,
'depends' : ['base'],
'update_xml' : [
#'travaux_view.xml',
],
'demo_xml' : []
'installable': True,
'application': False,
'auto_install': False,
}
Exemple de fichier de description du module
__openerp__.py (Squelette)

Module spécifique
Conclusion
Exercice 1 :Exemple de création de module
•Créer un module vide formation_travaux
•Créer les fichiers obligatoires __init__.py et __openerp__.py
•Redémarrer le serveur
•Installer le module à partir du menu
•Configuration -> Modules -> Modules installés
•Lancer l’installation du module on cliquant sur installé

Module spécifique
Conclusion
{
'name' :"Formation Gestion des travaux",
'author' : "Ait-Mlouk Addi",
'version' :"0.1",
'description' :"Module de gestiondes travauxsous odoo",
'website' :"www.aitmlouk.esy.es",
'category' :"Maintenance",
'summary' :"Travaux, Taches, Incidents",
'sequence' : 0,
'depends' : ['base'],
'update_xml' : [
#'travaux_view.xml',
],
'demo_xml' : []
'installable': True,
'application': False,
'auto_install': False,
}
Réponse
__openerp__.py

Module spécifique
Conclusion
Les classes
Partie 2
Les classes

Module spécifique
Conclusion
La couche Model
•Le Framework Object Service(OSV) met en oeuvre une couche complète de MappingObjet Relationnel.
•Il permet aux développeurs de mettre en place l’architecture SQL de base.
•Les objets métier sont déclarés comme des classes Python qui héritent de la classe osv.osv, ce qui les rend une partie du modèle OpenObjectmodèle, et qui seront automatiquement persistés par la couche ORM.
Les classes

Module spécifique
Conclusion
Les types des champs de l’ORM
•Un objet peut avoir 3 types de champs
•Simple: Integers, Floats, Date, Booleans, Char, Text, Binary…
•Relationnel: Représente les relations entre les objets (one2many, many2one, many2many)
•Fonctionnel : Des champs stocké ou non-stockés à la base de donnée, il sont calculés à la volé comme des fonctions Python
Les classes

Module spécifique
Conclusion
Champs simple
boolean(...),integer(...),date(...),datetime(...)
time(...),float(…)
Exemple :
'active': fields.boolean('Active'),
'priority': fields.integer('Priority'),
'start_date': fields.date('Start Date'),
char(string,size,translate=False,..) text(string,size,translate=False,..)
• translate: True sile champs peutêtretraduitpar l’utilisateur
• size: la taillemaximum d’un champs caractère(→41,45)
selection(values, string, ...)
‘status' :fields.selection([('open','Open'),('closed','Closed')],'Status',
required=True, translate=True),
binary(string, filters=None, ...)
Un champs pour stocker des fichiers ou des images
• filters: Filtresoptionnelssurle nom du fichier'picture':fields.binary('Picture',filters='*.png,*.gif')
Champs relationnel
many2one(obj, ondelete='set null', …)
Relationversl’objetcourant
• obj: Le nom _namede l’objet destination (requis)
• ondelete: e.g. 'set null', 'cascade', Voir la documentation PostgreSQL
one2many(obj, field_id, …)
L’inverse de many2one
• field_id: field name of inverse many2one
many2many(obj, rel, field1, field2, …)
Relation bidirectionnelmultiple entre deuxclasses
• rel: Le nom SQL de la table associative (requis)
• field1: Le nom du champs de l’objetactueldansla table associative (requis)
• field2: Le nom du champs de l’objetdestination dansla table associative (requis)
Les classes

Module spécifique
Conclusion
La couche Model
L’architecture d’une classe (Model) vide
classclasse_name(osv.osv):
_name= 'object.name'
_description = u"objectdescription"
_columns= {
'field1' : fields.char(u'Numéro', size=32, required=True),
'field2' : fields.many2one('object.name', u'Responsable', required=True),
…
}
_defaults = {
'field': lambda self, cr, uid, context: '/',
}
Classe_name()
fromopenerp.osvimportfields, osv
Les packages et el éléments nécessaires pour créer un model
Les classes

Module spécifique
Conclusion
Exercice 2 : Exemple de création des classes
•Créer un nouveau fichier travaux.py dans le module formation_travaux
•Importer les packages du frameworkosv
•Créer une classe formation_workdans le fichier travaux.py
•Redémarrer le serveur
•Mettre à jour le module à partir du menu
•Configuration -> Modules -> Modules installés
•Lancer la mise à jour du module on cliquant sur Mettre à jour
•Ouvrer le gestionnaire PgAdminet vérifier dans votre base de données si la table formation_worka été bien créée.
Les classes

Module spécifique
Conclusion
Réponse
L’architecture d’une classe (Model) vide
travaux.py
classformation_work(osv.osv):
_name= 'formation.work'
_description = u"Thisis for managing works"
_columns= {
'name' : fields.char(u'Numéro', size=32, required=True),
'responsable': fields.many2one('hr.employee', u'Responsable', required=True),
'user' : fields.many2one('res.users',u'Note', translate=True),
'line_ids': fields.many2one('formation.work.line', u'maintenance', required=True)
}
_defaults = {
'name': lambda self, cr, uid, context: '/',
}
formation_work()
Les packages nécessaires pour créer un model
Les classes

Module spécifique
Conclusion
Exercice 3
•Créer une nouvelle classe formation_work_linedans le fichier travaux.py
•Ajouter des champs relationnelsdans les deux classes (formation_worket formation_work_line) pour représenter la relation suivante,
formation_work
name(char)
responsable (many2one)
user(many2one)
line_ids(many2one)
formation_work_line
name(char)
maintenance (one2many)
description (text)
*
1
many2one
one2many
Les classes

Module spécifique
Conclusion
Réponse 1 :
L’architecture d’une classe formation_work
travaux.py
classformation_work(osv.osv):
_name= 'formation.work'
_description = u"Thisis for managing works"
_columns= {
'name' : fields.char(u'Numéro', size=32, required=True),
'responsable': fields.many2one('hr.employee', u'Responsable', required=True),
'user' : fields.many2one('res.users',u'Note', translate=True),
'line_ids': fields.many2one('formation.work.line', u'maintenance', required=True)
}
_defaults = {
}
formation_work()
Les classes

Module spécifique
Conclusion
Réponse 2 :
L’architecture d’une classe formation_work_line
travaux.py
classformation_work_line(osv.osv):
_name= 'formation.work.line'
_description = u"Thisis for managing works line"
_columns= {
'name' : fields.char(u'Nom', size=32, required=True),
'maintenance' : fields.one2many('formation.work', u'Maintenance', required=True),
'description' : fields.text(u'Description', translate=True),
}
_defaults = {
}
formation_work_line()
Les classes

Module spécifique
Conclusion
vues, actions et Menus
Partie 2
Vues, Actions et Menus

Module spécifique
Conclusion
Structure des modules Odoo
•Structure standard d’un module sous OpenERP

Module spécifique
Conclusion
Les Vues
•Déclaration générique d’une vue :
<record model="ir.ui.view" id="VIEW_ID">
<field name="name">VIEW.NAME</field>
<field name="model">PYTHON.CLASS.NAME</field>
<field name="arch" type="xml">

</field>
</record>
•namenom de la vue (nomination séparée par des point)
•modelmodèle d'objet sur lequel la vue est définie (comme res_modeldans les actions)
•typeform, tree, graph, calendar, search, gantt, kanban
•archarchitecture de la vue

Module spécifique
Conclusion
La vue Formulaire (Form)
•Exemple de la vue formulaire

Module spécifique
Conclusion
•Déclaration XML

<record model="ir.ui.view" id="formation_work_form">
<field name="name">formation.work.form</field>
<field name="model">formation.work</field>
<formstring="Travaux">
<fieldname="name" />
<fieldname="responsable" />
<fieldname="user" />
<fieldname="line_ids" />
</form>
</field>
</record>

Module spécifique
Conclusion
•Déclaration XML ( API Version 7)
<record model="ir.ui.view" id="formation_work_form">
<field name="name">formation.work.form</field>
<formstring="Tables" version="7.0">
<sheet>
<h1>
<label for="name" string="Numéro" />
</h1>
<label for="user" string="Utilisateur" />
<fieldname="description" />
</sheet>
</form>
</field>
</record>

Module spécifique
Conclusion
•Les attributs communs à tous les éléments :
• string: label de l'élément ;
• nolabel: mettre à 1 pour cacher l'étiquette du champ ;
• colspan: nombre de colonnes sur lesquelles le champ doit s'étendre ;
• rowspan: nombre de lignes sur lesquelles le champ doit s'étendre ;
• col: nombre de colonnes que cet élément doit allouer à ses éléments enfants ;
• invisible: mettre à 1 pour cacher cet élément complètement ;

Module spécifique
Conclusion
•Déclaration XML (Sheet, h1+ Group+ Notebook)

Module spécifique
Conclusion
La vue Liste (Tree)
•Exemple de la vue liste (Tree)

Module spécifique
Conclusion
La vue Liste (Tree)
•Déclaration XML

<record model="ir.ui.view" id="formation_work_tree">
<field name="name">formation.work.tree</field>
<treestring="Travaux">
<fieldname="description" />
</tree>
</field>
</record>

Module spécifique
Conclusion
La vue Liste (Tree)
•Déclaration XML

Module spécifique
Conclusion
La vue Kanban (Vignette)
•Cette vue représente les données sous forme de colonnes / petite vignette regroupées par un critère.
•Les vue Kanban sont personnalisable avec des balises HTML ou QWeb
• Qweb: Un langage de Template HTML développé par OpenERPqui permet de définir une structure portable des composantes HTML.

Module spécifique
Conclusion
La vue Kanban (Vignette)
<record model="ir.ui.view" id="formation_work_tree">
<field name="name">formation.work.kanban</field>
<kanban> <templates>
<t t-name="kanban-box">
<div class="oe_module_vignette" style="background:#EEE">
<div class="oe_module_desc">
<h2><a type="edit"><field name="name"/></a></h2>
<ul>
<li><strong><fieldname="description"/></strong></li> </ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>

Module spécifique
Conclusion
La vue Kanban (Colonnes)

Menus et actions
•Les menus principales permette à l’utilisateur d’accéder au module
•Chaque module est dispose d’un menu principale et d’autres sous menus
•Les menus et leurs actions sont déclarés à l’intérieur d’un fichier xml: ( travaux_view.xml)
Module spécifique
Conclusion

Module spécifique
Conclusion
Menus et actions
Menu sans action
Menu 1 avec action
Menu principal
Menu 2 avec action

Module spécifique
Conclusion
•Structure de la vue travaux_view.xmlvide
<?xml version="1.0" encoding="UTF-8"?>
<openerp>
<data>
[views definitions]
[actions definitions]
[menus definitions]
</data>
</openerp>
Actions et menus
Pour les bonnes pratique il est préférer de séparer les menus dans
un fichier xml(menu_views.xml) a fin de facilité la maintenance.

Module spécifique
Conclusion
Actions
•La déclaration XML d’une actionest la suivante
•model: la table (base de données) pour stocker des actions
•id: Identifiantde l’actiondansla table ir.action.act_windows, ildoitêtreunique
•name: Le nom de l’action (requis)
•res_model: Le model (classe python) objet de la vue (requis)
•view_mode: La liste des modes alloués pour visualiser les enregistrements
<record model="ir.actions.act_window" id="work_action_work">
<field name="name">Works</field>
<field name="res_model">formation.work</field>
<field name="view_mode">tree,form</field>
</record>

Module spécifique
Conclusion
Menus
•La déclaration XML d’un menu principal, niveau 1
•La déclaration d’un menu niveau 1.1 (Sans action = non cliquable)
•La déclaration d’un menu niveau 1.1.1 (menu cliquable avec action)
•REMARQUE: Avant d’utiliser les menus cliquables, il faut définir l’action action="[ACTION_ID]" qui va être déclenchée.
<menuitemid="work_menu_root"name="Traveaux" />
<menuitemid="work_menu" parent="work_menu_root" name="Traveaux" />
<menuitemid="works_work_menu" parent="work_menu" name="Traveaux" action="[ACTION_ID]" />

Module spécifique
Conclusion
Exercice 3 (Création des menus)
Travaux
Travaux
Tache
Travauxformation.work.lineformation.work

Module spécifique
Conclusion
Réponse :
<menuitemid="work_menu_root"name="Traveaux" />
<menuitemid="work_menu" parent="work_menu_root" name="Traveaux" />
<menuitemid="works_work_menu" parent="work_menu" name="Traveaux" action="[ACTION_ID]" />
<menuitemid="works_task_menu" parent="work_menu" name="Tache" action="[ACTION_ID_TASK]" />

Module spécifique
Conclusion
Sécurité
Partie 3
Sécurité

Module spécifique
Conclusion
Sécurité
•LesutilisateursetlesrôlessontdespointscritiquesenmatièredesécuritéinternedansOpenERP.
•OpenERPproposeplusieursconceptsdesécuritéconcernantlesrôlesdesutilisateurs:
•Utilisateur:unepersonneidentifiéeparsonloginetmotdepasse.Notezquetouslesemployésd'uneentreprisenesontpasnécessairementlesutilisateursOpenERP,unutilisateurestunepersonnequiaccèdeàl'application.
•Groupe:ungrouped'utilisateursquiadesdroitsd'accès.Ungroupedonnesesdroitsd'accèsàsesutilisateurs.Ex:responsabledesventes,comptable,etc
•Règlesde sécurité: une règle qui définit les droits d'accès d'un groupe donné. Les règles de sécurité sont fixées à une ressource donnée, par exemple le modèle de facturation.
Sécurité

Module spécifique
Conclusion
Groupes
•Lacréationdesgroupespeutsefaired’unemanièregraphique(Configuration-> Utilisateurs->Groupes)ouavecdesfichiersdedonnéesXML
Sécurité
Méthode graphique

Module spécifique
Conclusion
•ExempledefichierXMLdegroups
<?xml version="1.0" encoding="utf-8"?>
<openerp>
<data noupdate="1">
<record id="group_work_manager" model="res.groups">
<field name="name">work/ Manager</field>
<field name="comment">Manager of works</field>
<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
</record>
<record id="group_work_user" model="res.groups">
<field name="name">Restaurant / user</field>
<field name="comment">userofrestaurant</field>
<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
</record>
</data>
</openerp>
Sécurité
Groupes

Module spécifique
Conclusion
Les états de sortie
report
Développement spécifique d’un moduleétats de sortie

Module spécifique
Conclusion
Développement spécifique d’un moduleinternationalisation
•Odoo(Openerp)possèdedeuxtypesderapport:
•Rapportsetstatistiques:cesontdesdonnéescalculées,souventreprésentéssouslaformegraphiques.
•Etatdesortie:ilssontutiliséspourimprimerdesdocumentsdusystème.LerésultatestgénéralementunPDFgénéréparunesélectioneffectuéesurl'écran.Enoutre,OpenERPvouspermetd'ouvrircesrapportsdansOpenOffice.org.
reports

Module spécifique
Conclusion
•Pourlareprésentationdesmenusd’impressionondéfinieunfichierxmlcommesuite:
<?xml version="1.0" encoding="utf-8"?>
<openerp>
<data>
<report auto="False" id="report_formation_travaux" model="formation.work" name="formation.work"
rml="formation_travaux/report/travaux.rml"string="Fiche de Travau"usage="default"/>
<report auto ="False" id="report_formation_travaux" model="formation.work" name="formation.work"
rml="formation_travaux/report/travaux.rml" string="Fiche de Travau"usage="default"/>
<report auto="False" id="report_formation_travaux" model="formation.work" name="formation.work"
rml="formation_travaux/report/travaux.rml" string="Fiche de Travau" usage="default"/>
</data>
</openerp>

Module spécifique
Conclusion
•Leparseur
importtimefromopenerp.reportimportreport_sxw
classmadrassa_travaux(report_sxw.rml_parse):
def__init__(self, cr, uid, name, context=None):
super(madrassa_travaux, self).__init__(cr, uid, name, context=context)
self.line_no= 0
self.localcontext.update({
'time': time,
'line_no':self._line_no,
})
report_sxw.report_sxw('report.formation.work', 'formation.work', 'addons/formation_travaux/report/travaux.rml', parser=madrassa_travaux, header="external")

Module spécifique
Conclusion
Internationalisation
i18n

Module spécifique
Conclusion
Exercice 5 (Internationalisation)
•Exporter la Template de traduction du module formation_travaux
•Configuration -> Importer / Exporter -> Exporter une traduction
•Sélectionner le module formation_travaux
•Cliquer sur Exporter
•Télécharger le fichier formation_travaux.po
•Créer un sous répertoire i18n à l’intérieur le dossier du module
•Coller le fichier formation_travaux.podedans
•Créer une copie du fichier avec le nom fr.po
•Ouvrer l’éditeur Poeditet traduire les messages du fichier fr.poen français
•Enregistrer et redémarrer le serveur, puis lancer un mise à jour du module.
•Si la base de données est installée en français, le module va prendre en considération le fichier fr.po

Paramétrage et développement spécifique des modules odoo(OpenERP)
aitmlouk@gmail.com
Laboratoire ETRI

Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1
Twiter: https://twitter.com/aitmlouk
Facebook: https://www.facebook.com/iminoika
Viadeo: http://ma.viadeo.com/fr/profile/addi.mlk
Linkedin: https://www.linkedin.com/pub/addi-ait-mlouk/56/850/32a
Youtube: https://www.youtube.com/user/mloukaddi/videos
Github: https://github.com/aitmlouk
Slidshare: http://fr.slideshare.net/mloukaddi/
aitmlouk@gmail.com
Module spécifique
Conclusion
Conclusion
Laboratoire ETRI

Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1

Contenu connexe

Tendances

Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1