openerp-expert-framework team mailing list archive

Thread
Date

[Bug 1023615] Re: Module upgrade ignores noupdate attribute for deleted records

To: openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
From: Don Kirkby <1023615@xxxxxxxxxxxxxxxxxx>
Date: Tue, 04 Sep 2012 17:38:38 -0000
Reply-to: Bug 1023615 <1023615@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx

To help with the discussion, I have summarized the three proposed
solutions and added them to the end of the bug description.

** Description changed:

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.
+
+ Analysis:
+ It appears that two changes may affect this behaviour. One of the changes in version 6.0 was to start deleting ir_model_data records when you delete what they point to. (See comments 2 and 11 for more details.) This means that the module upgrade process can't tell whether a record was newly added with this version and should be created, or the record was deleted by an administrator and should not be recreated. The other relevant change was from before version 5.0 to make forcecreate default to True. This means that when the upgrade process doesn't see a record in the database, it will create it. (See comments 9-12 for more details.)
+
+ Proposed solutions:
+ 1. Leave the code as is - instead of deleting configuration records, mark them as inactive so they won't get recreated.
+ 2. Stop deleting ir_model_data records - that way the module upgrade process can tell whether the configuration record is new with this version or not. See comment 2.
+ 3. Change the default forcecreate back to False - that way most records would not be created after the initial installation of a module. See Turkesh's merge proposal from trunk-bug-1023615-tpa.
+
+ My personal preference is for option 1 or 2. With option 3, I think that
+ many bug fixes or enhancements to modules would not be released
+ correctly, because adding new records to modules that are already
+ installed would be ignored.

--
You received this bug notification because you are a member of OpenERP
Framework Experts, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1023615

Title:
Module upgrade ignores noupdate attribute for deleted records

Status in OpenERP Server:
Fix Committed

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.

Expected behaviour: the "g" record should stay deleted because product_data.xml used noupdate="1".
Actual behaviour: the "g" record is recreated.

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.

Analysis:
It appears that two changes may affect this behaviour. One of the changes in version 6.0 was to start deleting ir_model_data records when you delete what they point to. (See comments 2 and 11 for more details.) This means that the module upgrade process can't tell whether a record was newly added with this version and should be created, or the record was deleted by an administrator and should not be recreated. The other relevant change was from before version 5.0 to make forcecreate default to True. This means that when the upgrade process doesn't see a record in the database, it will create it. (See comments 9-12 for more details.)

Proposed solutions:
1. Leave the code as is - instead of deleting configuration records, mark them as inactive so they won't get recreated.
2. Stop deleting ir_model_data records - that way the module upgrade process can tell whether the configuration record is new with this version or not. See comment 2.
3. Change the default forcecreate back to False - that way most records would not be created after the initial installation of a module. See Turkesh's merge proposal from trunk-bug-1023615-tpa.

My personal preference is for option 1 or 2. With option 3, I think
that many bug fixes or enhancements to modules would not be released
correctly, because adding new records to modules that are already
installed would be ignored.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/1023615/+subscriptions