Every growing Odoo deployment eventually hits the same wall: customer portal access becomes a mess of one-off grants. Someone manually flips "Grant portal access" on a contact, a colleague later revokes it and no one records why, an ex-customer keeps signing in to see their old quotations, and a partner contact can view documents that belong to a different company. Odoo core lets you grant portal access per contact, but it gives you no central register, no reason codes, no expiry, no bulk operations, and no audit trail of who changed what and when. When compliance, security, or a customer offboarding question lands on your desk, you are left clicking through contacts one by one.

We build a Portal Access management layer that turns this scattered activity into a governed, auditable workflow inside your own Odoo. Technically, we extend res.partner and the portal wizard flow with a dedicated access-request/grant model (models.Model) that records the actor, timestamp, reason, scope, and optional expiry date for every grant and revoke. A @api.depends compute keeps a live "current access state" field per contact so your team sees the truth at a glance instead of inferring it from group membership. Bulk grant/revoke actions run over selected contacts from the list view, and an ir.cron scheduled job auto-expires time-boxed access so temporary vendor or seasonal-customer logins do not linger. Every change writes an immutable log line, exposed in a QWeb-printable access report for auditors.

Access is enforced where it matters, not just in the UI. We author ir.model.access.csv entries plus ir.rule record rules so that a portal user only ever sees documents scoped to their own partner and, where you have multiple companies, only their company's records — closing the cross-company leakage that trips up naive setups. Administrative actions (grant, revoke, extend, override) are gated behind a dedicated security group so front-line staff can request access while only authorized managers approve it. Optional automated actions can notify an account manager on revoke, or fire a webhook to a downstream system via the XML-RPC/JSON-RPC API so your CRM, helpdesk, or provisioning tools stay in sync. The module respects Community vs Enterprise boundaries — we build to whichever edition you run and never assume an Enterprise-only dependency unless you have it.

Because this is build-to-order, nothing ships until we have agreed your exact access rules. We start with a short scoping call to map your portal document types, company structure, reason codes, and approval chain, then build against a version-matched checkout of your Odoo (17.0, 18.0, or 19.0). You get the work on a UAT staging instance first, run your own acceptance tests, and we deploy to production with a rollback plan. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company record-rule depth, approval-workflow complexity, and integrations with external systems via the RPC API increase the quoted scope.