default_get called twice

Bug #985699 reported by David Lefever @ Taktik
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Web Client
Fix Released
Undecided
OpenERP Publisher's Warranty Team

Bug Description

Hello,

in the web client, default_get of a wizard is called multiple times (twice).

Is it normal?

Thank you,
David Lefever.

Tags: maintenance

Related branches

Changed in openobject-client-web:
assignee: nobody → OpenERP Publisher's Warranty Team (openerp-opw)
tags: added: maintenance
Revision history for this message
Mohammed Shekha(Open ERP) (msh-openerp) wrote :

Hello,

This has been fixed and merged with lp:~openerp-dev/openobject-client-web/6.0-opw-574014-cpa.

Revsion No. 4846.

Thanks.

Changed in openobject-client-web:
status: New → Fix Released
Revision history for this message
Alexis de Lattre (alexis-via) wrote :

This issue is also present in OpenERP 6.1 with both the Gtk client and the Web interface (tested with Firefox).

Revision history for this message
Alexis de Lattre (alexis-via) wrote :

Here is a more accurate description of the problem :

I have several fields attached to an osv_memory wizard. I have defined a default_get function that sets the default value for these fields.

When I launch the Wizard, the default_get function is called and the fields of my wizard get a value. Then, I click on one of the buttons of the wizard : in the function called by the button, I do a self.read(cr, uid, ids[0], [fields], context=context) to read the fields of my wizard -> the default_get function is called a second time.

Revision history for this message
Alexis de Lattre (alexis-via) wrote :

After some more investigation, I found out that it's NOT the "self.read" in the code of the button that triggers the second call to default_get.

When you click on a button of the wizard, the OpenERP framework calls the self.create() method, who is responsible for the second call to default_get. It does that because i have some readonly fields in the wizard that are set by default_get() ; as these fields are readonly, they are not passed to create(), so the framework calls default_get() to get the values for these readonly fields.

The big mess with readonly fields not passed to create() nor write() is a well known problem of the OpenERP framework, cf https://bugs.launchpad.net/openobject-client/+bug/378824

Revision history for this message
jordg (gbj) wrote :

This has been purplexing me also
For a work arround:

Create 2 columns. One the real variable and the other the display variable.
Make the real column invisble and the display column readonly.
Pass the real column to some_onchange(product_id, real_column) and return real and display columns
In your action code called after OK button you can access your real_column in your object.

For example
Decalre 2 columns. In this case date.

        'date': fields.datetime('Issue Date', help="Date of Issue"),
        'date_d': fields.dummy(string='Issue Date', type='datetime', help="Date of Issue"),

Set defaults via _defaults or default_get()
        'date': lambda *a: time.strftime('%Y-%m-%d %H:%M:%S'),

In your view create 'date' invisible and 'date_d' readonly
Pass date to some onchange function
        <field name="date" invisible="1"/>
        <field name="date_d" readonly="1"/>
        <field name="product_id" colspan="6" default_focus="1" on_change="onchange_product_id(product_id, date)"/>

In your onchange return date and date_d:
def onchange_product_id(self, cr, uid, ids, product_id, date):
        ...
        return { 'value':{
            'product_uom':product['uom_id'][0],
            'soh':product['qty_available'],
            'date':date,
            'date_d':date,
            'name':name,
        }}

When you press OK call some action. Here your 'date' is the correct value
def my_action(self, cr, uid, ids, context=None):
        o = self.browse(cr, uid, ids[0], context=context)
        date = o.date

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.