Questions and suggestions for `agreement` and `agreement_legal`

[tarteo]

• Is there a reason why the templates menu is not in agreement directly. That module introduces the field
• I would also think stages (agreement.stage) are generic and should belong in agreement
• Why is subtype (agreement.subtype) created, why not parent / child relation on type (agreement.type)?
• I would expect agreement to have the res.config.settings stuff
• We could make the Dynamic field editor an mixin so we have less reduncency
• agreement has no configuration menu for agreement.type

[tarteo]

@CRogos @max3903 @ygol please let me know what you think

[ygol]

agreement can be used without agreement_legal.

The split exists because they serve two different types of "Agreements": one that is an Administrative/Financial Record and one that is a Legal Document.

1. agreement (The Base)
   This module is essentially a metadata container. Many organizations use it simply to group disparate Odoo records under a single "Agreement Number."

Why use it alone? Many companies have their contracts signed via external tools (DocuSign, physical paper, or legal firms) and don't need Odoo to manage the text. They just need a "Box" in Odoo to hold:

Related Records: Link a specific Agreement to 5 different Sale Orders, 2 Projects, and 12 Months of Invoices.

Expiration Tracking: Send a notification 30 days before a contract expires.

Versioning: Tracking that "Agreement V2" replaced "Agreement V1" without needing to see the internal clauses.

Current State: Because it's lightweight, it has been migrated more quickly across Odoo versions and acts as the "Base" for many vertical modules (like agreement_sale, agreement_project, and agreement_purchase).

2. agreement_legal (The Extension)
   This module is for Contract Lifecycle Management (CLM). It adds "content" to the "box."

The Difference: While agreement gives you a name and a date, agreement_legal gives you the Section and Clause structure.

Is it necessary? Only if you want to actually generate the PDF of the contract. If you already have the PDF from an external source and you just want to attach it to a record, agreement_legal is overkill and adds unnecessary complexity to the database.

[tarteo]

Okay clear, I would have done it differently but who cares. Still:

• Is there a reason why the templates menu is not in agreement directly. That module introduces the field, otherwise move the field to agreement_legal
• I would also think stages (agreement.stage) are generic and should belong in agreement. Still need it in the base module, as I want to store a PDF and signed scanned PDF of the agreement as an attachment Stages in agreement are not bloat and should be usable without installing 200 fields that agreement_legal introduces
• Why is subtype (agreement.subtype) created, why not parent / child relation on type (agreement.type)?
• I would expect agreement to have the res.config.settings stuff. It mostly installs other modules which can easily be moved to agreement itself including an option for agreement_legal ala module_agreement_legal
• We could make the Dynamic field editor an mixin so we have less reduncency. Done [18.0][REF] agreement_legal: Replace repeated dynamic field code with mixin #105

Just let me know if I can refactor the above points or would I be wasting my time

BTW: I'm also not suggesting to move all fields from agreement_legal to agreement, just the basic fields unrelated to legal stuff, I don't know where I mentioned that...

[CRogos]

We are currently introducing agreement / agreement_legal and are also struggling with some implementation details. Some are already mentioned in the roadmap
and should defently be done with the next version.
We've also think replacing existing views is not a good practice. Instead the existing form should be extended: #101

I also agree with @tarteo that agreement_legal if it is based on agreement should not "reinvent" the hole look and feel. I was also very confused that everything is on a diffent place after installing agreement_legal.
If there are fields in agreement that are not needed in agreement_legal, than we maybe should move them to a 3rd module agreement_??? or move the common fields to base_agreement?

For v18 this #105 is fine, but for v19 we might think about a dedicated module agreement_fields?