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

Confirmation of changes #5458

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

Originally created by @SerhiiZahuba on GitHub (Oct 2, 2021).

NetBox version

v3.0.4

Feature type

New functionality

Proposed functionality

I propose a new functionality, namely confirmation of changes or changes. For example, 5 people work in the infrastructure department (4 juniors and 1 of their leader), if one of the junior makes a change, then his manager must confirm this change. For example, I added new equipment to netbox, it is not immediately displayed in the system, but goes into an application that my manager must confirm.

Use case

Thus, we will be able to check what each employee contributes and whether he did it correctly.

Database changes

No response

External dependencies

No response

Originally created by @SerhiiZahuba on GitHub (Oct 2, 2021). ### NetBox version v3.0.4 ### Feature type New functionality ### Proposed functionality I propose a new functionality, namely confirmation of changes or changes. For example, 5 people work in the infrastructure department (4 juniors and 1 of their leader), if one of the junior makes a change, then his manager must confirm this change. For example, I added new equipment to netbox, it is not immediately displayed in the system, but goes into an application that my manager must confirm. ### Use case Thus, we will be able to check what each employee contributes and whether he did it correctly. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:28:18 +01:00
adam closed this issue 2025-12-29 19:28:19 +01:00
adam commented 2025-12-29 19:28:19 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 4, 2021):

This sort of thing has come up in conversation a few times. It definitely sound like it'd be a cool feature, though we'd need to iron out the implementation.

Presumably, we could save the "proposed" new state of an object in a dedicated ProposedChange model (or something to that effect). A user with the proper permission could then either apply the change, updating the object with the new attributes, or reject it. I would assume that any changes to an object applied in the interim would invalidate the proposed change, to avoid potential issues with data integrity.

How to best handle permissions requires some more though, as this introduces a new concept: We need a way to indicate that a user is allowed to propose creating/modifying a model, but not to actually apply the changes. Or, alternatively, leave the existing permissions unchanged and just offer the option of proposing a change instead of applying it immediately.

@jeremystretch commented on GitHub (Oct 4, 2021): This sort of thing has come up in conversation a few times. It definitely sound like it'd be a cool feature, though we'd need to iron out the implementation. Presumably, we could save the "proposed" new state of an object in a dedicated ProposedChange model (or something to that effect). A user with the proper permission could then either apply the change, updating the object with the new attributes, or reject it. I would assume that any changes to an object applied in the interim would invalidate the proposed change, to avoid potential issues with data integrity. How to best handle permissions requires some more though, as this introduces a new concept: We need a way to indicate that a user is allowed to _propose_ creating/modifying a model, but not to actually apply the changes. Or, alternatively, leave the existing permissions unchanged and just offer the option of proposing a change instead of applying it immediately.
adam commented 2025-12-29 19:28:19 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (Oct 4, 2021):

In my world, this is getting into the world of ITIL and change management where one should be careful of not getting into a rabbit hole. And this hole is deep...trust me...

In my view, the whole approval process should have been done before the object is even placed in netbox, and to be honest, the definition of permissions in Netbox should be that if you have a permission to add an object to Netbox, you have already been approved.

One way would be to add a status of an object to "Pending" with a permission for the "minions" to only be able to add objects with that status, and by integrations from whatever system to look at this (we do something like this with Remedy).

My point here is not to limit features, but starting to go in this direction will start an journey to process management that will suck the life out of everything..... been there..... never got the t-shirt though:-)

@ziggekatten commented on GitHub (Oct 4, 2021): In my world, this is getting into the world of ITIL and change management where one should be careful of not getting into a rabbit hole. And this hole is deep...trust me... In my view, the whole approval process should have been done before the object is even placed in netbox, and to be honest, the definition of permissions in Netbox should be that if you have a permission to add an object to Netbox, you have already been approved. One way would be to add a status of an object to "Pending" with a permission for the "minions" to only be able to add objects with that status, and by integrations from whatever system to look at this (we do something like this with Remedy). My point here is not to limit features, but starting to go in this direction will start an journey to process management that will suck the life out of everything..... been there..... never got the t-shirt though:-)
adam commented 2025-12-29 19:28:19 +01:00
Author
Owner
Copy Link

@rfdrake commented on GitHub (Nov 3, 2021):

I have an idea for this, but I'm not sure if it's going to be easy to write. I saw an open issue about exporting and importing more object types as YAML and it got me thinking about something like this:

It would be very nice if we could dump an entire site (or tenant, or any other aggregate object) with subobjects as JSON or YAML. At that point it would be a little easier to export and import data from different netbox instances. Then a designer might have their own instance where they do all the planning for a new site. It gets reviewed in another instance and once approved it would be uploaded to a master instance.

There is still some question marks, like how do you handle duplicated data on a merge, and what do you do with circuits which leave a site? But those details might be punted for later.

@rfdrake commented on GitHub (Nov 3, 2021): I have an idea for this, but I'm not sure if it's going to be easy to write. I saw an open issue about exporting and importing more object types as YAML and it got me thinking about something like this: It would be very nice if we could dump an entire site (or tenant, or any other aggregate object) with subobjects as JSON or YAML. At that point it would be a little easier to export and import data from different netbox instances. Then a designer might have their own instance where they do all the planning for a new site. It gets reviewed in another instance and once approved it would be uploaded to a master instance. There is still some question marks, like how do you handle duplicated data on a merge, and what do you do with circuits which leave a site? But those details might be punted for later.
adam commented 2025-12-29 19:28:20 +01:00
Author
Owner
Copy Link

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

I think @ziggekatten is right on the money here. While an interesting idea, it's almost certainly not going to be worth the trouble to pursue, at least at this stage in NetBox's development. It might be something to reconsider when/if we amass a larger development team.

@jeremystretch commented on GitHub (Nov 12, 2021): I think @ziggekatten is right on the money here. While an interesting idea, it's almost certainly not going to be worth the trouble to pursue, at least at this stage in NetBox's development. It might be something to reconsider when/if we amass a larger development team.
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 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#5458
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?