Configuration¶
Roles¶
The 4 seeded roles (see Get Started §2) ship with sensible defaults. Two of them use expression partner resolution (chair, vendor) — they auto-fill the signer from the parent record. The other two (role_committee_member, role_hospital_signer) use empty policy and the bridge fills the partner explicitly at "Send for Signature" time.
Editing a role¶
Sign → Settings → Roles → open the role → edit. The XML data file uses noupdate=1, so your edits survive module upgrades.
Common customizations:
- Renaming the bilingual label (e.g. swap order of EN/TH)
- Adding a
default_partner_idforrole_vendor_signerto make a specific contractor the signer when bulk-using the demo template
Adding a new role¶
If you need a fifth role (e.g. "Witness"), add it through the UI. The bridge code only references the 4 seeded roles by XML ID, so a new role only affects bulk "Sign from Template" workflows — not the inspection or contract per-record flows.
Hospital Authorized Signer¶
On the contract form, the Hospital Authorized Signer field (roots_hospital_signer_id) is a res.users Many2one. Set this to the person at your hospital who has signing authority — often the BME Department Head or the Hospital Director.
The field is required at signing time (not at contract creation). You can create a contract without it set, but action_send_for_signature will refuse to fire until it's populated.
Distinction from user_id (Responsible):
| Field | Purpose |
|---|---|
user_id | Hospital-side contract owner — receives renewal alerts (Q3.7), is the default assignee for contract-related activities |
roots_hospital_signer_id | Person with authority to e-sign the contract on behalf of the hospital |
The same user can fill both roles, but they're separate fields so the owner can delegate signing to a senior signatory without losing contract-management context.
Demo templates¶
Two pre-built sign.oca.template records ship with the module (installed when Demo data is checked at install):
| Template | Linked to | Pre-placed fields |
|---|---|---|
sign_oca_template_inspection_demo | hemms.asset.inspection | 1 chair signature (drag the 2 member signatures onto the PDF yourself) |
sign_oca_template_contract_demo | hemms.service.contract | 2 signatures (vendor + hospital) — full layout |
These templates power the Sign → Templates → Sign from Template bulk-action flow. They are NOT used by the per-record "Send for Signature" button on the form (which renders the live qweb PDF every time).
Replacing the demo PDFs¶
The demo PDFs are generic blank pages copied from sign_oca/tests/empty.pdf. To replace with hospital-styled forms:
- Sign → Templates → open the demo template
- Click Upload PDF → select your real PDF
- Click Configure Document → drag/drop the signature, text, and check fields onto the new pages
- Save
The template's model_id link to the bridged model persists, so the "Sign from Template" bulk action continues to surface on inspection or contract records.
Per-record vs template-based signing¶
A reminder of which flow uses what:
| Flow | PDF source | When to use |
|---|---|---|
| Send for Signature (button on the form) | Live qweb render of the parent record (inspection report / contract summary) | Normal day-to-day — what hospital users will do 95% of the time |
| Sign from Template (bulk action) | The template's uploaded PDF | When you have an externally-prepared PDF (e.g. vendor's contract draft) that doesn't match the qweb-rendered version |
Both flows end up with a sign.oca.request linked to the parent via record_ref + hemms_asset_inspection_id / hemms_service_contract_id, so the Q4.5 hook fires for both, and the signed PDF lands on the parent's chatter the same way.