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

Inventory item name uniqueness not enforced with same parent device #8603

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

Originally created by @aaron-iles on GitHub (Sep 12, 2023).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.6.1

Python version

3.8

Steps to Reproduce

  1. Click Devices.
  2. Click Add and create a new device called "Foo".
  3. Click on Devices -> Inventory Items.
  4. Click Add.
  5. Create an inventory item named "Bar" and assign the parent device "Foo".
  6. Click Create.
  7. Repeat steps 4-6.

Expected Behavior

The user should be stopped from creating an inventory item under the same parent device with the same name according to the documentation: https://demo.netbox.dev/static/docs/models/dcim/inventoryitem/

Observed Behavior

Two inventory items with the name "Bar" and the parent device "Foo" exist in the database.

Originally created by @aaron-iles on GitHub (Sep 12, 2023). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.6.1 ### Python version 3.8 ### Steps to Reproduce 1. Click `Devices`. 2. Click `Add` and create a new device called "Foo". 3. Click on `Devices` -> `Inventory Items`. 4. Click `Add`. 5. Create an inventory item named "Bar" and assign the parent device "Foo". 6. Click `Create`. 7. Repeat steps 4-6. ### Expected Behavior The user should be stopped from creating an inventory item under the same parent device with the same name according to the documentation: https://demo.netbox.dev/static/docs/models/dcim/inventoryitem/ ### Observed Behavior Two inventory items with the name "Bar" and the parent device "Foo" exist in the database.
adam added the status: acceptedtype: documentation labels 2025-12-29 20:38:44 +01:00
adam closed this issue 2025-12-29 20:38:45 +01:00
adam commented 2025-12-29 20:38:45 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Sep 12, 2023):

Thank you for opening a bug report. I was unable to reproduce the reported behavior on NetBox v3.6.1. Please re-confirm the reported behavior on the current stable release and adjust your post above as necessary. Remember to provide detailed steps that someone else can follow using a clean installation of NetBox to reproduce the issue. Remember to include the steps taken to create any initial objects or other data.

@abhi1693 commented on GitHub (Sep 12, 2023): Thank you for opening a bug report. I was unable to reproduce the reported behavior on NetBox v3.6.1. Please re-confirm the reported behavior on the current stable release and adjust your post above as necessary. Remember to provide detailed steps that someone else can follow using a clean installation of NetBox to reproduce the issue. Remember to include the steps taken to create any initial objects or other data.
adam commented 2025-12-29 20:38:45 +01:00
Author
Owner
Copy Link

@aaron-iles commented on GitHub (Sep 12, 2023):

I'm not sure how else to improve the instructions to make it clearer. I tested this on 3.6.1 several times and can confirm the behavior.

Here is a screenshot from https://demo.netbox.dev/
image

@aaron-iles commented on GitHub (Sep 12, 2023): I'm not sure how else to improve the instructions to make it clearer. I tested this on 3.6.1 several times and can confirm the behavior. Here is a screenshot from https://demo.netbox.dev/ ![image](https://github.com/netbox-community/netbox/assets/35903275/b598eb84-b1b2-48fb-ad46-00ec17999eb8)
adam commented 2025-12-29 20:38:46 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Sep 12, 2023):

I checked your work on demo and it has no parent assigned to the items. Whereas your bug report was when the same parent is assigned the code still let's you add them. Please let me know when you have a bug report which is reproducible

@abhi1693 commented on GitHub (Sep 12, 2023): I checked your work on demo and it has no parent assigned to the items. Whereas your bug report was when the same parent is assigned the code still let's you add them. Please let me know when you have a bug report which is reproducible
adam commented 2025-12-29 20:38:46 +01:00
Author
Owner
Copy Link

@josh-d-smith commented on GitHub (Sep 13, 2023):

Chiming in here since I've encountered the same bug. I think there's confusion here as @aaron-iles is referring to the inventory item device field and not the parent field.

