cannot make a sale order correctly

Bug #694124 reported by Aline (OpenERP)
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
High
OpenERP's Framework R&D

Bug Description

in web client
 (firefox)

Create a db with sale application installed. Create a user with only 2 groups : internal user and sales/User. As this user :
- create a sale order
- try to confirm or save it
-> Warning : You can not write in this document! (sale.shop)
- try to go to an other page (e.g. opportunity)
-> Message : The record has been modified Do you want to save it ?
- cancel this message
- go back into sale order list
- You can see the SO you have just created
If you open the form view, you can then confirm it and create the invoice.

Access rights are good because in GTK, it works well.

Related branches

Changed in openobject-client-web:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → OpenERP SA's Web Client R&D (openerp-dev-web)
Revision history for this message
Navrang Oza (noz-tiny) wrote :

Hello Aline,

It works well.
I can not reproduce this problem.

Please update your code and check it once.
Thanks.

Changed in openobject-client-web:
status: Confirmed → Invalid
milestone: none → 6.0-rc2
Revision history for this message
Antony Lesuisse (OpenERP) (al-openerp) wrote :

As a user only in group sale/user and internal user. When you save a sale order with lines, you get a lightbox:

You can not write in this document! (sale.shop)

But the sale order is written anyway.

Changed in openobject-client-web:
status: Invalid → Confirmed
Revision history for this message
Nicolas Vanhoren (OpenERP) (niv-openerp) wrote :

I was not able to reproduce it, everything goes fine. Altough I had to add the role "partner manager" to the user, else I can't choose a contact which is mandatory for sale orders.

Changed in openobject-client-web:
status: Confirmed → In Progress
affects: openobject-client-web → openobject-server
Changed in openobject-server:
assignee: OpenERP SA's Web Client R&D (openerp-dev-web) → OpenERP's Framework R&D (openerp-dev-framework)
milestone: 6.0-rc2 → none
status: In Progress → Triaged
Revision history for this message
Jiten (OpenERP) (jiten-openerp) wrote :

GTK does not affect this issue because, in this case GTK passed only fields which is modified by user, but Web Client passed all fields of the current record (modified or not).
So in this case server goes to check these fields are modified and than it gives raise exception error even when its not modified by user.

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

We can try to implement a workaround for this in the framework, but the behavior is quite correct: apparently the web client is trying to write to the "company_id" field that is hidden, readonly, and has not been modified by the user.
As the company_id field of the sale.order is a related field on the sale.shop, you cannot write to it as a mere Sales/User.

BTW after v6.0 we should really modify the web client to make sure it does not try to write() fields that have not been modified.

Changed in openobject-server:
status: Triaged → In Progress
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

After further investigation, the web client and server behave correctly when the field is marked as "read-only", which is missing in the case of the related "company_id" field on the sale.order. This is to be fixed in the "sale" module, as well as any module that has the same mistake: related fields that should be read-only and are not.

affects: openobject-server → openobject-addons
Revision history for this message
Antony Lesuisse (OpenERP) (al-openerp) wrote :

The company_id was not readonly fixed in commit:
revno: 4179
revision-id: <email address hidden>

Changed in openobject-addons:
status: In Progress → Fix Released
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.