| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Contacts (contacts)
• Discuss (mail) |
| Lines of code | 195 |
| Technical Name |
no_selection_key_visibility |
| License | OPL-1 |
| Website | https://www.oudayet.com |
| Versions | 16.0 17.0 18.0 19.0 |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Contacts (contacts)
• Discuss (mail) |
| Lines of code | 195 |
| Technical Name |
no_selection_key_visibility |
| License | OPL-1 |
| Website | https://www.oudayet.com |
| Versions | 16.0 17.0 18.0 19.0 |
Selection Key Visibility
Hide or show selection options per field instance, in XML — without touching Python.
Odoo 18 $5 USD Per-View FilteringOne Selection Field, Many Contexts
The same selection field shows up on the main form, the embedded child list, the wizard, and a dozen other views — but you don't always want every value available everywhere.
Without this module
Either you override fields_get() in Python and the change leaks into every other view, or you create a separate selection field with a different name and copy half the model.
With this module
Add a widget option in the XML where you want to filter. The selection field on every other view stays untouched. Zero Python, zero side effects.
Four Things It Does Well
Three widgets, two filter modes, one config option per instance.
The selection_key_visibility widget filters the list of options inside any standard selection dropdown.
The radio_key_visibility widget removes radio buttons from the rendered group, horizontal or vertical.
The statusbar_key_visibility widget hides pipeline stages while always preserving the record's current value.
Blacklist with hide_selection_keys or whitelist with show_selection_keys. Hide takes precedence if both are set.
No Python overrides. No new fields. No DB migrations.
Real-World Scenarios
The res.partner.type field appears in many forms. On a "child contacts" embedded list you want only physical addresses; on the main partner form you want every type. One XML attribute per view, no model changes.
Sales reps see "Draft → Sent → Confirmed". Managers see the full lifecycle including "On Hold" and "Cancelled". Same field, two statusbar widgets, two whitelists.
A multi-tenant deployment wants the language dropdown to show only the languages that tenant supports. Different views inherit different whitelists, the underlying res.lang table stays canonical.
A Studio user (or a custom module) wants three of the seven values from a core Odoo selection field. Add the widget, list the keys, ship. No selection_add, no upgrade headaches.
How It Works
Replace the standard selection, radio, or statusbar widget on the field with our drop-in equivalent.
Add a single options dict to the XML with either hide_selection_keys or show_selection_keys. That's the whole config.
The widget applies the filter at render time, in the browser. The field still talks to the same column, still saves the same value, still respects every other view's options.
Installation
No Python dependencies, no database migration, no configuration.
Step 1
Install from the Apps menuApps menu → remove the Apps filter → search "Selection Key Visibility" → Install.
Step 2
Use the widgetIn any inherited form view, set widget="selection_key_visibility" (or radio / statusbar variant) and pass options="{'hide_selection_keys': [...]}".
Works With Every Selection Field
Anything in Odoo backed by a selection field — core or custom.
Works with module-defined selections and Studio fields.
What This Module Doesn't Do
Honest scope. Here's what's out of reach.
Filtering happens in the browser. A determined user could bypass the UI and write a hidden value via the API. For hard validation, also add a Python constraint.
It filters the existing options. To add a new value to a core selection field, use the standard selection_add mechanism — this module is a complement, not a replacement.
The statusbar widget always shows the record's current stage, even if it's in the hidden list. That's intentional — otherwise the field would render blank. Dropdowns and radios filter strictly.
This is for selection fields only (string-keyed). For relational many2one dropdowns use Odoo's domain mechanism — that's a different problem.
Pure Frontend. Zero Footprint.
No new database fields. No Python overrides on existing models. No selection_add. No upgrade migrations. The module ships three OWL widgets and registers them — that's the entire surface area. Uninstall is just as clean.
FAQ
Hide wins. The widget applies the blacklist first, then the whitelist; the intersection is what renders.
It's silently ignored. No error, no warning — the widget filters by membership, so non-existent keys have no effect.
The XML attribute is just text in the view. It survives every upgrade as long as the underlying field still exists.
No. The widgets register under unique names (selection_key_visibility etc.), so they coexist with the core widgets and any other custom widget you might be using.
Yes — pick the widget in Studio's widget dropdown and add the options in the Widget options field. No code editing needed.
At a Glance
© Naim OUDAYET — oudayet.com — OPL-1 license
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module