Context is not passed to name_get() in many2one widget in read-only form view

Bug #1297882 reported by Lionel Sausin - Initiatives/Numérigraphe
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Web (MOVED TO GITHUB)
Invalid
Undecided
Unassigned

Bug Description

In the current v7, I noticed that when I set a context on a many2one widget, it is not sent to the server in some situations :
- in the "view ony" form view
- in the editable field in "edit" view
It is however correctly passed to the pop-up list under the editable field in edit mode.
It is also correctly passed to other widgets lik.e many2many-tags

Tags: maintenance
Revision history for this message
Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives) wrote :

Here is an illustration of this bug: I'm testing the module l10n_fr_naf from lp:openerp-data.
In partners, it adds a many2one to categories. It also imports a big file of official categories, with a 6 levels deep hierarchy.
So it uses a context key to demand short category names for display.
In the attached video you can see that the long name is returned instead, except in the pop-up list. You can see from the console that the key is missing from the context ("LONG" is printed on the console).

Changed in openerp-web:
assignee: nobody → OpenERP Publisher's Warranty Team (openerp-opw)
tags: added: maintenance
summary: - Context is lost in many2one widget
+ Context is lost in many2one widget in read-only view
summary: - Context is lost in many2one widget in read-only view
+ Context is lost in many2one widget in read-only form view
Revision history for this message
Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives) wrote : Re: OpenERP Enterprise Edition Bugfix: Context is lost in many2one widget (web client v7)

Thanks for your tests.
Indeed your video shows a case where it works. Maybe this is only a
problem with name-get?
You can see an example of where it fails using the standard addons here:
lp:~numerigraphe-team/openobject-server/7.0-exhibit-lp1297882-ls
<https://code.launchpad.net/%7Enumerigraphe-team/openobject-server/7.0-exhibit-lp1297882-ls>
You can test it on runbot here:
http://7-0-exhibit-lp1297882-ls-32877-all.runbot.openerp.com/#id=50&view_type=form&model=res.partner.category&menu_id=80&action=68
It's the latest 7.0 server with only 1 line changed: added context to
the parent in partner tags form.
I created a tag tree like this:
- partner
   - telecom
     - level3
       - level4
In "level4", the context demands that the parent be displayed as
"level3" instead of "Partner / Telecom sector / level3" (screenshot
attached).

Lionel.

Le 04/04/2014 07:46, Mohammed Shekha (msh) a écrit :
>
> Hello Lionel Sausin,
>
> For you reference I have created a video at my end and here is my
> video link.
> http://youtu.be/HEeCkRZZ8aw
>
> Please go through this video and let me know if I am missing something.
>
> It seems that you may using old code of OpenERP Web-Client, also make
> sure that your name_get is not called from some other function of your
> adddons and from there you might forget to propagate context.
>
> You may right that context is not passed through many2one but would
> you please provide me either scenario in standard module or provide me
> your test module so that I face and can fix it for you.
>
> Awaiting a response from you.
>
> ---------------------------------------------
> Regards,
> Mohammed Shekha,
> OpenERP Enterprise Services
>
> Sent by OpenERP India using OpenERP <https://www.openerp.com/>. Access
> your messages and documents through our Customer Portal
> <https://accounts.openerp.com/web/login?redirect=%2Fweb%23model%3Dproject.issue%26id%3D605780&token=9ppxSDjYL3MvY6ZRg2YS&db=openerp&mode=signup>

Revision history for this message
Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives) wrote :

Mohammed Shekha answered:
"I got your issue, you are not getting context when you are in readonly view and name_get is called.

Note that if you are overriding name_get method and value is coming based on context key then I would prefer always_reload option should set on that many2one field, so I would write something like below.

<field name="parent_id" context="{'partner_category_display':'short'}" options='{"always_reload": True}'/>

Note that when readonly view is displayed then name_get is not called by web-client so if you want to do explicit call of name_get then you must set this option on your many2one field."

"When search read is called to fetch existing record, server already gives key, value pair for records like(id, value) but when there is many2one is in effective_readonly mode(that is readonly view) at that time Web-Client do not call name_get method explicitly, it s server which calls name_get while reading record and at that time server will not having field based context right and hence you might getting wrong name_get value.

always_reload option will forces many2one to call name_get explicitly and hence youwill get proper result based on context."

summary: - Context is lost in many2one widget in read-only form view
+ Context is not passed to name_get() in many2one widget in read-only form
+ view
Changed in openerp-web:
status: New → Invalid
assignee: OpenERP Publisher's Warranty Team (openerp-opw) → nobody
Revision history for this message
Zeno Trevisan (zeno-trevisan) wrote :

I have a very similar issue, however I cannot overcome the problem with the options='{"always_reload": True}' as described by Mohammed Sheka. In my case I have a custom stock.location.balance object with a reference to the location. I am trying the group in a search view on the location_id (many2one on stock.location) but the group view will not display the location name but "undefined" despite using always_reload. How can it be enforced to call explicitly name_get?

Revision history for this message
Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives) wrote : Re: [Bug 1297882] Re: Context is not passed to name_get() in many2one widget in read-only form view

Le 15/07/2014 21:01, Zeno Trevisan a écrit :
> I have a very similar issue, however I cannot overcome the problem with
> the options='{"always_reload": True}' as described by Mohammed Sheka.
Then it would probably another proble, and I suggest you file a new bug,
or rather an "issue" on github now.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.