2.1 Tile Grid

The centre of the home page is a tile grid. Each published HR document appears as a card showing an icon and a label. Click any tile to open that document's list page immediately. The tiles are ordered by the Sequence value set in the document configuration — lower numbers appear first, reading left-to-right and top-to-bottom.

2.2 Employee Profile Card

Near the top of the home page a profile card shows the employee's name, job title, and department. This confirms which employee record is active for the current session — useful if a manager oversees multiple employees and switches between accounts.

2.3 Bottom Navigation Bar

On mobile screens a fixed navigation bar appears along the bottom edge of the display, giving one-tap access to key pages without scrolling back to the home tile grid. The tiles shown in the bar are controlled by the administrator through the Show in Bottom Nav toggle on each document configuration.

5.1 Creating a New Document

Follow these steps to add a new section to the portal:

1. Go to Employees → Employee Portal → Documents.
2. Click New.
3. Fill in the Basic Settings (see section 5.2).
4. Set the Data Source (see section 5.3).
5. Configure Display and Pagination (see section 5.4).
6. Set the Action Controls (see section 5.5).
7. Add Whitelisted Fields (see section 5.6) or enable Use Backend Views (see section 5.7). These two approaches are mutually exclusive — use one or the other.
8. Optionally add custom HTML to the Page Body or Detail Body (see section 5.8).
9. Set Is Published to on when you are ready for employees to see the tile.
10. Click Save to apply all changes.

5.2 Basic Settings

• Name (name) — the label shown on the tile and at the top of the document's portal page. For example: My Contracts or Expense Reports. Keep it short and descriptive so employees recognise it immediately.
• Technical Name (technical_name) — sets the URL path segment for the portal page. Must be unique across all documents and must not contain spaces or special characters. For example, contracts produces the URL /employee/contracts.
• Icon (icon) — a Font Awesome 4 class name displayed on the home tile. For example, fa-file-text for a document icon or fa-money for a currency symbol. Browse the full list at fontawesome.com/v4.
• Sequence (sequence) — controls the display order of tiles on the home page. Lower numbers appear first (left-to-right, top-to-bottom). Set two documents to the same sequence number to let Odoo decide their relative order by ID.
• Is Published (is_published) — toggle on to make the tile visible to employees, or off to hide it without deleting any configuration. Use this to stage a new document before employees can see it.
• Show in Bottom Nav (show_in_bottom_nav) — when enabled, this document also appears as a one-tap shortcut in the fixed bottom navigation bar on mobile screens. Reserve this for the most frequently used documents to avoid overcrowding the bar.

5.3 Data Source

• Model (model_id) — the Odoo model this document reads records from. For example, hr.contract for employment contracts, hr.expense for expenses, or any other model your portal users should access. Type part of the model's technical name or display name in the search box to find it.

• Employee Scope Domain (scope_domain) — a domain expression that restricts records to the current logged-in employee. This is the most important security field: it ensures each employee sees only their own data. Several variables are available inside this domain at runtime:

  Variable	Value
  uid	The current user's numeric ID (res.users.id)
  user	The current res.users record
  employee	The current user's linked hr.employee record
  today	Today's date as a Python date object
  datetime	Python's datetime module (for date arithmetic)

  Example: [('employee_id', '=', employee.id)]

• Additional Filter Domain (domain) — a static filter applied on top of the scope domain. Use this for business logic that does not depend on who is logged in. For example: [('state', 'not in', ['cancel'])] hides cancelled records for all employees.

• Editable Domain (editable_domain) — a subset of the visible records that the portal user is allowed to edit. This requires Allow Update to be on. Records that do not match this domain are shown as read-only even when Allow Update is enabled. For example: [('state', '=', 'draft')] allows editing only while a record is in draft.

5.4 Display and Pagination

