[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

[CRogos]

@max3903 I've implemented it by extracting template into the module agreement_template. The template feature is still configurable by group_

@peluko00 #124 should now be integrated. Could you test the modules?

I am now retesting the migration script and before we merge I would like to squash the last two commits.

[haivanlive]

@CRogos
I can't create an agreement template, pls fix it

[CRogos]

@haivanlive thanks. The New button is now visible again for the manager role.

[CRogos]

@max3903 could you update your review? The template recompute issue should be solved.

The migration script worked, but during testing I still finding minor issues.

[max3903]

@CRogos I have stated my position on this refactoring. Don't expect me to approve it in its current state.

[CRogos]

@max3903 of cause not, but you could confirm that the missing functionality is implemented now.
I have the problem, that the v18 version of agreement_legal is only usable with highly customization, which removes all the benefits of this module.

I think we should collect more feedback maybe from @peluko00 @ygol @haivanlive , or some of the agreement module users like @vangnp3702 if they also benefit from the feature separation.

[peluko00]

@max3903 of cause not, but you could confirm that the missing functionality is implemented now. I have the problem, that the v18 version of agreement_legal is only usable with highly customization, which removes all the benefits of this module.

I think we should collect more feedback maybe from @peluko00 @ygol @haivanlive , or some of the agreement module users like @vangnp3702 if they also benefit from the feature separation.

I have the same idea as @max3903 to don't split the module.
The feature for example for recompute can be used by an activate feature in config.

[ygol]

Same opinion here to not split the module

[CRogos]

@peluko00 I've moved recompute to the agreement_template. agreement_revision and agreement_product depends on template. Moving all the template stuff into agreement module would make things easier, but I did not want to change to much on the agreement base module. The agreement_template feature itself is still controllable by user group, as before.

I still don't see the benefit, why not to move things like revision or stage into separate modules which can be used by agreement, without agreement_legal. If you come to the OCA Days you may explain it to my on a beer.

I think the best way to continue is to split in to two worlds. I'll rename this agreement_legal into agreement_* focusing on my requirements and not on backwards compatibility. I'll mark all the modules in this PR as incompatible with "agreement_legal" for better distinction. I'll also remove agreement_legal_content because this part is ugly anyway.

Someone else can than provide a new 1:1 migration of agreement_legal according to your needs.

@vangnp3702 do you have contact to other agreement module users? Maybe we can discus what else could be added/changed to the agreement module. The settings menu and security roles have already been merged into agreement, but maybe we could also add a kanban view or move some template stuff?

(not today, first I'll give some time for more discussions ;) )

[vangnp3702]

@peluko00 I've moved recompute to the agreement_template. agreement_revision and agreement_product depends on template. Moving all the template stuff into agreement module would make things easier, but I did not want to change to much on the agreement base module. The agreement_template feature itself is still controllable by user group, as before.

I still don't see the benefit, why not to move things like revision or stage into separate modules which can be used by agreement, without agreement_legal. If you come to the OCA Days you may explain it to my on a beer.

I think the best way to continue is to split in to two worlds. I'll rename this agreement_legal into agreement_* focusing on my requirements and not on backwards compatibility. I'll mark all the modules in this PR as incompatible with "agreement_legal" for better distinction. I'll also remove agreement_legal_content because this part is ugly anyway.

Someone else can than provide a new 1:1 migration of agreement_legal according to your needs.

@vangnp3702 do you have contact to other agreement module users? Maybe we can discus what else could be added/changed to the agreement module. The settings menu and security roles have already been merged into agreement, but maybe we could also add a kanban view or move some template stuff?

(not today, first I'll give some time for more discussions ;) )

I think you should review the migration script again because translate=True makes agreement_type.name a jsonb column. Currently, your script doesn't handle that right?

[CRogos]

@vangnp3702 are you on the latest version of v18?
https://github.com/OCA/agreement/blob/18.0/agreement/models/agreement_type.py
There was a recent change to translate=True in v18. #124

I tried to handle both input in the migration, but I failed. Therefore you need to install the latest v18 first.

[CRogos]

I've created a dedicated PR for each new module. Each module is marked as incompatible with agreement_legal

agreement_template #134
agreement_stage #135
agreement_type #136
agreement_termination #137
agreement_signature #138
agreement_revision #139
agreement_product #140

Because I don't use the functionality of agreement_legal_content and agreement_legal, this is not available as dedicated module.

I will now close this PR so it is not blocking #132