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

Provide documentation explaining what fields should be used for (their purpose) #8910

New Issue
Closed
opened 2025-12-29 20:42:44 +01:00 by adam · 2 comments
adam commented 2025-12-29 20:42:44 +01:00
Owner
Copy Link

Originally created by @jwbensley on GitHub (Dec 4, 2023).

Change Type

Addition

Area

Features

Proposed Changes

As I pointed out in this issue: https://github.com/netbox-community/netbox/issues/13027
Lots of people have opened issues over the years requesting field lengths be extended.
My issues was because of the facility name being too short, which resulted in this dedicated sub-issue being opened: https://github.com/netbox-community/netbox/issues/13316

My parent and sub-issue were both closed because they are examples (according to Jeremy) of how data should not be modelled in NetBox, abusing the fields/data model. This also applies to the various issues I linked to in 13027, lots of them were closed due to incorrect use of the NetBox data model in Jeremy's eyes.

It's fine to close tickets with this reason, if the purpose of these fields/the correct usage of these fields, is actually documented somewhere, which it isn't.

If you want users to store specific information and specific fields, and use that as a valid reason to close issues, you need to document how the fields should be used.

I still have the problem that I have facilities with a name longer than 50 characters and I can't store this in NetBox. It's a totally legit request that was denied. But it also applies to many other fields too. So I think we need documentation so that we don't waste time opening more GitHub issues.

Originally created by @jwbensley on GitHub (Dec 4, 2023). ### Change Type Addition ### Area Features ### Proposed Changes As I pointed out in this issue: https://github.com/netbox-community/netbox/issues/13027 Lots of people have opened issues over the years requesting field lengths be extended. My issues was because of the facility name being too short, which resulted in this dedicated sub-issue being opened: https://github.com/netbox-community/netbox/issues/13316 My parent and sub-issue were both closed because they are examples (according to Jeremy) of how data should not be modelled in NetBox, abusing the fields/data model. This also applies to the various issues I linked to in 13027, lots of them were closed due to incorrect use of the NetBox data model in Jeremy's eyes. It's fine to close tickets with this reason, **if** the purpose of these fields/the correct usage of these fields, is actually documented somewhere, which it isn't. If you want users to store specific information and specific fields, and use that as a valid reason to close issues, you need to document how the fields should be used. I still have the problem that I have facilities with a name longer than 50 characters and I can't store this in NetBox. It's a totally legit request that was denied. But it also applies to many other fields too. So I think we need documentation so that we don't waste time opening more GitHub issues.
adam added the type: documentation label 2025-12-29 20:42:44 +01:00
adam closed this issue 2025-12-29 20:42:44 +01:00
adam commented 2025-12-29 20:42:45 +01:00
Author
Owner
Copy Link

@Chiniquy commented on GitHub (Dec 4, 2023):

I assume you have seen https://docs.netbox.dev/en/stable/, and so your argument would then be that the explanations of the usage of fields within the documentation is insufficient?
The use of tenancy is documented pretty well imo in https://docs.netbox.dev/en/stable/features/tenancy/. Reading this would solve the issue #13316 (for that specific case) as it is explained in the documentation that:
"Tenant assignment is used to signify the ownership of an object in NetBox. As such, each object may only be owned by a single tenant. For example, if you have a firewall dedicated to a particular customer, you would assign it to the tenant which represents that customer. However, if the firewall serves multiple customers, it doesn't belong to any particular customer, so tenant assignment would not be appropriate."

@Chiniquy commented on GitHub (Dec 4, 2023): I assume you have seen https://docs.netbox.dev/en/stable/, and so your argument would then be that the explanations of the usage of fields within the documentation is insufficient? The use of tenancy is documented pretty well imo in https://docs.netbox.dev/en/stable/features/tenancy/. Reading this would solve the issue #13316 (for that specific case) as it is explained in the documentation that: _"Tenant assignment is used to signify the ownership of an object in NetBox. As such, each object may only be owned by a single tenant. For example, if you have a firewall dedicated to a particular customer, you would assign it to the tenant which represents that customer. However, if the firewall serves multiple customers, it doesn't belong to any particular customer, so tenant assignment would not be appropriate."_
adam commented 2025-12-29 20:42:45 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 4, 2023):

As @Chiniquy points out, the specific purpose of each model field is already well documented. It appears that your only motivation for opening this issue is to complain about other issues being closed, so it too is being closed.

NetBox is open source software. If you disagree with the decisions of its maintainers, you have complete freedom to modify it as you see fit.

@jeremystretch commented on GitHub (Dec 4, 2023): As @Chiniquy points out, the specific purpose of each model field is already well documented. It appears that your only motivation for opening this issue is to complain about other issues being closed, so it too is being closed. NetBox is open source software. If you disagree with the decisions of its maintainers, you have complete freedom to modify it as you see fit.
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: documentation
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#8910
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?