[19.0][MIG] agreement_legal: Migration to 19.0 + Refactoring

[CRogos]

@tarteo, @ygol, @max3903 I mention you because you were active in #104

I would like to take the opportunity to split the agreement_legal into several modules with the migration to odoo 19.

Changes in agreement and agreement_sale are not part of this PR. There is a separate PR to set the foundations: #122

Currently I've identified the follwing modules:
agreement_legal
agreement_signature
agreement_termination
agreement_legal_content
agreement_product
agreement_revision
agreement_stage
agreement_type

(There is a screenshot in each module, that shoes the change if each module individually)

The goal is to keep the current functionality when all modules are installed, but make it possible to only install a subset if the functions.

This PR will replace: #120
This PR depends on: #122

[max3903]

@CRogos We don't need to split the module. We can use group_* settings to activate/show features.

[CRogos]

@max3903 I understand your argument, and it is a valid approach. But is this the better solution? It would still blow up the database, and also the complexity of the module is still high.

With the current split it is also possible to use agreement_signature and agreement_termination without agreement_legal. My goal would be to achive this also for agreement_legal_revision, agreement_legal_stage and agreement_legal_type, but I am currently struggling with the access groups.

Do you disagree with splitting the module? (and how strong ;) )

[max3903]

@CRogos Yes, I disagree with the split. Experience shows me that:

1. if you split the module, it will age pretty badly across migrations.
2. you may be implementing and supporting those modules now, but what about in 1+ year?

When version 20.0 will be released, those 8 modules will not get migrated or they will, but not the way you expect. Worst thing is you may not be available to review those.

Same thing will happen with version 21, 22, etc... as you may not be financed to support them anymore.

So when you will look at those modules in 3+ versions, you will not recognize them: you will think you can use them for a new project and save some money, but you will end up putting the effort again or losing the opportunity or both.

[max3903]

@CRogos Also, I didn't build the OCA to be a module factory, I built it to provide long-term solutions.

[max3903]

/ocabot migration agreement_legal

[peluko00]

Hi @CRogos , can you please include this FW #124?

Thank you

[CRogos]

@peluko00 could you have a look into the update?
I had some trouble to implement this reset, because child_agreements_ids is now part of agreement_revision which does not depend on agreement_legal and I did not want to move recompute_from_template() to agreement.

If we want to achive this, we maybe need to extract the template part into agreement_template and create additional bridging moduls agreement_revision_template and agreement_product_template?

agreement_revision

    @api.model
    def recompute_from_template(self):
        res = super().recompute_from_template()
        agreements = self.browse(self.env.context.get("active_ids", [])).filtered(
            lambda a: a.template_id
        )
        for agreement in agreements:
            template = agreement.template_id
            agreement.child_agreements_ids.unlink()
            for child in template.child_agreements_ids:
                child.copy({"parent_agreement_id": agreement.id})
            return res

agreement_product

    @api.model
    def recompute_from_template(self):
        res = super().recompute_from_template()
        agreements = self.browse(self.env.context.get("active_ids", [])).filtered(
            lambda a: a.template_id
        )
        for agreement in agreements:
            template = agreement.template_id
            agreement.line_ids.unlink() # product
            for line in template.line_ids:
                line.copy({"agreement_id": agreement.id})
        return res

There is also a lot of improvement potential in agreement_legal_content (which I am not using). I think instead of the "field" placeholders, we should use the email template editor. I think the change is not complicated but the migration script could be more complicated.

[max3903]

Don't split. Use group_ settings to achieve the same result.

[CRogos]

Don't split. Use group_ settings to achieve the same result.

I know you like the group_ solution very much, but I am not convinced to add so many groups. Yes this would bypass the problem, but in my opinion this is not the right way, and only a work around and not solving the problem behind.

Maybe we should move template_id to agreement and activate the template feature by group_ ?