Update CSV files treated as noupdate=False

Bug #1024114 reported by Gustavo Adrian Marino
50
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Triaged
Low
OpenERP's Framework R&D

Bug Description

Hi all
There is a bug on V6.1 regarding .csv files. On update time, they are treated as noupdate=False, despite the documentation says they should be treated as noupdate=True
The attached patch correct the issue. It was already reported on bug #980369, but for a reason I don't known, never answered or treated

This bug can cause big difficulties, because .csv are used in two critical cases: initialization of the security records and initial customer data load.
In the first case (security descriptors), when you update the module, ALL CHANGES introduced to fine tune the security of the database are lost. That could be something easy to see (i.e. no access) or it could generate a major security breach for customer data, that could be eventually recognized when a (good) user reports problems, and thus the (bad) users will get granted access to restricted data for a while!
In the second case, initial customer data will be most probably updated by the customer on its daily operation. All changes will be LOST on an update of the initial modules (something common if you are on the initial phases of a project). Again, a critical case for many installation

I strongly believe this is a major problem.

This is a branch of https://bugs.launchpad.net/bugs/1023615

Revision history for this message
Gustavo Adrian Marino (gamarino) wrote :
Revision history for this message
Don Kirkby (donkirkby) wrote :

Looking for bugs related to CSV files and noupdate, I found two. Bug 397741 complained about security settings from the CSV files overwriting what the users had changed in the database. It asked for CSV files to be treated as noupdate="1", but was closed as invalid. Bug 787256 complained that failed CSV imports did not get rolled back, and it's been in the triaged state since June 2011. That bug is not particularly related to the noupdate attribute, but it did include the following in comment #4 from Olivier Dony.

>Note that there is a legacy difference between CSV files that are in the 'update_xml' section of
>the __openerp__ vs those in the init_xml/data sections. The former are in noupdate=False
>mode, the latter are in noupdate=True mode.

Revision history for this message
Gustavo Adrian Marino (gamarino) wrote :

Don:
The argumentation given is not solving the issue and it is not consistent with the current implemententation of modules

If at update time, csv are treated as noupdate=True (like in the current status) it is non consistent with the policy on almost 100% of addons, where the security info was placed on update, not init, and overwrites any customer modification

Additionally, it is not wath the doc says, and most important, it could generate a mess on database security!

Please take into account the profound impact this fault could have in actual installations (not demos)

Revision history for this message
Gustavo Adrian Marino (gamarino) wrote :

Attached you will find a patch to solve the general problem that even on init section, csv are treated as noupdate=False

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Gustavo,

This is closely related with lp:787256 and for the lp:787256 is in "Triaged ". And yes I agreed that CSV files treated as noupdate=False. But our framework will take the decision on it that either it's bug or it's behaviour.

That's why I am assigning this to Framework team, our Framework team will double check it and take the appropriate decision on it.

Thank you!

Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Asgardinho (felipereyesazul) wrote :

I also believe that this is a major problem.

does someone know what if the future of this?, it has been in Triaged for more than a year and 4 months, and with the problems mentioned in the bug report, this should not be low priority.

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

Other bug subscribers

Bug attachments

Remote bug watches

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