• Order (order) — the default sort applied to the results table. Use the format field_name asc or field_name desc. For example, date_start desc shows the most recent records first. Leave blank to use the model's default order.
• Default Limit (default_limit) — the number of rows shown per page before pagination is triggered. Defaults to 20. Lower this for models with many columns to keep the page responsive.
• Max Limit (max_limit) — the maximum number of rows a portal user can request per page. Prevents unbounded queries on large datasets and protects server performance.
• Counter Key (counter_key) — an optional field name used to display a badge count on the home tile (for example, the number of pending records). Leave blank if you do not want a counter badge on the tile.

5.5 Action Controls

These three toggles control what employees can do with records. All three are off by default — enable only what you explicitly want to allow.

• Allow Create (allow_create) — shows a + New button on the list page. Employees can open a creation form and submit a new record directly from the portal. When Use Backend Views is on, you must also configure the Auto-fill on Create table (see section 5.7).
• Allow Update (allow_update) — makes records editable. An employee can click a row to open an edit form and save changes. The Editable Domain further restricts which records can be edited. For example, you might allow updating only draft records.
• Allow Delete (allow_delete) — shows a Delete button on the record detail page. An employee can permanently remove a record. Use with caution — deleted records cannot be recovered from the portal.

5.6 Whitelisted Fields

The Whitelisted Fields tab (field_line_ids) controls exactly which fields are visible and where they appear. Add one line per field you want to expose. Each line has the following role toggles:

• Column (role_column) — the field appears as a column header and value in the list table.
• Default Column (role_default_column) — the column is visible by default without the employee needing to enable it. If this is unchecked, the field is available but hidden until the employee switches it on from the column picker.
• Show on Detail (role_detail) — the field appears on the record detail page when an employee clicks a row.
• Create Form (role_create) — the field appears in the form shown when an employee clicks + New. Enable this for every field an employee needs to fill when creating a record.
• Update Form (role_update) — the field appears in the form when an employee edits a record. You can expose different fields for create and update if needed.
• Searchable (role_search) — the field is included in the query run by the search box. Works best on text fields such as name or description.
• Status Filter (role_status) — the field's distinct values populate the Status dropdown filter on the list page. Use this on a selection or many2one field that represents a record's state (for example, the state field).
• Date Filter (role_date) — this field drives the From and To date range pickers on the list page. Only one field per document should have this role enabled.

Example for a contract document (hr.contract):

5.7 Use Backend Views

When Use Backend Views (use_backend_views) is enabled, the document page embeds the real Odoo web client inside the portal shell instead of the lightweight field table. Employees see native Odoo views — complete with print to PDF, the attachments panel, the chatter thread, group-by options, and custom filters — without holding an internal user licence.

Backend View Types (backend_view_types)

A comma-separated list of view types to offer on the document page. Supported values are:

• list — a sortable, filterable table of all records.
• form — the full Odoo form for a single record, including all tabs and related sub-lists. Form is always included regardless of what you enter here.
• kanban — a card-based view grouped by stage or another field, ideal for workflow visualisation.
• calendar — a monthly or weekly calendar view, useful for time-based records such as attendance or leave.

Example: list,form for a simple read-only view, or list,form,kanban,calendar to give employees the full Odoo experience.

What happens when you save with Use Backend Views on

When you save the document record with Use Backend Views enabled, the system automatically creates the following Odoo objects for the selected model:

• ir.ui.view records for each of the selected view types (list, kanban, calendar, search, and always form).
• An ir.actions.act_window that wires all these views together as a single action.

You do not need to create these views manually — the system generates them from the document's configuration.

Auto-security

When backend views are generated, the system also automatically creates:

• An ir.model.access record granting portal users read access to the model.
• A scoped ir.rule that limits portal users to records within the document's scope domain.
• The same pair of access record and rule for every related co-model found in the generated views. For example, if the list view displays a many2one field pointing to res.partner, portal read access is also granted on res.partner automatically.

This auto-security covers the vast majority of models. However, a small set of sensitive models is on a built-in denylist and will never receive auto-generated access rules. hr.contract is one such model. For any denylist model you must add the access rules manually (see sections 6.3 and 6.4 for a concrete example with hr.contract).

Try as Portal User button

