starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Introduce a standardized framework for user preferences #5620

New Issue
Closed
opened 2025-12-29 19:30:13 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:30:13 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Nov 5, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0.9

Feature type

Change to existing functionality

Proposed functionality

Introduce a new Python class for representing individual user preferences. This would supplant the current user preferences structure, which is limited in function and offers no real validation mechanism. Currently, only the following preferences are manageable:

  • UI color preference (light/dark)
  • Page length
  • Table columns (per table)

This would likely follow the pattern introduced by the ConfigParam class in v3.1, with each instance declaring a name, default value, and acceptable choices/validation rules.

Use case

This would enable more robust validation around user preferences, and allow more dynamic rendering of the user preferences form. It would also enable us to expose more default values as user-configurable preferences. (See #7702 as an example.)

Database changes

This likely won't require any database changes, as we'll be able to continue using the UserConfig model to store saved user preferences.

External dependencies

No response

Originally created by @jeremystretch on GitHub (Nov 5, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0.9 ### Feature type Change to existing functionality ### Proposed functionality Introduce a new Python class for representing individual user preferences. This would supplant the current user preferences structure, which is limited in function and offers no real validation mechanism. Currently, only the following preferences are manageable: - UI color preference (light/dark) - Page length - Table columns (per table) This would likely follow the pattern introduced by the ConfigParam class in v3.1, with each instance declaring a name, default value, and acceptable choices/validation rules. ### Use case This would enable more robust validation around user preferences, and allow more dynamic rendering of the user preferences form. It would also enable us to expose more default values as user-configurable preferences. (See #7702 as an example.) ### Database changes This likely won't require any database changes, as we'll be able to continue using the UserConfig model to store saved user preferences. ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:30:13 +01:00
adam closed this issue 2025-12-29 19:30:13 +01:00
adam commented 2025-12-29 19:30:14 +01:00
Author
Owner
Copy Link

@bistraque commented on GitHub (Nov 12, 2021):

An open question regarding this new user preference framework: could this include some sort of "default" user preference acting as system-wide preference ? this would cover a use case where choices of relevant columns in a table don't match current defaults (in our case no need for interfaces LAG and MTU columns but tags definitely needed).

Regarding design, I would see this as an option for super-users to tick if they wish to force their customized element to be applied globally. For normal users, this should be transparent, i.e. global settings apply iff user settings are undefined.

@bistraque commented on GitHub (Nov 12, 2021): An open question regarding this new user preference framework: could this include some sort of "default" user preference acting as system-wide preference ? this would cover a use case where choices of relevant columns in a table don't match current defaults (in our case no need for interfaces LAG and MTU columns but tags definitely needed). Regarding design, I would see this as an option for super-users to tick if they wish to force their customized element to be applied globally. For normal users, this should be transparent, i.e. global settings apply iff user settings are undefined.
adam commented 2025-12-29 19:30:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 22, 2021):

An open question regarding this new user preference framework: could this include some sort of "default" user preference acting as system-wide preference ?

I plan to support this by exposing a new dynamic configuration parameter named DEFAULT_USER_PREFERENCES. This can be set to a JSON mapping of available preferences to their values. So for example, if you wanted to set the default columns of the sites table for new users, you would do:

DEFAULT_USER_PREFERENCES = {
    "tables": {
        "SiteTable": {
            "columns": ["name", "status", "facility"]
        }
    }
}

Then when a new user is created, these preferences will be set automatically. It probably needs a bit of tweaking still, but that's the general idea.

@jeremystretch commented on GitHub (Dec 22, 2021): > An open question regarding this new user preference framework: could this include some sort of "default" user preference acting as system-wide preference ? I plan to support this by exposing a new dynamic configuration parameter named `DEFAULT_USER_PREFERENCES`. This can be set to a JSON mapping of available preferences to their values. So for example, if you wanted to set the default columns of the sites table for new users, you would do: ``` DEFAULT_USER_PREFERENCES = { "tables": { "SiteTable": { "columns": ["name", "status", "facility"] } } } ``` Then when a new user is created, these preferences will be set automatically. It probably needs a bit of tweaking still, but that's the general idea.
adam commented 2025-12-29 19:30:14 +01:00
Author
Owner
Copy Link

@bistraque commented on GitHub (Dec 22, 2021):

A configuration parameter is perfectly fine, as this is not something that needs frequent modification. I would expect this config to be applicable to all users, not only new users (unless the user has a custom configuration for a given table). Looks like a json merge of user prefs and default prefs similar to how config contexts work...

@bistraque commented on GitHub (Dec 22, 2021): A configuration parameter is perfectly fine, as this is not something that needs frequent modification. I would expect this config to be applicable to all users, not only new users (unless the user has a custom configuration for a given table). Looks like a json merge of user prefs and default prefs similar to how config contexts work...
adam commented 2025-12-29 19:30:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 22, 2021):

This will only apply to new users. Once a user has modified their preferences, the new preferences will apply.

Sorry I think I misunderstood your comment above. We can reference DEFAULT_USER_PREFERENCES for a default value in cases where a user has not chosen a specific preference. (However any defined preferences will override these defaults.)

@jeremystretch commented on GitHub (Dec 22, 2021): ~This will only apply to new users. Once a user has modified their preferences, the new preferences will apply.~ Sorry I think I misunderstood your comment above. We can reference `DEFAULT_USER_PREFERENCES` for a default value in cases where a user has not chosen a specific preference. (However any defined preferences will override these defaults.)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5620
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?