Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize filtering logic for the parents of recursively-nested models #15383

Closed
jeremystretch opened this issue Mar 8, 2024 · 0 comments
Closed
Assignees
Labels
breaking change This change modifies or removes some previously documented functionality status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@jeremystretch
Copy link
Member

jeremystretch commented Mar 8, 2024

NetBox version

v3.7.3

Feature type

Change to existing functionality

Proposed functionality

I'm opening this FR to address an inconsistency in the filtering of parent objects of self-recursive models (e.g. regions, site groups, locations, etc.).

For most of these objects, filtering by the parent object will return only the immediate children of the specified parent. For example, filtering for all regions belonging to North America (PK 1) will return only the countries assigned to that continent; it will not include child states or cities within each country.

# Returns immediate children only
GET /api/dcim/regions/?parent_id=1

However, this is not true for locations. Per #6124, filtering locations by a parent location will return all of the parent object's descendants. For example, if dealing with a hierarchy of buildings, floors, and rooms, filtering for a specific building will return both rooms and floors within it.

# Returns *all* descendants in the hierarchy
GET /api/dcim/locations/?parent_id=1

I am proposing a two-part change:

  1. Standardize the behavior of the parent & parent_id filters so that they behave consistently across all nested models. (This will likely mean modifying the current behavior of the location filter, as it would be the smallest breaking change.)
  2. Introducing an alternative filters for all models to provide the complementary filtering behavior (perhaps named ancestor).

Edit: For example, you could then do

GET /api/dcim/regions/?parent_id=1

to return only the immediate children of region 1, OR

GET /api/dcim/regions/?ancestor_id=1

to return all regions within region 1.

Use case

Neither behavior described above is objectively correct or incorrect: Both have valid use cases. However, we should address the inconsistency and prescribe a clear mechanism for achieving either behavior for all relevant models.

Database changes

None expected

External dependencies

None

@jeremystretch jeremystretch added type: feature Introduction of new functionality to the application status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Mar 8, 2024
@jeremystretch jeremystretch self-assigned this Mar 11, 2024
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Mar 11, 2024
@jeremystretch jeremystretch added this to the v4.0 milestone Mar 11, 2024
jeremystretch added a commit that referenced this issue Mar 11, 2024
jeremystretch added a commit that referenced this issue Mar 11, 2024
@jeremystretch jeremystretch added the breaking change This change modifies or removes some previously documented functionality label May 9, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking change This change modifies or removes some previously documented functionality status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

1 participant