openerp-india team mailing list archive

["Stefan Rijnhart \(Therp\)" <1023615@xxxxxxxxxxxxxxxxxx>]

Hi Don,

I agree that both mechanisms of readding the records as well as deleting
them at upgrade time when their XML IDs are not present in the module
anymore are in place to support an automatic upgrade procedure between
versions. In fact, they make the effort of the OpenUpgrade project
relatively easy as it relieves us of having to load new data and
cleaning up obsolete data. But the automatic recreation of 'noupdate'
records in XML files is related to the commit that I referred to. Let me
try and clarify.

>From your bug report: "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."

>From the OpenERP documentation: "The noupdate attribute can be
overridden by marking a record with forcecreate="True". This means that
the record will be created if it doesn’t already exist in the database,
but it won’t be modified." (see [1])

As per the commit I referred to, the 'forcecreate' attribute is implicit
in any XML record definition, defaulting to True.

Of course, if you have been able to upgrade your modules with every 5.0
release without these records being recreated, then this commit is
indeed not the whole story as you remark correctly that it was always
there.

Anyway, I do agree that this behaviour leads to real problems such as
those that your case demonstrates that should be solved. The problem
with your suggestion of having the OpenERP upgrade mechanism respect a
dangling row in ir_model_data as a sign that the record was removed
manually is that certain data entries are simply assumed to be present
in parts of the code as well as referred to in other modules. My
suggestion would be to have the  'forcecreate' tag set to 'False' on the
multitude of XML records for which is isn't the case.

You could consider consulting the expert framework list on this issue.

Cheers,
Stefan.

[1]
http://doc.openerp.com/v6.0/developer/5_18_upgrading_server/index.html
#table-object-structure

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is 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