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

Parent property for IPAddress/Prefix #7125

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

Originally created by @elipsion on GitHub (Oct 19, 2022).

NetBox version

v3.3.5

Feature type

Data model extension

Proposed functionality

Add an object property pointing to the direct parent of an object.

Use case

Permission rules requiring a parent object to have certain properties.

Database changes

No response

External dependencies

No response

Originally created by @elipsion on GitHub (Oct 19, 2022). ### NetBox version v3.3.5 ### Feature type Data model extension ### Proposed functionality Add an object property pointing to the direct parent of an object. ### Use case Permission rules requiring a parent object to have certain properties. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:19:28 +01:00
adam closed this issue 2025-12-29 20:19:28 +01:00
adam commented 2025-12-29 20:19:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 19, 2022):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

@jeremystretch commented on GitHub (Oct 19, 2022): Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.
adam commented 2025-12-29 20:19:29 +01:00
Author
Owner
Copy Link

@elipsion commented on GitHub (Oct 19, 2022):

Hi Jeremy,
Thank you for your thorough review of my feature request and accompanying code snippets, nothing makes me want to contribute more to open-source software like a generic canned response with clauses not related to the issue in question.

Your contributing guide does not give any indication of how much of an essay is expected for what is essentially 4 lines of code, so maybe you can enlighten me on what is expected?
I found the need for this when writing permission constraints and in keeping up with the standard set by the documentation didn't want to include any unnecessary writing that might confuse the reader.
The rule that I wanted to enforce was as follows:

[{"address__parent_prefix__tennant__id": 3}]
@elipsion commented on GitHub (Oct 19, 2022): Hi Jeremy, Thank you for your thorough review of my feature request and accompanying code snippets, nothing makes me want to contribute more to open-source software like a generic canned response with clauses not related to the issue in question. Your contributing guide does not give any indication of how much of an essay is expected for what is essentially 4 lines of code, so maybe you can enlighten me on what is expected? I found the need for this when writing [permission constraints](https://docs.netbox.dev/en/stable/administration/permissions/#permissions-enforcement) and in keeping up with the standard set by the documentation didn't want to include any unnecessary writing that might confuse the reader. The rule that I wanted to enforce was as follows: ```json [{"address__parent_prefix__tennant__id": 3}] ```
adam commented 2025-12-29 20:19:29 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Oct 19, 2022):

@elipsion - Like the docs you link mention, permission constraints are just QuerySet filters. You cannot filter on properties.

Did you test your PR before submitting it?

If you just want permissions like that working, it would be covered by https://github.com/netbox-community/netbox/issues/7845

@kkthxbye-code commented on GitHub (Oct 19, 2022): @elipsion - Like the docs you link mention, permission constraints are just QuerySet filters. You cannot filter on properties. Did you test your PR before submitting it? If you just want permissions like that working, it would be covered by https://github.com/netbox-community/netbox/issues/7845
adam commented 2025-12-29 20:19:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 19, 2022):

Thank you for your thorough review of my feature request and accompanying code snippets,

Per the pull request template:

IF YOUR PULL REQUEST DOES NOT REFERENCE AN ISSUE WHICH HAS BEEN ASSIGNED TO YOU, IT WILL BE CLOSED AUTOMATICALLY.

We don't spend any time reviewing PRs for issues that have not been accepted, as clearly indicated both above and in our contributing guide.

Your contributing guide does not give any indication of how much of an essay is expected for what is essentially 4 lines of code, so maybe you can enlighten me on what is expected?

Per the contributing guide:

Good feature requests are very narrowly defined. Be sure to thoroughly describe the functionality and data model(s) being proposed. The more effort you put into writing a feature request, the better its chance is of being implemented. Overly broad feature requests will be closed.

When submitting a feature request on GitHub, be sure to include all information requested by the issue template, including:

  • A detailed description of the proposed functionality
  • A use case for the feature; who would use it and what value it would add to NetBox
  • A rough description of changes necessary to the database schema (if applicable)
  • Any third-party libraries or other resources which would be involved

The entirety of your proposal was the sentence

Add an object property pointing to the direct parent of an object.

Surely you realize that's not sufficient detail. You didn't even propose a name for the property.

While we'd be happy to review your proposal, you'll need to meet us halfway and invest reasonable effort in its definition, for the benefit of both the maintainers charged with its review as well as the community at large. If you're not willing to do that in a polite and productive manner, please refrain from participating.

