res_user_group_ids

Access rights in Odoo are a many2many to res.groups, but nobody wants to manage them as a list of group records. This widget turns that relation into the grid administrators actually use: application categories down the page, each with a dropdown choosing the level of access.

It does that by building a form view in the browser at runtime. It reads a structure the server sends alongside the record, view_group_hierarchy, containing the groups, the privileges and the categories, then generates selection and boolean fields for each and renders them through the standard form renderer.

The descriptor declares no options. There is nothing to pass it, because everything it draws comes from that server-sent hierarchy.

This is the screen where somebody decides whether a new starter can see other people's salaries. It is worth understanding that what you are looking at is a presentation of the group membership underneath, not a separate permission model.

Two consequences matter in practice. Anything you set here ends up as plain group membership, so a module that adds groups will change what this screen offers without anyone touching a configuration. And the grid only shows what the server sent: if a group is missing from the hierarchy, it is not visible here even though it may still be applied to the user.

For an audit, read the underlying group membership rather than this screen alone.

The standard use, on the user form:

<field name="group_ids" widget="res_user_group_ids" nolabel="1" colspan="2"/>

And on the groups form, for implied groups:

<field name="implied_ids" widget="res_user_group_ids" nolabel="1" colspan="2"/>

Putting it on any other many2many to res.groups will not work, because the record will not carry view_group_hierarchy.

If you go looking for the Other and Extra Rights sections in your category data, you will not find them. The widget creates both during setup.

Other collects privileges that have no category, so they are not dropped off the screen:

const privilegesWithoutCategory = Object.values(privileges)
    .filter((privilege) => !privilege.category_id)
    .sort((privilege) => privilege.sequence);
if (privilegesWithoutCategory.length) {
    categories.push({ id: "other", name: _t("Other"), ... });
}

Extra Rights collects groups that belong to no privilege at all, and renders each as a checkbox rather than a dropdown:

this.extraCategory = {
    id: "extra",
    name: _t("Extra Rights"),
    privileges: Object.values(groups)
        .filter((group) => !group.privilege_id)
        ...
};

That split is the rule worth remembering. A group attached to a privilege becomes one option in a dropdown, where picking one deselects the others. A group with no privilege becomes an independent checkbox. So whether a permission is exclusive or additive is decided by whether its group has a privilege_id, not by anything on this screen.

If you add custom groups in a module and they show up as loose checkboxes under Extra Rights rather than as levels in your application's dropdown, that is the reason: they have no privilege, so the widget has nowhere else to put them.

No change. Diffing the registration between the 19.0 and 20.0 branches shows no options added or removed and no registration changes, and it is applied in the same three places in the base module.

The component is rewritten internally for OWL 3, as all of Odoo 20's widgets are, but the screen and its behavior are the same.