[10.0][medical_insurance] why plan uses inherits plan.template?

[JordiBForgeFlow]

Hi @LasLabs,

We are struggling to understand how to use the insurance.plan and insurance.plan.template. Perhaps in Spain our use case is different. We are in the point to decide whether to adopt this model or not.

We expect that the clinic could define a number of insurance.plan.template that are not specific to a patient. For example, Insurance 'Acme Inc.' has a a plan that covers dental care.

Then, patients do have individual insurance.plan, that refer to a plan template.

With the introduction of the inherits https://github.com/LasLabs/vertical-medical/blob/release/10.0/medical_insurance/models/medical_insurance_plan.py#L11 this approach is dangerous. A specific medical.insurance.plan would be able to change any of the fields of the template it inherits from (unless you totally hide the template fields, and only expose in the views the insurance_template_id).

What is your use case in the US?

cc @etobella @Eficent/eficent

[lasley]

@jbeficent Our use case is identical, but we just haven't gotten to the point of actually building out or using any of this. The security for .plan is set to only allow write by medical.manager, and the security for .template is only medical.configurator. Does the security not transfer over when using delegate inheritance?

Regardless of the security, you're probably right that this is dangerous. Maybe it would be better to adopt a template mechanism similar to what I did in OCA/contract?

[JordiBForgeFlow]

@lasley Why wouldn't you just refer to the insurance_template_id in the medical.insurance.plan using inheritance?

In this case, a medical.insurance.plan attributes, and refers to a template (a required field).

cc @gmeficent

[lasley]

@jbeficent - We found that a lot of the medical.insurance.plan.template fields were required in the context of the medical.insurance.plan, and IIRC this was admittedly just a shortcut to redefining a bunch of fields as related and readonly. TBH I didn't think about the readonly thing at the time, otherwise I would not have made this concession.

[JordiBForgeFlow]

@lasley so I understand that you need a bunch of fields from the template to be visible (and readonly) in the plan.

Since we are very interested in this, can we make a PR with with the proposed approach? (Avoid inherits, jist use a template_id field in the plan + bunch of related fields?

[lasley]

@jbeficent -

so I understand that you need a bunch of fields from the template to be visible (and readonly) in the plan.

Yup exactly. Information regarding the plan template (namely the fields here) are required in the context of the plan.

Looking at this, it might also make sense to move the notes field back from the template into the plan.

Since we are very interested in this, can we make a PR with with the proposed approach? (Avoid inherits, jist use a template_id field in the plan + bunch of related fields?

Definitely - Any and all contributions are welcome! With the recent merges in OCA/vertical-medical, I was actually about to submit the next round of PRs to cover the dependencies. I'll submit medical_insurance as is, then your team can submit to my branch. This way we can just nip this module in the butt & get it out of the LasLabs incubator. Sound like a plan?

[JordiBForgeFlow]

@lasley, excellent! Just to be in the same page here. When you say 'required', you mean that the user wants them to be visible.

Then, send the PR and we will start ASAP to propose the changes.

[lasley]

@jbeficent

When you say 'required', you mean that the user wants them to be visible.

Yup exactly!

I'm working up the PR now; expect a tag in 5-15 min