@jeremystretch commented on GitHub (Oct 19, 2022): > Thank you for your thorough review of my feature request and accompanying code snippets, Per the pull request template: > IF YOUR PULL REQUEST DOES NOT REFERENCE AN ISSUE WHICH HAS BEEN ASSIGNED TO YOU, IT WILL BE CLOSED AUTOMATICALLY. We don't spend any time reviewing PRs for issues that have not been accepted, as clearly indicated both above and in our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md). > Your contributing guide does not give any indication of how much of an essay is expected for what is essentially 4 lines of code, so maybe you can enlighten me on what is expected? Per the contributing guide: > Good feature requests are very narrowly defined. Be sure to thoroughly describe the functionality and data model(s) being proposed. The more effort you put into writing a feature request, the better its chance is of being implemented. Overly broad feature requests will be closed. > > When submitting a feature request on GitHub, be sure to include all information requested by the issue template, including: > * A detailed description of the proposed functionality > * A use case for the feature; who would use it and what value it would add to NetBox > * A rough description of changes necessary to the database schema (if applicable) > * Any third-party libraries or other resources which would be involved The entirety of your proposal was the sentence > Add an object property pointing to the direct parent of an object. Surely you realize that's not sufficient detail. You didn't even propose a _name_ for the property. While we'd be happy to review your proposal, you'll need to meet us halfway and invest reasonable effort in its definition, for the benefit of both the maintainers charged with its review as well as the community at large. If you're not willing to do that in a polite and productive manner, please refrain from participating.
adam commented 2025-12-29 20:19:30 +01:00
Author
Owner
Copy Link

@elipsion commented on GitHub (Oct 20, 2022):

Like the docs you link mention, permission constraints are just QuerySet filters. You cannot filter on properties.

Ah, I did not know that. The documentation is, as I mentioned, not very extensive and the link to Django points to a fragment that is no longer present.

If you just want permissions like that working, it would be covered by #7845

It would indeed be covered by that issue, thanks for pointing it out. This could if nothing else be seen as a stopgap implementation until the database changes has been hashed out.

@elipsion commented on GitHub (Oct 20, 2022): > Like the docs you link mention, permission constraints are just QuerySet filters. You cannot filter on properties. Ah, I did not know that. The documentation is, as I mentioned, not very extensive and the link to Django points to a fragment that is no longer present. > If you just want permissions like that working, it would be covered by #7845 It would indeed be covered by that issue, thanks for pointing it out. This could if nothing else be seen as a stopgap implementation until the database changes has been hashed out.
adam commented 2025-12-29 20:19:30 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Oct 20, 2022):

Ah, I did not know that. The documentation is, as I mentioned, not very extensive

I diagree, the docs here very clearly point out how the filtering works. Also the netbox docs are not expected to document how django or the django ORM functions, if you want to contribute code, it is expected that you either know that yourself or has the capacity to look it up on your own.

and the link to Django points to a fragment that is no longer present.

Works fine here, points to the right place in the django docs for me.

This could if nothing else be seen as a stopgap implementation until the database changes has been hashed out.

It would never work, so I'm not sure how it would be a stopgap? That's one of the reasons why your FR was inadequate, you proposed a specific non-functional implementation instead of explaining what you wanted to achieve. As it stands now, the proposed functionality in your FR will not solve the usecase you described, so I'll close this out as invalid.

@kkthxbye-code commented on GitHub (Oct 20, 2022): > Ah, I did not know that. The documentation is, as I mentioned, not very extensive I diagree, the docs here very clearly point out how the filtering works. Also the netbox docs are not expected to document how django or the django ORM functions, if you want to contribute code, it is expected that you either know that yourself or has the capacity to look it up on your own. > and the link to Django points to a fragment that is no longer present. Works fine here, points to the right place in the django docs for me. > This could if nothing else be seen as a stopgap implementation until the database changes has been hashed out. It would never work, so I'm not sure how it would be a stopgap? That's one of the reasons why your FR was inadequate, you proposed a specific non-functional implementation instead of explaining what you wanted to achieve. As it stands now, the proposed functionality in your FR will not solve the usecase you described, so I'll close this out as invalid.
adam commented 2025-12-29 20:19:30 +01:00
Author
Owner
Copy Link

@elipsion commented on GitHub (Oct 20, 2022):

I could have chosen a better word than stopgap, sure. The feature is still useful for someone consuming the REST API, even if that wasn't my use case.

@elipsion commented on GitHub (Oct 20, 2022): I could have chosen a better word than stopgap, sure. The feature is still useful for someone consuming the REST API, even if that wasn't *my* 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#7125
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?