Portal Access

核心功能

Dedicated access-grant model on `res.partner` recording actor, timestamp, reason code, scope, and optional expiry for every grant and revoke

Live computed `current_access_state` field via `@api.depends` so contacts show their true portal status without inspecting group membership

Bulk grant and revoke server actions runnable over multi-selected contacts from the list view

`ir.cron` scheduled job that auto-expires time-boxed access grants (temporary vendors, seasonal customers, trial users)

Immutable audit log line written on every access change, with no in-place editing of history

QWeb-printable access audit report listing all grants, revokes, and expiries over a chosen date range

`ir.model.access.csv` plus `ir.rule` record rules scoping each portal user to their own partner's documents

Multi-company record rules that prevent a portal contact from seeing another company's records

Dedicated security group separating who can request access from who can approve or override it

Optional approval workflow: staff raise an access request, a manager confirms before the portal login is enabled

Automated actions to email the account manager on revoke or fire a webhook via the XML-RPC/JSON-RPC API

Reason-code taxonomy (configurable) so every revoke is categorized for compliance reporting

Reactivation flow that re-grants a previously revoked contact while preserving the full prior history

Views built in XML/OWL that fit your existing contact form without replacing standard Odoo screens

按需定制，全程代劳

无需自行搭建——由 ECOSIRE 构建、安装并提供支持的可用应用。

您下单

以一次性构建价格开始。我们在启动时与您共同确定范围。

我们构建与安装

ECOSIRE 在您的 Odoo 上构建、配置并安装。

上线 + 支持

约 2–4 周内上线，并提供上线后的支持期。

关于此产品

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 2-4 weeks from confirmed scope. Pricing starts from $249 (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.

你得到什么

Installable, version-matched Odoo module source for your edition (17.0, 18.0, or 19.0)

Installation and configuration on your environment, including security group and record-rule setup

Technical documentation: data model, record rules, cron behavior, and RPC integration points

End-user guide plus a live training session for the staff who grant and approve access

Post-go-live support window for defect fixes and questions

UAT on a staging instance with your sign-off, plus a documented rollback plan

Git repository handover with full commit history for your version

Configured reason-code taxonomy and access-report templates seeded to your policy

这是给谁的

Operations Manager on Odoo

Runs day-to-day Odoo and is tired of portal access being an untracked pile of manual toggles. Needs bulk actions, expiry, and a single view of who has access and why.

Compliance / Security Lead

Answers to auditors and data-protection rules. Needs an immutable log of every grant and revoke, reason codes, and a printable report proving offboarded customers lost access.

Customer Success / Account Team Lead

Onboards and offboards portal customers constantly. Needs a request-and-approve flow so front-line staff can act without holding admin rights, and notifications when access changes.

Multi-Company Finance Director

Operates several companies in one Odoo database. Needs airtight record rules so a portal contact in one company can never see another company's documents.

Portal Access 如何比较

标准	伊科西尔	定制建造	竞争对手
Central access register	Single governed view of every grant with state, reason, and expiry	Whatever you choose to build and maintain yourself	Varies; often a partial list with no reason or expiry
Audit trail	Immutable log line per change plus printable QWeb report	Possible but you design and test the logging	Frequently limited to basic tracking
Bulk grant / revoke	Multi-select server actions over contacts	Build the wizard and actions yourself	Sometimes available, scope differs
Auto-expiry	`ir.cron` job expires time-boxed access automatically	You write and schedule the cron	Rarely included
Multi-company isolation	Record rules prevent cross-company document access	You author and verify the rules	Depends on the module; often untested for this
Approval workflow	Request-and-approve with a dedicated security group	Built to your spec at full dev cost	Uncommon in generic modules
Fit to your policy	Reason codes and rules built around your process	Fully bespoke, highest effort and cost	Generic assumptions you adapt to
Support and handover	Training, support window, and full git repo handover	Depends on who built it staying available	Vendor support terms vary widely

关于Portal Access的常见问题

How long does delivery take?

This is a build-to-order capability, not an off-the-shelf download. Typical delivery is 2-4 weeks from confirmed scope. The clock starts once we have finished the scoping call and agreed your access rules, approval chain, and Odoo version in writing.

How does pricing and scoping work?

Pricing starts from $249, which is indicative for a single-company base scope. After a short scoping call we send a fixed written quote. Drivers that raise the quote include multi-company record-rule depth, approval-workflow complexity, custom reason-code logic, and integrations with external systems via the RPC API.

Which Odoo versions and editions do you support?

We build against Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. We match your exact version at build time and avoid Enterprise-only dependencies unless you already run Enterprise. Tell us your version on the scoping call and we target it precisely.

What about support and updates after go-live?

Every build includes a post-go-live support window for defect fixes and questions. You receive the full git repository, so your own team can maintain it. Version upgrades (for example moving from 17.0 to 18.0) are scoped as a separate engagement since Odoo API changes between majors can require rework.

Will this break standard Odoo portal behavior?

No. We extend `res.partner` and the portal flow rather than replacing core screens, and we layer access control through `ir.model.access.csv` and `ir.rule` record rules. Standard portal login, document sharing, and the customer-facing portal continue to work as Odoo intends.

Can access changes sync to our other systems?

Yes. We can wire automated actions to notify account managers or fire a webhook, and expose grant/revoke events over the XML-RPC/JSON-RPC API so your CRM, helpdesk, or provisioning tools stay in sync. The specific integrations are scoped on the call and reflected in the quote.

How do you make sure it works before it hits production?

We deliver first to a UAT staging instance where your team runs acceptance tests against real access scenarios. Only after your sign-off do we deploy to production, and we always ship with a documented rollback plan so a bad deploy can be reversed cleanly.