The Try as Portal User button simulates a portal user opening the document page from scratch. It catches any AccessError that would occur at runtime, reports which models are missing access rules, and stores the list in the last_simulation_missing_models field on the document. Click this button after setting up a new document to confirm that employees will not encounter a security error when they open the page.

Auto-grant Missing Access button

After running Try as Portal User, if the simulation found models with missing access, an Auto-grant Missing Access button appears. Clicking it automatically adds every missing co-model (that is not on the denylist) to the transitive dependency list and re-syncs all security rules in one step. For denylist models such as hr.contract, the access rules must still be added by hand — the button deliberately skips them.

Auto-fill on Create table

When Allow Create is enabled alongside Use Backend Views, the system detects which fields on the model are required at the database level and presents an Auto-fill on Create table. Each row in the table lets you choose how that required field is populated when a portal user submits a new record:

• current_user — fills the field with the current res.users record.
• current_employee — fills the field with the current user's linked hr.employee record.
• current_partner — fills the field with the current user's res.partner record.
• current_company — fills the field with the current user's active company.
• skip — leaves the field blank. Use only if the field is not truly required or is computed by another mechanism.
• add_to_form — adds the field to the creation form so the employee fills it in themselves. Use this for fields where the employee must make a choice, such as a project or category.

5.8 Page Body and Detail Body

Each document page has two HTML regions — one above the document table and one below it — that are fully editable in the Odoo Website Builder. Open the portal page while logged in as an administrator, click Edit in the top bar, and drag any website snippet into either region: text blocks, image galleries, FAQ accordions, countdown timers, call-to-action banners, pricing tables, carousels — every snippet in the Website Builder panel works here.

• The body field stores the HTML for the region above and below the table on the list page.
• The detail_body field stores the HTML displayed on the record detail page, above and below the field values.

Use these regions to publish policy notices, HR announcements, or helpful links directly on the portal page — with no developer involvement needed.

6.1 Create the Document Record

1. Go to Employees → Employee Portal → Documents and click New.

2. Set Name to My Contracts.

3. Set Technical Name to contracts. The portal URL will be /employee/contracts.

4. Set Model to hr.contract (type "contract" in the search box).

5. Set Employee Scope Domain to:

   [('employee_id', '=', employee.id)]
   

   This ensures each employee sees only their own contracts.

6. Set Additional Filter Domain to:

   [('state', 'not in', ['cancel'])]
   

   This hides cancelled contracts from the list.

7. Set Icon to fa-file-text.

8. Set Sequence to 50 (or any number that places the tile where you want it on the home page).

9. Leave Is Published off for now — turn it on after you have verified everything works.

10. Click Save (do not close the record yet — you need to add fields or enable backend views in the next steps).

6.2 Add Whitelisted Fields

On the same document record, open the Whitelisted Fields tab and add the following lines. For each line, select the field from the model's field list and check the indicated roles.

Field: name (Contract Reference)

• Column: on
• Default Column: on
• Show on Detail: on
• Searchable: on

Field: date_start (Start Date)

• Column: on
• Default Column: on
• Show on Detail: on
• Date Filter: on (this drives the From / To date pickers)

Field: date_end (End Date)

• Column: on
• Show on Detail: on

Field: wage (Wage)

• Column: on
• Default Column: on
• Show on Detail: on

Field: state (Status)

• Column: on
• Default Column: on
• Show on Detail: on
• Status Filter: on (this drives the Status dropdown)

Set Order to date_start desc so the most recent contracts appear first.

Click Save.

6.3 (Snippet Table Approach) Add Manual Security

If you are using the standard snippet table (use_backend_views is off), you must manually grant portal users access to hr.contract. The system will NOT do this automatically because hr.contract is on the security denylist.

Step A — Add an ACL entry

In your module's security/ir.model.access.csv, add a line granting portal users read access:

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_hr_contract_portal,hr.contract portal read,hr_contract.model_hr_contract,base.group_portal,1,0,0,0

If you do not have a custom module, you can create this entry via Settings → Technical → Security → Access Rights in developer mode.

Step B — Add a record rule

