Surcharge d'un champ

[guile520]

Bonjour.

Dans un module custom, je parviens à ajouter des champs ou redéfinir une fonction.

Mais pas à redéfinir par le champ 'company' de account.payment. (le domaine pose problème lors d'un create)

J'ai ajouté un champ test pour vérifier que les déclarations, l'héritage du modèle étaient ok.

Dans odoo, quand j'avais ce problème, c'est parce qu'un autre module installé surchargeait déjà ce champ.

Je ne trouve aucun module installé dépendant de account.payment dans la base concernée ...

Une idée ?

modules installés activés:

account

account_fr

account_invoice

account_invoice_stock

account_payment

account_product

company

country

currency

ir

(module_test)

party

party_siret

product

res

sale

stock

web_user

[Jean Cavallo]

Bonjour,

Les modifications de champs doivent être faites dans le "__setup__" de la classe.

(ex: http://hg.tryton.org/modules/account_payment_sepa/file/tip/payment.py#l101)

En revanche, essayer d'enlever ce domaine me semble dangereux.

Jean Cavallo

Coopengo

[guile520]

Il n'y aura a priori qu'une seule compagnie.

Merci !

[Cédric Krier]

On 2017-09-21 06:27, guile520 wrote:
> Bonjour.
>
> Dans un module custom, je parviens à ajouter des champs ou redéfinir une
> fonction.
> Mais pas à redéfinir par le champ 'company' de account.payment. (le domaine
> pose problème lors d'un create)
> J'ai ajouté un champ test pour vérifier que les déclarations, l'héritage du
> modèle étaient ok.
>
> Dans odoo, quand j'avais ce problème, c'est parce qu'un autre module
> installé surchargeait déjà ce champ.
> Je ne trouve aucun module installé dépendant de account.payment dans la
> base concernée ...
>
> Une idée ?

La modification d'attribut de champs ne se fait pas de la même manière
qu'Odoo. On n'ajoute pas un champ avec le même noms sur la classe que
étend un Model existant car c'est toujours une copie du champs original
qui est utilisé pour construire la classe finale du pool.

Il faut manipuler le champs (une copie) depuis la méthode '__setup__'.
L'avantage est qu'on peut mettre de la logique comme tester si une
valeur de sélection n'existe pas déjà etc.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Cédric Krier]

On 2017-09-21 15:55, Jean Cavallo wrote:
> En revanche, essayer d'enlever ce domaine me semble dangereux.

On 2017-09-21 07:07, guile520 wrote:
> Il n'y aura a priori qu'une seule compagnie.

C'est vrai que ces domaines qui dépendent du contexte ne sont pas
terrible.
Ils devraient disparaitre avec https://bugs.tryton.org/issue4080
Mais en attendant, je suggère fortement de mettre l'unique compagnie
dans le contexte car enlever un tel domaine pourrait créer un bug dans
du code qui se base dessus.

[guile520]

"Mais en attendant, je suggère fortement de mettre l'unique compagnie 

dans le contexte car enlever un tel domaine pourrait créer un bug dans 
du code qui se base dessus."

Je connais mal 'le contexte', je ne l'ai utilisé auparavant qu'avec odoo pour passer des valeurs entre fichier xml et python.

Quelle est la syntaxe et à quel endroit du module custom (payment.py ?) dois-je l'ajouter svp ?

[Cédric Krier]

Le context se met à jour avec
http://doc.tryton.org/4.4/trytond/doc/ref/transaction.html#trytond.transaction.Transaction.set_context

Avec flask-tryton, le décorateur 'transaction' peut prendre un context
comme argument. Ou bien pour plus de dynamisme, on peut enregistrer un
callback qui doit retourner le context avec le décorateur
'default_context'.

Voir l'example sur:
https://pypi.python.org/pypi/flask_tryton

[guile520]

"Le context se met à jour avec
http://doc.tryton.org/4.4/trytond/doc/ref/transaction.html#trytond.transaction.Transaction.set_context

Avec flask-tryton, le décorateur 'transaction' peut prendre un context
comme argument. Ou bien pour plus de dynamisme, on peut enregistrer un
callback qui doit retourner le context avec le décorateur
'default_context'. "

Merci pour l'info.