Every Odoo session renders a user menu in the top-right corner — the avatar dropdown with Preferences, My Odoo.com Account, Documentation, Support, Shortcuts, the developer-tools toggle, and Log out. For back-office power users that is fine, but for kiosk terminals, shop-floor tablets, warehouse scanners, and locked-down operational roles it is an exposed surface: staff wander into Preferences and change their timezone or language, curious users flip on developer mode and start editing views, or a shared account leaves a Log out link that strands the next person at the login screen. Odoo core gives you no setting to hide or prune this menu — it is rendered by the web client's UserMenu systray component in the web module, so the only "native" levers are heavy-handed: strip permissions until half the UI breaks, or simply tell people not to click it. Neither is a real control.

ECOSIRE builds a made-to-order module that gives you precise, policy-driven control over that top-right menu. Rather than a blunt CSS hide, we extend the web client so the user-menu items are governed by who is logged in. We add configuration — typically boolean and selection fields on res.users and res.groups, and optionally per res.company — that declares which entries (or the entire menu) are suppressed. That policy is exposed to the browser through a lightweight http.Controller (or a value read from ir.config_parameter) so the front end never trusts a hardcoded list. On the client we patch the OWL UserMenu systray component to filter the registry of user-menu items against the policy for the current session.uid, so hidden entries never mount in the DOM instead of being merely visually hidden with display:none — which matters, because a CSS-only approach is trivially bypassed via the browser inspector.

Because the entry points differ across Odoo 17.0, 18.0, and 19.0 — the systray registry keys, the OWL patch surface, and the assets bundle declarations in __manifest__.py all shifted between versions — we target your exact version rather than shipping one brittle build. Access to the configuration screens is protected with ir.model.access.csv and, where you need per-company scoping, ir.rule record rules so only administrators can change the policy. The module ships version-appropriate web.assets_backend entries, an XML/OWL patch, a small Python mixin, and an optional automated action so a newly created user in a designated group inherits the locked-down menu automatically. It works identically on Community and Enterprise; where an Enterprise-only entry (such as an Odoo.com account link) is absent on Community, the policy simply skips it.

Delivery is build-to-order: you request a quotation, we run a short scoping call to confirm which menu entries to hide, for which users or groups, and on which Odoo version and edition, then we build, test on a staging clone of your database, and hand over installable source with documentation. This is not an existing download — it is engineered to your environment, with typical delivery of 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company per-company policies, custom entry-level rules tied to complex group hierarchies, and integration with an existing access-management module increase the quoted scope. You receive a fixed quote after the scoping call.