Portal users must be restricted to their own contracts. In your module's security/ir_rules.xml (or via Settings → Technical → Security → Record Rules), add:

<record id="hr_contract_portal_rule" model="ir.rule">
    <field name="name">HR Contract: portal users see own contracts</field>
    <field name="model_id" ref="hr_contract.model_hr_contract"/>
    <field name="groups" eval="[(4, ref('base.group_portal'))]"/>
    <field name="domain_force">
        [('employee_id.user_id', '=', user.id)]
    </field>
    <field name="perm_read" eval="True"/>
    <field name="perm_write" eval="False"/>
    <field name="perm_create" eval="False"/>
    <field name="perm_unlink" eval="False"/>
</record>

This rule matches the scope domain you set in step 6.1 — each portal user sees only the contracts belonging to their linked employee.

After saving, set Is Published to on and test by opening the portal page as an employee.

6.4 (Backend Views Approach) Enable Backend Views

If you prefer the full Odoo interface (chatter, attachments, print, and so on) instead of the snippet table, follow these steps instead of section 6.3.

1. On the document record you created in section 6.1, check Use Backend Views.
2. Set Backend View Types to list,form.
3. Click Save. The system will automatically generate ir.ui.view records and an ir.actions.act_window for hr.contract.
4. Click Try as Portal User. The system simulates a portal login and reports any models that are missing access rules. Because hr.contract is on the security denylist, it will appear in the missing-access report.
5. For any models listed in the report that are not hr.contract, click Auto-grant Missing Access to let the system add them automatically.
6. For hr.contract itself, add the ACL entry and record rule manually as described in section 6.3 steps A and B. This is intentional: hr.contract contains wage and salary data, and the system deliberately requires a human decision before granting portal access to it.
7. Click Try as Portal User again to confirm there are no remaining errors.
8. If Allow Create is on, review the Auto-fill on Create table. A common setup for hr.contract is:
   • employee_id → current_employee
   • company_id → current_company
   • Any other required fields → add_to_form (so the employee fills them in) or skip (if they have a sensible default).
9. Set Is Published to on.

6.5 Test the Result

1. Open a browser in a private or incognito window.
2. Log in as a portal user who has a linked employee record with at least one active contract.
3. Navigate to /employee/home. You should see the My Contracts tile.
4. Click the tile. The contract list should show only the contracts belonging to that employee, sorted by start date descending, with cancelled contracts excluded.
5. Click a row to open the contract detail. Verify the fields you configured in section 6.2 are all visible.
6. Log in as a second portal user (a different employee) and confirm they see only their own contracts — not the first employee's.

If any step fails, consult section 8, Troubleshooting.

7.1 Embedded Backend Views

When Use Backend Views is enabled, the portal page embeds the full Odoo web client inside the portal shell. Employees see native list, form, kanban, or calendar views — complete with print to PDF, the attachments panel, the chatter thread, group-by options, and custom filters — without holding an internal user licence. The embedded view respects all existing access rules, so portal users can only see and act on their own records.

7.2 Kanban View

The kanban view renders records as cards grouped by stage or another configurable field. This is ideal for workflows where employees need to see at a glance which stage each record is in — for example, expense approval stages or contract status.

7.3 Form View

The form view opens a single record in the full Odoo form interface, including all tabs, related sub-lists, the attachments panel, and the chatter thread. Employees can print a PDF, download attachments, and follow the record's communication history without ever leaving the portal.

7.4 Website Builder Integration

Every portal document page is a standard Odoo website page. Open it while logged in as an administrator, click Edit in the top bar, and drag any snippet above or below the document table: text blocks, image galleries, FAQ accordions, call-to-action banners, and every other snippet in the Website Builder panel. Use these regions to publish HR announcements, policy summaries, or important links — with zero developer involvement.

7.5 Theme Colors

The portal shell — header bar, tile cards, buttons, and navigation — reads CSS variables from the active Odoo website theme. Changing the color preset in Website → Configuration → Themes instantly recolors the entire portal. No custom CSS and no template overrides are needed.