[5.2] one2many field in osv_memory doesn't send default values

[Alberto Luengo Cabanillas (Pexego)]

Hi community!

Using 5.2 version both in GTK client and server (June 21st 2010 revision), I got following error: After building an "osv_memory wizard" with a one2many field inside of it, I realized that if I didn't change the default values I filled it with (through a function), I didn't receive any value at all; however, if I add/edit/delete some values, all values of this field were properly sent.

Any idea?

Thanks in advance!

[Jay Vora (Serpent Consulting Services) (jayvora)]

This is currently working as expected.
Thanks.

[Margarita Manterola (marga)]

I don't understand... How can it be working as expected? Expected by whom?

I'm having the same problem, and I don't see how it could be working as expected. When resources are spent in populating the data for the osv_memory object, I don't want to waste those resources in re-populating the data, because for some reason someone decided not to send it.

I've already posted about it in the forums, including the whole code of my wizard:

http://www.openerp.com/forum/topic21513.html

Please tell me how I can achieve what I want WITHOUT re-creating the information and wasting resources uselessly.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello,

You can check the accounting configuration wizard and see its working.

Can you attach your module here,so we can check and tell you?

Thanks.

[Margarita Manterola (marga)]

Hola Jay (OpenERP)!

> You can check the accounting configuration wizard and see its working.

As far as I can see in the account/account.py file, the only one2many field
used in an osv_memory object is:

'bank_accounts_id': fields.one2many('account.bank.accounts.wizard',
    'bank_account_id', 'Bank Accounts',required=True)

Which is not populated through a defaults function, so I fail to see how
this relates to what is reported in the bug.

The problem is that the defaults function correctly populates the one2many,
but then this info is neither stored in memory neither sent back by the
client. Only the modified info is sent and given an id.

And it's not even trivial to merge with the items returned by the default
function, because there's no id to match them with. You need to somehow
identify the items and depending on the situation that might be difficult,
very difficult or impossible.

I'll try to make my module into a test case and attach it here.

--
Love,
Marga

[Margarita Manterola (marga)]

I'm attaching a test module to test this issue.

This module replaces the "Make packing" button in the out_picking_form. So, to test it, you need to have some out products (for example by creating a sale order), then press the "Make Shipping" button (I named it differently to be sure that the button had been replaced).

Once you press it, you get a one2many field that you can edit, with the same lines as the out_delivery. But when you press "Ok", only the lines you edited are sent back.

Some stuff is printed in the server console to show this.

[Margarita Manterola (marga)]

Hi!

I switched the bug back to "New". Please do not close it as invalid, since it's a real bug.

osv_memory objects are the way to make new wizards and with this bug there's plenty of old functionality that is lost. The module I attached is an attempt to migrate the stock_partial_picking wizard, which is not possible with the current behaviour.

[Azazahmed Saiyed (OpenERP) (saz-openerp)]

Margarita,

I agree that this is a problem.

We were targeting it to trunk as you mentioned version 5.2(which was supposed to be trunk).

As you sent the module,things have been clear now that you are talking about stable and that is 5.0.15 now(not at all 5.2).

Our R&D Teams are focused on the latest OpenERP version, and this issue does not affect it.

Our policy is to keep the changes applied on stable branches to a minimum, in order to limit the regression risks for customers that are in production. This means that bugs reported on Launchpad are fixed in the trunk branch only by default, even if they were reported against other stable versions.

We stand of course ready to backport the change to stable releases if it has an impact on any customer. In this case please report it to our maintenance team via the OpenERP Publisher's Warranty. They will quickly help solve the issue and backport the fix if needed.

Thank you for your understanding!

[xrg (xrg)]

On Thursday 23 December 2010, you wrote:
> I'm attaching a test module to test this issue.
>
> This module replaces the "Make packing" button in the out_picking_form.
> So, to test it, you need to have some out products (for example by
> creating a sale order), then press the "Make Shipping" button (I named
> it differently to be sure that the button had been replaced).
>
> Once you press it, you get a one2many field that you can edit, with the
> same lines as the out_delivery. But when you press "Ok", only the lines
> you edited are sent back.
>
> Some stuff is printed in the server console to show this.
>
> ** Attachment added: "Example module to experiment the undesired
> functionality."
> https://bugs.launchpad.net/openobject-client/+bug/660049/+attachment/17745
> 30/+files/test_packing.tar.gz

Allow me to make a note on this bug:
a couple of weeks ago, I have written a patch against orm_memory, which puts
more restrictions on the way these models work, including not-null validations
etc. (commit 85816908a45a13d)
In order to verify the operation of orm_memory, some example models and tests
are located in the 'test_orm' module of extra-addons. (commit 69307065e77e and
on)

A change in orm_memory, at this stage, may trigger unwanted side-effects that
may affect our release schedule. It could bring up some extra bugs, too, that
would break the functionality of some wizards. We don't want that. ( so far,
indeed, some wizards have shown bad behaviour after the orm_memory change and
fixed)

Please accept the fact that the "trunk" branch is now in a freeze process for
stability. We should not make any framework changes onto that. On the other
hand, everybody is free to experiment with custom branches on those features
we seem to want/challenge on the "trunk" server.

We do have already a backlog of bugs/features queued for v6.1 or even v6.0.1
(depending on their significance) and you are welcome to be a part of the
development process.

This "bug" will surely be in the list of things to consider for next ORM.