Platform & Base¶

1. Purpose¶

These are the modules nothing works without. base provides users, companies, contacts, access rights, sequences and the settings framework. web provides the user interface every other module renders inside. mail provides the chatter, activities and outgoing email that every business document depends on for its audit trail and its notifications.

No client ever asks for these modules. Every client depends on all of them, and most "the system doesn't work" reports trace to something configured here — a mail server, a user's groups, a company setting.

2. Features¶

`base`¶

Users and their access groups
Companies, including multi-company structures
Contacts — customers, vendors, and their addresses and contact people
Access rights: groups, model permissions and record rules
Document sequences and numbering
Currencies and exchange rates
Languages and translations
Scheduled actions (cron) and automated actions
Technical settings and the module list

`web`¶

The web client every app runs in — list, form, kanban, pivot and graph views
Search, filtering and grouping
The assets pipeline that bundles JavaScript and CSS

`mail`¶

Chatter on business documents — the message and change history
Activities: scheduled to-dos on records, assigned to users
Followers and subscription-based notification
Outgoing and incoming mail servers, aliases
Email templates
Internal discussion channels

3. Where to find it¶

Menu: Settings → Users & Companies / Technical / General Settings; Contacts; Discuss
Technical names: base, web, mail, mail_bot, contacts
Tier: Odoo core (Community Edition)
Available in: Odoo 16, 17 and 18 — base and web are always present; mail is required by most of our modules

4. Modules used¶

Module	Tier	Why it is needed
`base`	Odoo core	Users, companies, contacts, access rights, sequences, cron
`web`	Odoo core	The user interface and asset pipeline
`mail`	Odoo core	Chatter, activities, email templates, outgoing mail
`mail_bot`	Odoo core	The OdooBot assistant — pulled in by `mtewele_web_theme`
`contacts`	Odoo core	The Contacts app UI — pulled in by `thalia_invoice_reminders`

NestERP custom modules that build on the platform¶

Module	Odoo version	What it adds
`nesterp_branding`	17	NestERP branding across the web client
`mtewele_web_theme`	17	Client-specific UI theming
`mtewele_report_theme`	17	Client-specific report layouts
`thalia_invoice_reminders`	17	Uses `mail` templates and cron for tiered escalation
`payroll_custom_module`	17 · 18	Uses `mail` templates for payroll notifications
Every dashboard module	16 · 17 · 18	Built as OWL components on `web`

5. Configuration¶

Create the company — Settings → Users & Companies → Companies. Name, logo, address, country, currency, and tax identifiers. The country drives tax and localisation defaults, so set it before anything financial.
Set the company currency. Changing it after transactions exist is not a supported operation.
Configure the outgoing mail server — Settings → Technical → Outgoing Mail Servers, then Test Connection. Nothing that sends email works until this passes, and several NestERP modules depend on it.
Set the web base URL — Settings → Technical → System Parameters, web.base.url. Links in outgoing email point at whatever is here; a wrong value sends clients to localhost.
Create users and assign their groups. Start from the narrowest set of groups that lets them work.
Review document sequences — Settings → Technical → Sequences. Journal and picking sequences are legal or operational numbering; agree the format with the client early.
Configure languages if the client needs anything besides English.
Set up currencies and rate updates if the client transacts in more than one.
Review scheduled actions — Settings → Technical → Scheduled Actions. Our reminder and reconciliation modules run on cron; a disabled cron makes them look broken.
Apply branding — nesterp_branding or a client theme.

Configuration traps

web.base.url is silently wrong on every fresh deployment until set. Email links, portal invitations and report links all use it.
The outgoing mail server is the single most common cause of "the feature doesn't work" for anything notification-driven. Test it before blaming the module.
Company country cannot be casually changed — tax and localisation defaults derive from it.
Multi-company visibility is driven by the user's allowed companies, not only by their groups. A user seeing "missing" records is usually in the wrong company context.
Asset cache. After any module deploy touching JavaScript or views, the browser serves the old bundle. Hard-refresh, or load /odoo?debug=assets. We have twice diagnosed a "bug" that was a stale asset bundle — once on the Thalia clients instance, where a hard refresh was the entire fix.
Deactivating a user does not free their access to documents they created; archive rather than delete, and reassign ownership deliberately.

6. How it's used¶

Platform modules are used by administrators, not by end users in a daily workflow.

Adding a user¶

System Administrator — Settings → Users & Companies → Users → New.
Sets the login email, the allowed companies, and the access groups per app.
Sends the invitation; the user sets their own password.
HR — links the user to an employee record where payroll or HR applies.

Investigating a document's history¶

Any user — opens the record and reads the chatter: who changed what, when, and any messages exchanged.
Administrator — for deeper history, Settings → Technical → Audit / logs where enabled.

Scheduling a follow-up¶

Any user — uses Activities on the record to assign a dated to-do to themselves or a colleague.

Screenshots needed

Save to docs/assets/platform/: user form showing access-rights tabs · company settings · outgoing mail server with a successful test · scheduled actions list · chatter with activities on a document · sequences configuration.

7. Access rights¶

Group	Can do
Internal User	The baseline for any employee using the system
Portal	External access — customers seeing their own documents only
Administration / Settings	Full configuration: users, companies, groups, technical settings
Administration / Access Rights	Manage groups and permissions

Settings access is effectively root

A user with Administration / Settings can grant themselves any right, read any record, and change any configuration. It is not an HR-level permission and should be held by as few people as the client can tolerate.

8. Version differences (16 / 17 / 18)¶

Odoo 16Odoo 17Odoo 18

Web client served under /web.
Views use attrs and states for conditional field behaviour.

attrs and states removed. Conditional behaviour moves to direct invisible, readonly and required attributes with Python expressions. This is the highest-impact framework change for our modules across the whole 16 → 17 upgrade.
Refreshed web client interface.

<tree> view elements superseded by <list>.
Mail-template rendering is stricter — a template referencing a field that does not resolve raises instead of rendering empty. This bit the payroll module during its v18 upgrade, and it affects anything using mail templates.
editable="0" required where an empty attribute previously sufficed.
The /odoo URL scheme replaces /web as the web client entry point.

9. Known limitations¶

No Odoo Studio. Enterprise. All customisation is code, which is why the module list is as long as it is.
No official mobile app. Enterprise. Community is browser-only, though responsive.
No Odoo Sign, no document OCR, no VoIP. All Enterprise.
Audit logging is thin. Chatter records changes on tracked fields only; there is no comprehensive audit trail across all models in Community.
No two-factor authentication in older Community releases — confirm availability on the deployed version rather than assuming it.
Incoming mail (fetchmail) is fragile and needs monitoring; it is a common silent failure.

Needs verification on the Thalia live instance

web.base.url value, and whether it matches the live domain
Outgoing mail server configuration, and whether the test passes
Whether incoming mail / aliases are configured
How many companies exist, and how users are scoped across them
Which users hold Administration / Settings
Which scheduled actions are active, and whether any are disabled
Whether two-factor authentication is available and enabled
Which branding module is installed