The below screenshot shows that an inventory item with the same name can be added multiple times to the same device. Please note, parent is not the issue here.
netbox_duplicate_names

Steps to Reproduce (Modified/Clarified)

  1. Click Devices.
  2. Click Add and create a new device called Foo.
  3. Click on Devices -> Inventory Items.
  4. Click Add.
  5. Create an inventory item named Bar and assign it to the device Foo.
  6. Click Create.
  7. Repeat steps 4-6.
@josh-d-smith commented on GitHub (Sep 13, 2023): Chiming in here since I've encountered the same bug. I think there's confusion here as @aaron-iles is referring to the inventory item `device` field and not the `parent` field. The below screenshot shows that an inventory item with the same name can be added multiple times to the same `device`. Please note, `parent` is not the issue here. ![netbox_duplicate_names](https://github.com/netbox-community/netbox/assets/122414633/42239d95-fa6c-4ae2-b376-50666c8f3a14) ### Steps to Reproduce (Modified/Clarified) 1. Click `Devices`. 2. Click `Add` and create a new device called `Foo`. 3. Click on `Devices` -> `Inventory Items`. 4. Click `Add`. 5. **_Create an inventory item named `Bar` and assign it to the device `Foo`._** 6. Click `Create`. 7. Repeat steps 4-6.
adam commented 2025-12-29 20:38:46 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 15, 2023):

This is happening because PostgreSQL considers NULL values to be unique. We need to add a secondary uniqueness constraint for items which have no parent item assigned.

@jeremystretch commented on GitHub (Sep 15, 2023): This is happening because PostgreSQL considers NULL values to be unique. We need to add a secondary uniqueness constraint for items which have no parent item assigned.
adam commented 2025-12-29 20:38:46 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Sep 20, 2023):

Why is there a requirement to have the name of an Inventory item unique ?
We create an item for each CPU, DISK, MEM, ...
If I have 4 CPU's, I will have 4 times the same name

for swtiches the same.. If I have 4 fans, I will have 4 times the same inventory item

Can this requirement be reconsidered ?

Actually, someone was showing his integration of Nornir with NetBox : https://netdev-community.slack.com/archives/C01PFCBBQ4T/p1695144834403849?thread_ts=1695135414.451869&cid=C01PFCBBQ4T
and he'll have issues too

@PieterL75 commented on GitHub (Sep 20, 2023): Why is there a requirement to have the name of an Inventory item unique ? We create an item for each CPU, DISK, MEM, ... If I have 4 CPU's, I will have 4 times the same name for swtiches the same.. If I have 4 fans, I will have 4 times the same inventory item Can this requirement be reconsidered ? Actually, someone was showing his integration of Nornir with NetBox : https://netdev-community.slack.com/archives/C01PFCBBQ4T/p1695144834403849?thread_ts=1695135414.451869&cid=C01PFCBBQ4T and he'll have issues too
adam commented 2025-12-29 20:38:46 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Sep 20, 2023):

In real world use-case such as yours, CPUs are labelled like CPU 1, CPU 2 etc and the same is for DISK, MEM etc. No component in your device will be unlablled by the manufacturer. Now, whether a user utilizes this information or not is a separate matter IMO.

@abhi1693 commented on GitHub (Sep 20, 2023): In real world use-case such as yours, CPUs are labelled like CPU 1, CPU 2 etc and the same is for DISK, MEM etc. No component in your device will be unlablled by the manufacturer. Now, whether a user utilizes this information or not is a separate matter IMO.
adam commented 2025-12-29 20:38:47 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Sep 20, 2023):

The same issue is present for SFP's. We have an explicit component association in netbox for inventory items now (the component field), so having SFP's with duplicate names directly associated with the corresponding interface will not be possible after this change is released. This will necessitate adding unneeded information to the SFP name just to satisfy the uniqueness constraint.

