← Back to team overview

c2c-oerpscenario team mailing list archive

[Bug 693102] [NEW] yml one2many records not deleted on uninstall

 

Public bug reported:

If a module's yml !record creates additional one2many related records, 
like this example creates both a res.partner record and a related res.partner.address,
the related record is not given a module ref id (ir_model_data.name),
thus will not be deleted upon module uninstall.
-
  !record {model: res.partner, id: res_partner_markjohnson0}:
    address:
      - city: paris
        country_id: base.fr
        name: Mark Johnson
        street: 1 rue Rockfeller
        type: invoice
        zip: '75016'
    name: Mark Johnson
-

When YamlInterpreter::_eval_field::one2many is called, 
it does the _create_record,
but fails to follow with a ir.model.data create/update,
like the parent record's process_record does properly.
___
class YamlInterpreter(object):

    # ...

    def _eval_field(self, model, field_name, expression):

        # ...

        elif column._type == "one2many":
            other_model = self.get_model(column._obj)
            value = [(0, 0, self._create_record(other_model, fields)) for fields in expression]
            ### Should be code here to create ir.model.data ... ###

    # ...

    def process_record(self, node):
            ...
            id = self.pool.get('ir.model.data')._update(self.cr, self.uid, record.model, \
                    self.module, record_dict, record.id, noupdate=self.isnoupdate(record), mode=self.mode, context=context)
           ### ... like this does correctly ###
___

I don't know if it's legal to create an ir.model.data with a blank ir_model_data.name,
If not, perhaps it could be an enumerated suffix could be added to the parent record's ir_model_data.name?

Or perhaps this could be handled using cascading deletes?  Not?

Workaround: don't use the automatic one2many facility; created all
!records individually and relate using module ref id's.

I volunteer to propose a patch, if assigned a mentor.

** Affects: openobject-server
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/693102

Title:
  yml one2many records not deleted on uninstall

Status in OpenObject Server:
  New

Bug description:
  If a module's yml !record creates additional one2many related records, 
like this example creates both a res.partner record and a related res.partner.address,
the related record is not given a module ref id (ir_model_data.name),
thus will not be deleted upon module uninstall.
-
  !record {model: res.partner, id: res_partner_markjohnson0}:
    address:
      - city: paris
        country_id: base.fr
        name: Mark Johnson
        street: 1 rue Rockfeller
        type: invoice
        zip: '75016'
    name: Mark Johnson
-

When YamlInterpreter::_eval_field::one2many is called, 
it does the _create_record,
but fails to follow with a ir.model.data create/update,
like the parent record's process_record does properly.
___
class YamlInterpreter(object):

    # ...

    def _eval_field(self, model, field_name, expression):

        # ...

        elif column._type == "one2many":
            other_model = self.get_model(column._obj)
            value = [(0, 0, self._create_record(other_model, fields)) for fields in expression]
            ### Should be code here to create ir.model.data ... ###

    # ...

    def process_record(self, node):
            ...
            id = self.pool.get('ir.model.data')._update(self.cr, self.uid, record.model, \
                    self.module, record_dict, record.id, noupdate=self.isnoupdate(record), mode=self.mode, context=context)
           ### ... like this does correctly ###
___

I don't know if it's legal to create an ir.model.data with a blank ir_model_data.name,
If not, perhaps it could be an enumerated suffix could be added to the parent record's ir_model_data.name?

Or perhaps this could be handled using cascading deletes?  Not?

Workaround: don't use the automatic one2many facility; created all !records individually and relate using module ref id's.

I volunteer to propose a patch, if assigned a mentor.





Follow ups

References