Incorrect computation of cooperator_type ?

[victor-champonnois]

In cooperator, the field cooperator_type is computed in the following manner:

    @api.multi
    @api.depends(
        "share_ids",
        "share_ids.share_product_id",
        "share_ids.share_product_id.default_code",
        "share_ids.share_number",
    )
    def _compute_cooperator_type(self):
        for partner in self:
            share_type = ""
            for line in partner.share_ids:
                if line.share_number > 0:
                    share_type = line.share_product_id.default_code
                    break
            partner.cooperator_type = share_type

This will set cooperator_type to the first share_type in the share_line table. In the case when a cooperator has several share types, the first one will arbitrarily be chosen.
It is technically possible for a cooperator to have several share types (no constraints exists), so this could be an issue.

[robinkeunen]

Until we find a foolproof way of doing this (needs to check the analysts), fetching the share created last could be a good heuristic.

[enricostano]

Hi @robinkeunen and @victor-champonnois !

We're migrating right now a quite big cooperative (6k members) and we face this specific issue since it is a multi stakeholder coopderative and the same member could pertain to different membership "categories" at the same time.

Translated to EMC... ehm, sorry... Cooperator language, it means that a single member can subscribe multiple share types at the same time.

This leads to the issue @victor-champonnois is pointing out. Actually, the whole Cooperators "list" should be re-designed to cover this use case IMHO.

What do you think?

[enricostano]

Also related, I guess: https://github.com/coopiteasy/vertical-cooperative/blob/12.0/cooperator/models/operation_request.py#L167-L168

[robinkeunen]

Hi @enricostano

I agree we could do better with the cooperator list. One way of doing so is to have something similar to what we did in investor-wallet-platform to allow multiple memberships. We could also get inspiration from oca/vertical-association.

In both case, the modules add a "membership" model separate from the partner.

[robinkeunen]

Audit cooperator_type

cooperator

The field is defined on res.partner here :

vertical-cooperative/cooperator/models/partner.py

Lines 159 to 164 in 35443a5

	cooperator_type = fields.Selection(
	selection="_get_share_type",
	compute=_compute_cooperator_type,
	string="Cooperator Type",
	store=True,
	)

vertical-cooperative/cooperator/models/partner.py

Lines 102 to 109 in 35443a5

	def _compute_cooperator_type(self):
	for partner in self:
	share_type = ""
	for line in partner.share_ids:
	if line.share_number > 0:
	share_type = line.share_product_id.default_code
	break
	partner.cooperator_type = share_type

Issues:

• can't handle several share types of different types (takes the first share type)
• no unicity on default_code Bug with cooperator_type #318
• no enough doc on how default code is used
• bad variable naming

How should we handle multiple share types ?

• forbid several share types ? cf existing unmix_share_type parameter (only through operation requests)
• sequence on share types allows to set a hierarchy of share type ?
• allow to force share type manually ?
• last created share ?

cooperator_website

Prevents creating several shares of different types for a partner through the online form.

beesdoo_easy_my_coop

Will be split into

• cooperator_worker_information
• cooperator_eater_configuration

cf beescoop/Obeesdoo#427

The field definition is overridden in this way

    cooperator_type = fields.Selection(
        [
            ("share_a", "Share A"),
            ("share_b", "Share B"),
            ("share_c", "Share C"),
        ],
        store=True,
        compute=None,
    )

source

From the share type, also computes

• partner.is_worker
• partner.can_shop
• max number of eaters

Issues:

• breaks if other share type are defined
• hardcoded but no use of share string litterals in code ("share_a")

Also see #318

[robinkeunen]

Décision :

=> ajouter un champs séquence / hierarchie (pas de ir.sequence) sur les types de part
=> requis si le produit est une part
=> attention initialisation existant vs nouvelle base

[enricostano]

@robinkeunen would be great to have a small chat about this changes, would you mind a call next week? Thanks!

[robinkeunen]

Hey @enricostano, sure. I'm available monday-tuesday-wednesday mornings.

[robinkeunen]

@enricostano I need to have this conversation soon, I'll be working on this this week or the next.

[enricostano]

@robinkeunen sorry, I missed your comment. Would you mind a call talking about this? Thanks!

[victor-champonnois]

closed in favor of OCA/cooperative#18