Use class method to define state selection in addons instead of list

Registered by FireMage

There are some cases when custom module needs to add some state to model it extend. And when using standard way of redefining field state there may be conflict betwen few such modules.

For example we have next classes doing redefenition in standard way:

Module A:
class A:
    _inherit = 'sale.order'

    _columns = {
        'state': field.selection([<standard seection copied from sale module>], ('new1', 'New state 1'),...)
    }

Module B:
class B:
    _inherit = 'sale.order'

    _columns = {
        'state': field.selection([<standard seection copied from sale module>], ('new2', 'New state 2'),...)
    }

These modules are independent of each other (each do not know about other)

And in these case there will appear only one of new states in selection in sale.order model. And as of OpenERP 7 there sale_stock module, which redefines state too.

It would be nice to rewrite state definition for such modules to use method/function instead of inlining list/tuple in fields. definition.

To describe what i mean, just imagine flowing situation:

Module sale:
class sale_order:
    def _get_state_selection(self, cr, uid, context=None):
         return [
              ('draft', 'Draft'),
              ... <other standard states>
         ]

    _columns = {
        'state': fields.selection(_get_state_selection, ...)
    }

And now, each module can override this function changing its result using super:

Module A:
class A:
    _inherit = 'sale.order'

    def _get_state_selection(self, cr, uid, context=None):
         res = super(A, self)._get_state_selection(cr, uid, context=context)
         res.append( ('new1', 'New state 1') )
         return res

Module B:
class B:
    _inherit = 'sale.order'

    def _get_state_selection(self, cr, uid, context=None):
         res = super(B, self)._get_state_selection(cr, uid, context=context)
         res.append( ('new2', 'New state 2') )
         return res

So this will make module less coupled, and will allow third-party modules to make big changes to workflow easier.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
Proposed for trunk
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.