If your workflow requires signers to enter sensitive data like partial Social Security numbers, PINs, or confidential account references, you’ve likely asked: “Can we mask this field so the full value isn’t visible as they type?”
Odoo doesn’t include this feature natively—but that’s a deliberate design choice, not a technical gap. The good news? You can build it as a custom extension. The critical part is doing it in a way that preserves legal enforceability, audit integrity, and US e-signature compliance.
Here’s what you need to know before moving forward.
The ESIGN Act in 60 Seconds: Why Transparency Matters
Before diving into Odoo’s design choices, it helps to understand the federal law that shapes them.
The Electronic Signatures in Global and National Commerce Act (ESIGN Act) is the US federal law that gives electronic signatures the same legal standing as handwritten ones. Passed in 2000, it applies to all 50 states and covers most business, consumer, and commercial transactions.
Core Requirements That Impact Field Design:
Requirement | What It Means | Why Masking Complicates It |
|---|---|---|
Intent to Sign | Signers must clearly demonstrate they intend to approve the record | If input is masked, proving the signer saw and approved the actual value becomes harder |
Consent to Electronic Records | Signers must agree to conduct the transaction electronically | Masking doesn’t break this, but obscured content can muddy what was consented to |
Record Retention & Reproducibility | The signed record must be accurately retained and reproducible for all parties | If the UI shows •••• but the stored value is 1234, you now manage two representations |
Association of Signature & Record | The signature must be linked to the exact record in a way that detects changes | Masked input can fragment the audit trail, weakening the signature-to-data link |
The Bottom Line for Odoo Sign:
The ESIGN Act doesn’t forbid masked fields—but it does require unambiguous consent and a clear, human-readable link between the signer, the signature, and the exact content approved. Odoo’s native Sign module is engineered to meet this standard out of the box. Adding visual obfuscation by default would introduce legal uncertainty, so Odoo intentionally excludes it to keep every signed document defensible, transparent, and court-ready.
Think of it this way: The ESIGN Act asks, “Can you prove what the signer saw and approved?” Odoo answers by keeping every character visible during signing. If you need masking for UX reasons, you can add it—but you must preserve that proof.
🔍 Why Odoo Doesn’t Include Masked Fields Natively
Beyond the ESIGN Act, Odoo Sign is also designed to align with the Uniform Electronic Transactions Act (UETA) (adopted by 49 states + DC) and evidentiary standards like the Federal Rules of Evidence (FRE 901/902). Together, these frameworks create three compliance guardrails that make masked fields risky by default:
- Ambiguous Consent: If characters are hidden as they’re typed, it becomes harder to prove the signer reviewed and approved the actual value—not just the masked representation.
- Audit Trail Fragmentation: Courts and regulators expect a single, human-readable record linking the signature to the exact data approved. If the UI shows
••••but the backend stores1234, you now manage two representations of the same field. - Evidentiary Risk: Under FRE 901/902, electronic records must be authenticated and reproducible. Obscured input can complicate verification if the signature is ever contested.
Odoo’s product team intentionally excluded masked fields to keep the signing experience transparent, defensible, and court-ready. That said, if your business policy or industry workflow absolutely requires masked input, a custom extension is entirely feasible—provided it’s built with compliance guardrails from day one.
How to Build a Compliant Masked Field in Odoo 19 Sign
When masking is a business requirement, the goal isn’t to bypass Odoo’s compliance model—it’s to layer UX privacy on top of it. Here’s how to architect and deploy a solution that satisfies both users and auditors.
1. Core Architecture Principles
Layer | How It Works | Why It Matters |
|---|---|---|
Frontend (UI) | Mask characters as they’re typed using type="password" or a lightweight input-masking script. Add an optional “show/hide” toggle for signer control. | Provides the requested UX without altering backend data flow. |
Backend (Storage) | Always capture and store the raw, unmasked value in Odoo’s standard sign.request.item tables. Never persist masked strings. | Preserves audit integrity and ensures the executed record matches what was consented to. |
PDF Rendering | Default to displaying the full raw value in the final signed document. If business rules require masked output in the PDF, enforce an explicit consent step beforehand. | Keeps the executed contract court-admissible and legally defensible. |
2. Compliance-by-Design Safeguards
A compliant custom module must include these non-negotiable elements:
- Explicit Consent Checkpoint: Add a mandatory acknowledgment before signing, e.g.,
“I confirm the masked field represents [specific data type] and I approve its inclusion in this agreement.” Log the timestamp and signer ID. - Immutable Audit Logging: Rely on Odoo’s native signing logs. Do not override or filter audit entries for masked fields. Log input completion, visibility toggles (if used), and consent actions alongside standard IP/device metadata.
- Browser Autofill Prevention: Disable
autocomplete,autocorrect, andspellcheckon masked inputs to prevent password managers or mobile keyboards from caching sensitive values. - Access Control Alignment: Use Odoo’s record rules, portal tokens, and role-based permissions to restrict who can view masked field values in the backend. Masking the UI is not a substitute for proper data governance.
3. Development Roadmap & Effort
For a senior Odoo developer (5+ years experience), a production-ready, compliance-aligned extension typically requires 35–50 hours of focused work:
Phase | Deliverables | Effort |
|---|---|---|
Backend Setup | Extend sign.template.field, register masked type, enforce raw-value storage, configure access rules | 3–5 hrs |
Frontend UI | Build OWL component, implement masking logic, add visibility toggle, optimize for mobile/desktop browsers | 8–10 hrs |
PDF & Output | Configure rendering policy, validate final document output, ensure consistency across signers | 4–6 hrs |
Compliance & QA | Implement consent flow, verify audit log completeness, run accessibility (WCAG 2.1 AA) and cross-device tests | 8–12 hrs |
Documentation & Rollout | Admin configuration guide, deployment checklist, compliance implementation notes | 3–4 hrs |
Buffer | Legal review, minor revisions, Odoo framework compatibility checks | +10–15% |
Timeline: ~1 week for a focused senior developer. No third-party dependencies or infrastructure changes required.
4. Best Practices & Pitfalls to Avoid
| Do This |  Avoid This |
|---|---|
Store raw values server-side; mask only in the browser | Store only masked values or hash inputs irreversibly |
Keep Odoo’s native audit trail fully intact | Override, filter, or fragment signing logs |
Require explicit consent for any masking behavior | Assume masking implies implicit approval |
Render full values in the final executed PDF (default) | Mask values in the final contract without legal validation |
Use Odoo ACLs/record rules to restrict backend access | Rely on UI masking as a security control |
When to Build vs. When to Rethink
- Build it if: You need masked input for user comfort, internal policy, or regulated data collection, and you can implement explicit consent + raw-value auditing.
- Rethink it if: Your primary goal is “data security.” In that case, focus on Odoo’s access controls, secure sharing tokens, database encryption, and data retention policies instead of UI masking.
🎯 Final Takeaway
Masked fields aren’t missing from Odoo Sign due to a technical limitation—they’re excluded to preserve legal clarity, audit integrity, and defensible compliance under laws like the ESIGN Act. But if your workflow requires them, a custom extension is straightforward to build as long as it layers UX privacy on top of Odoo’s existing compliance framework, not around it.
The right approach: mask on-screen, store raw, log everything, capture consent, and default to transparency in the final document.