Skip to content
Back to catalog
ModuleAdministrationNew

User Profiles

Permissions defined by role, not by person

Create role profiles with their permission list and apply them to the right users. Onboarding someone stops being a memory exercise about which boxes to tick and becomes picking their role.

Compatibility
Odoo 19Odoo 18Odoo 17

How you get it

Every development works in all three Odoo environments. The only thing that changes is how we deliver it.

Nothing to install

Odoo Online (SaaS)

You do not need the ability to install modules. A Millora consultant comes in with temporary access that you authorize and implements it with Odoo Studio. When they are done, you revoke the access.

Install it today

Odoo.sh or your own server

You receive the module and the installation guide by email as soon as payment clears. Install it yourself, or we install it with you.

Installation · shell
# 1 · copia el módulo a tu addons_path
cp -r millora_perfiles_de_usuario /mnt/extra-addons/

# 2 · reinicia y actualiza la lista de apps
odoo-bin -u all -d tu_base --stop-after-init

# 3 · instala desde Apps
#     busca "User Profiles"

What it solves

The problem

In Odoo, permissions are configured user by user, checkbox by checkbox.

With five people that holds. With fifty, and with turnover, it becomes something else: every hire is an exercise in remembering what the last one got, and nobody is confident two people in the same role have the same access. Usually they don't.

The problem isn't how long it takes. It's that permissions stop being a policy and become an accumulation of one-off decisions. Someone who changed departments a year ago still holds the access of both roles, and nobody knows until something happens.

How it works

From the Profiles menu you create one profile per role — "Accounting", "Warehouse", "Forklift operator" — and define its list of Odoo permissions and groups. Once.

From the profile's form you add the users who hold that role. On Update, the system strips all of that person's current permissions and leaves only the profile's. That full replacement is what solves the underlying problem: it doesn't accumulate, it substitutes.

If somebody changes roles, you assign their new profile and their access instantly matches the new role, carrying nothing over from the old one.

And profiles can be duplicated, so building "Junior accounting" from "Accounting" is a copy and two removals.

What's included

Implementation covers defining up to ten profiles together with you, and training the team that will maintain them.

What it does not do

It does not lock the system down. An administrator can still edit permissions user by user after a profile is applied. Profiles organise the policy, they don't enforce it — and if nobody respects the process, the database drifts again.

It does not touch record rules. It works with Odoo groups. The rules deciding which records each person sees within a group are still configured separately.

And worth keeping in mind: Update wipes what was there. If someone had a special permission granted by hand, it is lost when the profile is applied. That is exactly the point, but you should know it.

What changes

Onboarding goes from a configuration to a choice: their role. And the audit question "who can see this?" gets answered by looking at profiles, of which there are ten, instead of users, of which there are fifty.

It is the difference between having an access policy and believing you have one.

What's included

  • Creates role profiles, each with its own list of Odoo permissions and groups
  • Applies a profile to several users from the profile's own form
  • Fully replaces a user's access on update, without accumulating the previous set
  • Changes someone's role by reassigning a profile, carrying nothing over from the old one
  • Duplicates an existing profile to start from it and adjust
  • Concentrates access policy in its own menu instead of spreading it across users

Requirements

  • A clear role structure before kickoff: profiles are defined on top of it
  • Agreed wording for role names, so the menu reads at a glance
  • The applications whose permissions will form part of the profiles, installed beforehand
  • An administrator who upholds the process: the module organises access, it doesn't stop anyone editing it by hand