Archives du mot-clé Exemple

Appli YD – filtrage/recherche des adhérents (7/7)

Pour conclure, j'aimerai apporter 2 améliorations :

  1. être sûr de n'afficher que les adhérents dans la vue "adhérent"
  2. aménager la recherche des adhérents

1 - Affichage uniquement des adhérents
Notre notion d'adhérent étant héritée de l'objet "Partner" qui peut aussi bien désigner un client, un fournisseur, un employé qu'un adhérent, il faut s'assurer que nous n'affichons dans la vue "adhérent" que des adhérents.
Pour cela, nous allons ajouter un attribut à l'objet 'Partner' qui précisera notre notion d'adhérent.

Nous allons modifier la classe "yd_member" en ajoutant cet attribut appelé "ydmember"

extrait fichier "yd.py"

 ... puis la vue en ajoutant un filtre "... domain ..." sur cet attribut

extrait fichier "yd_view.xml"

2- aménager la recherche des adhérents

... en ajoutant un filtre "Tarif réduit"

... en recherchant soit par le nom de l'adhérent, soit par le nom des cours

Pour cela, nous ajoutons une vue spécifique de type "search"

extrait fichier "yd_view.xml"

et nous la référençons dans l'action par la ligne "... search_view_id ..."

extrait fichier "yd_view.xml"

Appli YD – envoi de courriel – 3ème version (6/7)

L'objectif de cette nouvelle version est de pouvoir créer et envoyer un courriel à un ou plusieurs adhérents.
Nous allons tout d'abord ajouter le module "mail" à notre configuration.

Pour cela nous modifions notre fichier __openerp__.py en ajoutant "mail" dans les dépendances

Cela a comme conséquence de :

  • ajouter "messagerie" dans le menu général OpenERP

  • ajouter le choix "mass mailing"  lorsque l'on sélectionne un ou plusieurs adhérents dans le menu "tree"

Ensuite nous allons dans le menu "Configuration/Paramètres généraux" pour paramétrer notre serveur sortant de courriels

En théorie, ces opérations auraient dû suffire pour permettre d'envoyer des mails grâce au wizard "mail.compose.message" appelé par le choix "Mass Mailing"

Malheureusement, il y a un bug (corrigé en V8) dans la version actuelle et nous appliquerons le contournement proposé ici
Ce qui se traduit par la création du modèle de courriel suivant

en précisant dans l'onglet "avancé", notre serveur de courriels sortant

Ensuite, dans le formulaire d'envoi (wizard), il faut utiliser le modèle "YD bug send mail" créé pour l'occasion

Appli YD – gestion des adhérents – héritage de classe (5/7)

Dans la 1ère version de l'appli, nous avons utilisé une variante d'héritage appelé "héritage de prototype" (à droite sur le schéma ci-dessous) qui consiste à dupliquer l'objet "hérité", en l'occurence "Partner".
Cela interdit ensuite de réutiliser les vues, wizard, workflow (etc ...) existants en lien avec l'objet d'origine.

Pour cette 2ème version de l'appli, nous utilisons la variante "héritage de classe".
Elle nous donnera la possibilité de réutiliser la vue "form" de l'objet Partner et ultérieurement, le wizard d'envoi de mail.
Nous nous attardons uniquement sur les fichiers "yd.py" et "view".

Dans le 1er fichier, seule la valeur de "_name" est modifiée.

impact dans fichier "yd.py"

Dans le 2ème fichier , 2 possibilités :
  1- Pas d'héritage de vue :
pour la vue "form", on modifie la valeur "model" avec "res.partner"  et on rend cette vue (eval ... priority...) plus prioritaire que la vue par défaut "view_partner_form"

extrait fichier "yd_view.xml"

   ... et pour la vue "tree"

extrait fichier "yd_view.xml"

  2- héritage de la vue "view_partner_form" :
avec modifications apportées pour supprimer des champs et onglets affichés dans l'objet de base et ajouter les champs spécifiques à "yd.member" (cf documentation officielle)

extrait fichier "yd_view.xml"

Personnellement dans notre cas, les modifications par rapport à la vue "view_partner_form" étant assez importantes, je préfère ne pas utiliser l'héritage de cette vue.

Appli YD – gestion des adhérents – 1ère version (4/7)

Passons maintenant à la gestion des adhérents.
Nous avons uniquement à modifier des fichiers existants :

  1. le fichier view
  2. le fichier yd.py
  3. le fichier csv de droits d'accès
  4. le fichier de traduction

Pour chacun des 4 fichiers, voici les modifications apportées :

Lignes ajoutées dans fichier "yd_view.xml" (1/2)
Lignes ajoutées dans fichier "yd_view.xml" (2/2)
Lignes ajoutées dans fichier "yd.py"

Lignes ajoutées dans fichier "ir.model.access.csv"

 Le fichier de traduction "fr.po" lui, a été regénéré selon la procédure habituelle

