Close button remembers changes

[Willem Bouma]

When you use the close button to close a separate window (sale.order.line and similar) it remembers changed data, if that object already existed.

Example:
Create a new sale order and add one sale order line, press ok to add this new sale order line to the sale order.
Now edit that same entry and make the description (or any other required field) empty, and press the close button.

If you now edit that same line the description will still be empty. So it won't validate unless you fill it in again.

Running the client with log-level=debug_rpc_answer shows that pressing the close button doesn't trigger any event.

The behavior I think I should be seeing is that it asks me if I want to save my changes. At least that's what I see in the handling of the close signal in the client code.

Using OpenERP 5.0.7 (both server and client).

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

It has been fixed by revision 1069 <email address hidden>.
It will be fixed on trunk today itself.
Thanks.

[Jean-Luc WEYL (jean-luc-weyl)]

I have tested version 5.0.12 and the problem is still the same

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

Hello Jean-Luc WEYL,

Would you please demonstrate a situation where you met this scenario?

Thanks.

[Jean-Luc WEYL (jean-luc-weyl)]

Using version 5.0.12, take the example described in #1 and just change the word "description" by the word "Product UoM":

Example:
Create a new sale order and add one sale order line, press ok to add this new sale order line to the sale order.
Now edit that same entry and make the Product UoM (or any other required field) empty, and press the close button.

If you now edit that same line the Product UoM will still be empty. So it won't validate unless you fill it in again.

[Jean-Luc WEYL (jean-luc-weyl)]

Another similar situation:
Create a new sale order and add one sale order line, press ok to add this new sale order line to the sale order.
DO NOT SAVE the sale order.
Now edit that same entry again, change the product, and press the close button.
The new product has replaced the old one.

[Naresh(OpenERP) (nch-openerp)]

Hello jean-Luc-WEYL,

 Your comment #4 is valid and was a bug. which has been improved @ lp:~openerp-dev/openobject-client/trunk-dev-client
 with revision info as 1415 <email address hidden> and will be merged soon to the trunk client.

 Now for the comment #5 which seems a whishlist rather then a bug because according to the current architecture of O2M
 or any other type:

case 1: If the model is not saved i.e does not have any ID yet :
            when you focus out of any field that field will fire an 'focus-out' event which in turn will store that field value in the internal client's model and will be used for the further operations. So when you press cancel as the model does not have ID will just return silently. here we may think to revert back to the old value but the question is from where would we get the old value as the models internal data has already changed.

case 2: If the model is saved i.e does have an ID:
            when you focus out of any field that field will fire an 'focus-out' event which in turn will store that field value in the internal client's model and will be used for the further operations.So when you press cancel as the model does have an ID here will make an read request to the server with the ID to get the latest stored values.

may be we should consider this for the future version improvements (i.e v6.1) or so .

Hope you understand.

Thanks,

[Naresh(OpenERP) (nch-openerp)]

I would like to revert back the commit for the comment #4 as this may cause a regression because now the user will not be able to close the dialog box at all if he has atleast 1 required field. say for eg: you need to create a sale order line and
you click on new to create new record the dialog box pop ups now you change your mind , you do not want to create a new record and you press cancel to close the dialog box but you want be able to close it until and unless you fill in the required field.
I am marking this bug as invalid. according to the architecture does not seems to incorporate such changes.

Thanks,