Also this is a breaking change in a patch release, it will cause migrations to fail in a large number of netbox instances. I recommend you reconsider as well or at least push it to a minor release. If the uniqueness constraint is to stay, it would make much more sense to extend it to include the component field as well.

Also of import to note is that this has never worked, and the documentation did not seem to mention the constraint until the docs refactor in v3.3.0.

@kkthxbye-code commented on GitHub (Sep 20, 2023): The same issue is present for SFP's. We have an explicit component association in netbox for inventory items now (the component field), so having SFP's with duplicate names directly associated with the corresponding interface will not be possible after this change is released. This will necessitate adding unneeded information to the SFP name just to satisfy the uniqueness constraint. Also this is a breaking change in a patch release, it will cause migrations to fail in a large number of netbox instances. I recommend you reconsider as well or at least push it to a minor release. If the uniqueness constraint is to stay, it would make much more sense to extend it to include the component field as well. Also of import to note is that this has never worked, and the documentation did not seem to mention the constraint until the docs refactor in v3.3.0.
adam commented 2025-12-29 20:38:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 20, 2023):

This will necessitate adding unneeded information to the SFP name just to satisfy the uniqueness constraint.

The only change here is enforcing the same uniqueness requirement for items both with and without a parent item. It would make no sense to treat these differently, hence the bug report.

Also this is a breaking change in a patch release

This is a bug fix, which are routinely resolved in patch releases per our release policy.

If the uniqueness constraint is to stay, it would make much more sense to extend it to include the component field as well.

You are welcome to submit a feature request proposing this.

@jeremystretch commented on GitHub (Sep 20, 2023): > This will necessitate adding unneeded information to the SFP name just to satisfy the uniqueness constraint. The only change here is enforcing the same uniqueness requirement for items both with and without a parent item. It would make no sense to treat these differently, hence the bug report. > Also this is a breaking change in a patch release This is a bug fix, which are routinely resolved in patch releases per our release policy. > If the uniqueness constraint is to stay, it would make much more sense to extend it to include the component field as well. You are welcome to submit a feature request proposing this.
adam commented 2025-12-29 20:38:47 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Sep 20, 2023):

@jeremystretch - I'll skip the migration instead. I strongly disagree with the reasoning, but I appreciate the response.

@kkthxbye-code commented on GitHub (Sep 20, 2023): @jeremystretch - I'll skip the migration instead. I strongly disagree with the reasoning, but I appreciate the response.
adam commented 2025-12-29 20:38:48 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Sep 20, 2023):

The only change here is enforcing the same uniqueness requirement for items both with and without a parent item. It would make no sense to treat these differently, hence the bug report.

Sorry missed this, not sure what you mean with only change. That is the change we are flagging?

SFP's without a parent (why would a SFP have a parent?) cannot be named the same now. Maybe it would be helpful to know what the canonical way of naming SFP's stored as inventory items now after the change? Appending an incrementing integer to the name?

@kkthxbye-code commented on GitHub (Sep 20, 2023): > The only change here is enforcing the same uniqueness requirement for items both with and without a parent item. It would make no sense to treat these differently, hence the bug report. Sorry missed this, not sure what you mean with only change. That is the change we are flagging? SFP's without a parent (why would a SFP have a parent?) cannot be named the same now. Maybe it would be helpful to know what the canonical way of naming SFP's stored as inventory items now after the change? Appending an incrementing integer to the name?
adam commented 2025-12-29 20:38:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 20, 2023):

Maybe a recap would be helpful.

Prior to merging #13786

The following constraint was in place on InventoryItem:

        constraints = (
            models.UniqueConstraint(
                fields=('device', 'parent', 'name'),
                name='%(app_label)s_%(class)s_unique_device_parent_name'
            ),
        )

At first glance, one would assume that this enforces a unique combination of (device, parent, name) for each inventory item, and that is partially correct. For example, within one device, you cannot have two items named "Item1" if they are assigned to the same parent item.