Après ces modifications, nous arrivons au résultat suivant :

Appli YD – gestion des cours (3/7)

Commençons par la partie la plus simple de l'application YD : la gestion des cours.
Il s'agit de pouvoir rechercher/créer/supprimer/modifier un cours.

Cela consiste à créer :

  1. les fichiers __init__.py et __openerp__.py
  2. le fichier view
  3. le fichier yd.py
  4. le fichier de traduction fr.po
  5. les fichiers pour les droits d'accès

sous l'arborescence suivante :

Pour chacune des 5 étapes, voici les fichiers produits :

Etape 1 :

__init__.py
__openerp__.py

Etape 2 :

yd_view.xml

Etape 3 :

yd.py

Etape 4 :
Ce fichier a été produit selon la procédure décrite ici.

fr.po

Etape 5 :
Il faut tout d'abord créer un fichier xml qui :

  • catégorise l'application YD pour les droits d'accès
  • crée 2 groupes d'utilisateurs "user" et "manager"
yd_security.xml

Ensuite, il faut créer un fichier avec un nom imposé "ir.model.access.csv" qui définit les droits d'accès sur l'objet "yd.course" pour chacun des 2 groupes précédents (cf ici ).

ir.model.access.csv

En résumé, nous pouvons consulter, créer, modifier, supprimer et rechercher des cours ... avec :

  • 8 lignes de code Python (yd.py)
  • 2 fichiers xml (vue et droits d'accès)
  • 1 fichier de traduction
  • 1 fichier csv (droits d'accès)


Voici 2 copies d'écran :

Préparation du développement de l'appli YD (2/7)

Je vais apporter des modifications à mon environnement actuel :

* OpenERP et BD sur des serveurs distincts
Je choisis pour la 1ère fois d'exécuter OpenERP et la BD postgresql sur 2 serveurs distincts.
Pour cela, je crée un fichier dédié "myOERP.conf" qui va remplacer le fichier par défaut "openerp-server.conf", avec le contenu suivant :
[options]
db_host = '<adresse ip du serveur hébergeant la BD postgresql>'
db_port = 5432
db_user = openerp
db_password = False

et OpenERP sera lancé par :
./openerp-server --conf  /<mon repertoire>/myOERP.conf 

* Déploiement du nouveau module dans un répertoire dédié
Afin de bien séparer les modules standards OpenERP des modules "personnels", je crée un répertoire spécifique "mymodules" et j'ajoute dans le fichier "myOERP.conf", la ligne  :
addons_path = /<mon repertoire>/mymodules
  
* Configuration debug Eclipse
Pour débugger sous Eclipse , il faut configurer l'utilisation du fichier de configuration de lancement spécifique "myOERP.conf"
Pour cela, il faut ajouter une variable dans la configuration de debug :

 que l'on valorise ainsi

Développement de l'application YD (1/7)

Je voudrais passer du temps à nouveau sur le framework OpenERP et développer un nouveau module que j'améliorerai par itération au fur et à mesure de ma découverte du logiciel.
Ce module se nommera YD et concerne l'association dont je suis le trésorier.
J'ai déjà utilisé le module standard "gestion d'association" pour implémenter (en prototype) la gestion de cette association qui est actuellement en production sur Dolibarr.
Cette fois-ci, je voudrai partir de zéro sans utiliser de module existant.
J'utiliserai juste l'héritage de l'objet "partner" pour décliner la notion d'adhérent.
Un schéma freemind décrit les caractéristiques de cette application :

Description technique du scénario fonctionnel (5/5) – écritures comptables

En plus du lancement du workflow vu précédemment, la création de la facture "brouillon" prépare la future écriture  dans les journaux comptables (faite lors de la validation de la facture) en créant une instance de l'objet "account.invoice.line".
Une relation "account_id" est positionnée avec l'objet "account.account".
Or, cette relation "account_id" est positionnée à 856 (compte "707100") au lieu de 854 (compte "706000").

copie "pgadmin3"

Je me suis rendu compte grâce au debug sous Eclipse, que ce positionnement était mal fait et que cela provenait du code suivant :

sale_make_invoice_advance.py

Les 2 lignes
    ir_property_obj = self.pool.get('ir.property')
et
    prop = ir_property_obj.get(cr, uid,
                            'property_account_income_categ', 'product.category',    context=context)
montrent que l'origine du problème vient de la configuration de l'objet "ir.property"

Il s'avère que lors de l'installation de la base de données et du choix "plan comptable général (France)", on peut voir dans le menu ...

... que le paramètre "property_account_income_categ" n'est pas adapté à notre situation (vente de service et non pas de produit).

Il suffit donc de modifier ce paramètre avec le bon compte

Une fois cette modification faite et le scénario fonctionnel rejoué, nous avons (enfin) les écritures comptables attendues !!