Comment 5 for bug 1023615

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. I hope you get some attention
from OpenERP

2012/7/12 Don Kirkby <email address hidden>

> Sounds like the CSV problems should be a separate bug, Martin. I just
> looked at the docs[1], and it sounds like all CSV data in modules should
> be treated as if it had noupdate="1".
>
> [1]:
>
> http://doc.openerp.com/v6.0/developer/5_16_data_serialization/csv_serialization.html
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Server.
> https://bugs.launchpad.net/bugs/1023615
>
> Title:
> Module upgrade ignores noupdate attribute for deleted records
>
> Status in OpenERP Server:
> Confirmed
>
> Bug description:
> If I delete one of a module's standard configuration records, then
> upgrading the module recreates that record. This happens even when the
> noupdate attribute has been set. For example, when I delete a unit of
> measure, it comes back.
>
> I suspect this may have been a design change in v6.0 instead of a bug.
> If that's true, will I cause myself problems by changing it back? Was
> there a reason for the change, or did some users just prefer the new
> behaviour?
>
> Steps to reproduce:
> 1. Create a blank database with no demo data using version 6.1.1.
> 2. From the Settings menu, choose Modules: Modules.
> 3. Turn off the Apps filter and install the product module.
> 4. From the Settings menu, choose Users: Users.
> 5. Open the admin user and go to the Access Rights tab.
> 6. Set the Sales Management level to Manager, and turn on the Extended
> View.
> 7. Reload the main menu. From the Sales menu, choose Configuration:
> Products: Units of Measure: Units of Measure.
> 8. Delete the "g" record.
> 9. Go back to the Modules screen and upgrade the product module.
> 10. Go back to the Units of Measure screen and click the Find button.
>
> Expected behaviour: the "g" record should stay deleted because
> product_data.xml used noupdate="1".
> Actual behaviour: the "g" record is recreated.
>
> Workaround: instead of deleting the record, mark it inactive.
>
> Impact:
> There's no way for a user to tell whether a record is a standard
> configuration record or was added by a user, so they can't tell whether
> they're allowed to really delete it or they have to deactivate it. If I
> decide to live with the new behaviour, then I think I'll just have to tell
> the users not to delete any records from screens in the configuration
> menus. I guess that's probably a good policy anyway, because they can't
> easily tell whether it's being referenced by any child records.
> Where it's really biting us, though, is the migration process from
> version 5.0 to 6.0. Any records that we deleted, like currencies, are
> unexpectedly reappearing and causing errors.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/1023615/+subscriptions
>

--

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: <email address hidden>

Skype: gustavo.adrian.marino