The bug reported here affects items that are not assigned to a parent. This is because PostgreSQL evaluates NULL as not equal to NULL. This result is that uniqueness is enforced for items with a parent and not for items without a parent, which is inconsistent and unexpected. This discrepancy must be resolved one way or another.

After merging #13786

The resolution in PR #13786 was to add a second constraint, which ignored null parent assignments when enforcing uniqueness:

        constraints = (
            models.UniqueConstraint(
                fields=('device', 'parent', 'name'),
                name='%(app_label)s_%(class)s_unique_device_parent_name'
            ),
            models.UniqueConstraint(
                fields=('device', 'name'),
                name='%(app_label)s_%(class)s_unique_device_name',
                condition=Q(parent__isnull=True)
            ),
        )

This replicates the same approach we've taken elsewhere within the application to ensure consistent uniqueness enforcement. With this change in place, all parentless items assigned to a particular device must have a unique name.

Now, if someone wants to propose removing the uniqueness constraint entirely, that may also be considered as an alternative solution, but it's one which would warrant adequate discussion and consideration as an intentional change versus a correction to intended behavior.

Edit: @kkthxbye-code has opened #13837 to propose considering the component assignment as part of the uniqueness constraint.

@jeremystretch commented on GitHub (Sep 20, 2023): Maybe a recap would be helpful. ### Prior to merging #13786 The following constraint was in place on InventoryItem: ```python constraints = ( models.UniqueConstraint( fields=('device', 'parent', 'name'), name='%(app_label)s_%(class)s_unique_device_parent_name' ), ) ``` At first glance, one would assume that this enforces a unique combination of (device, parent, name) for each inventory item, and that is partially correct. For example, within one device, you cannot have two items named "Item1" _if_ they are assigned to the same parent item. The bug reported here affects items that are not assigned to a parent. This is because PostgreSQL evaluates NULL as not equal to NULL. This result is that uniqueness is enforced for items with a parent and not for items without a parent, which is inconsistent and unexpected. **This discrepancy must be resolved** one way or another. ### After merging #13786 The resolution in PR #13786 was to add a second constraint, which ignored null parent assignments when enforcing uniqueness: ```python constraints = ( models.UniqueConstraint( fields=('device', 'parent', 'name'), name='%(app_label)s_%(class)s_unique_device_parent_name' ), models.UniqueConstraint( fields=('device', 'name'), name='%(app_label)s_%(class)s_unique_device_name', condition=Q(parent__isnull=True) ), ) ``` This replicates the same approach we've taken elsewhere within the application to ensure consistent uniqueness enforcement. With this change in place, all parentless items assigned to a particular device must have a unique name. Now, if someone wants to propose removing the uniqueness constraint _entirely_, that may also be considered as an alternative solution, but it's one which would warrant adequate discussion and consideration as an intentional change versus a correction to intended behavior. Edit: @kkthxbye-code has opened #13837 to propose considering the component assignment as part of the uniqueness constraint.
adam commented 2025-12-29 20:38:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 20, 2023):

I've reverted PR #13741 and re-opened this issue pending discussion on #13837.

@jeremystretch commented on GitHub (Sep 20, 2023): I've reverted PR #13741 and re-opened this issue pending discussion on #13837.
adam commented 2025-12-29 20:38:48 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 20, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 20, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:38:48 +01:00
Author
Owner
Copy Link

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

Given the degree of opposition to this "fix" both here and on #13837, I'm going to flip it around. We'll update the documentation to reflect the current behavior, and treat it as correct until explicitly changed under #13837 or some other future FR.

@jeremystretch commented on GitHub (Dec 26, 2023): Given the degree of opposition to this "fix" both here and on #13837, I'm going to flip it around. We'll update the documentation to reflect the current behavior, and treat it as correct until explicitly changed under #13837 or some other future FR.
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 status: accepted 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#8603
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?