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

Add an "owner" field to all primary objects #792

New Issue
Closed
opened 2025-12-29 16:25:52 +01:00 by adam · 5 comments
adam commented 2025-12-29 16:25:52 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Mar 23, 2017).

Issue type: Feature request

Originally proposed by @CassioFabius in #979. This would entail adding a new optional ForeignKey field pointing to the User model. Each primary object type (listed below) could be assigned an owning user. Proposed objects include:

  • Circuits
    • Provider
    • Circuit
  • DCIM
    • Site
    • Rack
    • DeviceType
    • Device
  • IPAM
    • VRF
    • Aggregate
    • Prefix
    • IPAddress
    • VLAN
    • Service
  • Secrets
    • Secret
  • Tenancy
    • Tenant
Originally created by @jeremystretch on GitHub (Mar 23, 2017). ### Issue type: Feature request Originally proposed by @CassioFabius in #979. This would entail adding a new optional `ForeignKey` field pointing to the User model. Each primary object type (listed below) could be assigned an owning user. Proposed objects include: * Circuits * Provider * Circuit * DCIM * Site * Rack * DeviceType * Device * IPAM * VRF * Aggregate * Prefix * IPAddress * VLAN * Service * Secrets * Secret * Tenancy * Tenant
adam added the type: feature label 2025-12-29 16:25:52 +01:00
adam closed this issue 2025-12-29 16:25:52 +01:00
adam commented 2025-12-29 16:25:52 +01:00
Author
Owner
Copy Link

@arbor-bdoyle commented on GitHub (May 2, 2017):

What permissions do you predict being needed to change the Owner field? Our current system has a Reserved For field to track who is using a given test device in the lab, and it changes fairly frequently. We don't have any permissions around changing the field, as it mostly serves to ensure that people don't accidentally clobber boxes that other people are using with automated scripts, or to track down who is currently using a box if you're curious. It would be neat if we could keep this process but also adopt Owner.

@arbor-bdoyle commented on GitHub (May 2, 2017): What permissions do you predict being needed to change the Owner field? Our current system has a Reserved For field to track who is using a given test device in the lab, and it changes fairly frequently. We don't have any permissions around changing the field, as it mostly serves to ensure that people don't accidentally clobber boxes that other people are using with automated scripts, or to track down who is currently using a box if you're curious. It would be neat if we could keep this process but also adopt Owner.
adam commented 2025-12-29 16:25:52 +01:00
Author
Owner
Copy Link

@specialcircumstances commented on GitHub (May 6, 2017):

Would you propose that the object is inherited if not set... Similar to how tenant is inherited for prefixes?

@specialcircumstances commented on GitHub (May 6, 2017): Would you propose that the object is inherited if not set... Similar to how tenant is inherited for prefixes?
adam commented 2025-12-29 16:25:52 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Oct 19, 2017):

This records a single 'owner' against an item. I think it would be useful if:

  • one item can have multiple Users as owners; and/or
  • the owner can be a Group (or Groups)
@candlerb commented on GitHub (Oct 19, 2017): This records a single 'owner' against an item. I think it would be useful if: * one item can have multiple Users as owners; and/or * the owner can be a Group (or Groups)
adam commented 2025-12-29 16:25:53 +01:00
Author
Owner
Copy Link

@MalfuncEddie commented on GitHub (Dec 13, 2019):

Hi,

I suspect this feature originated from itil practices. If so I would replace "owner" with "accountable" and add responsible.

In itil these are not the same.
http://www.itsmprofessor.net/2011/01/accountable-or-responsible.html

PS: I also needed this and solved this by using custom fields (accountable & responsible).

@MalfuncEddie commented on GitHub (Dec 13, 2019): Hi, I suspect this feature originated from itil practices. If so I would replace "owner" with "accountable" and add responsible. In itil these are not the same. http://www.itsmprofessor.net/2011/01/accountable-or-responsible.html PS: I also needed this and solved this by using custom fields (accountable & responsible).
adam commented 2025-12-29 16:25:53 +01:00
Author
Owner
Copy Link

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

With the addition of object-based permissions in v2.9, this doesn't seem particularly useful anymore: the new permissions offer a much more flexible approach to designating "ownership" of objects. I'm going to close this issue, but if anyone still has a need for it, please open a new FR citing your specific use case.

@jeremystretch commented on GitHub (Nov 12, 2020): With the addition of object-based permissions in v2.9, this doesn't seem particularly useful anymore: the new permissions offer a much more flexible approach to designating "ownership" of objects. I'm going to close this issue, but if anyone still has a need for it, please open a new FR citing your specific use case.
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#792
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?