Duplicate “Add” buttons on child object list views #11570

New Issue

adam · 2025-12-29T21:46:53+01:00

adam commented

2025-12-29 21:46:53 +01:00

Originally created by @pheus on GitHub (Sep 4, 2025).

Originally assigned to: @pheus on GitHub.

Deployment Type

Self-hosted

NetBox Version

v4.4.0

Python Version

3.10

Steps to Reproduce

Minimal example (Prefixes → Child Prefixes):

Create a parent prefix (e.g., 10.0.0.0/8).
Open the parent prefix’s detail view.
Navigate to the Child Prefixes view for that prefix.
Observe two buttons at the top right: a contextual Add Prefix button and a generic Add button.

Also reproducible on other child views (examples):

Prefixes → Child Ranges
Racks → Non-racked Devices
Device → Contacts

Expected Behavior

Only one add action should be presented: the contextual add button for the specific child view (e.g., Add Prefix on Child Prefixes).

Observed Behavior

Both a contextual add button (e.g., Add Prefix) and a generic Add button are displayed. The generic Add button opens the create form without pre-populating the parent context.

Originally created by @pheus on GitHub (Sep 4, 2025). Originally assigned to: @pheus on GitHub. ### Deployment Type Self-hosted ### NetBox Version v4.4.0 ### Python Version 3.10 ### Steps to Reproduce *Minimal example (Prefixes → Child Prefixes):* 1. Create a parent prefix (e.g., `10.0.0.0/8`). 2. Open the parent prefix’s detail view. 3. Navigate to the **Child Prefixes** view for that prefix. 4. Observe two buttons at the top right: a contextual **Add Prefix** button and a generic **Add** button. *Also reproducible on other child views (examples):* - **Prefixes → Child Ranges** - **Racks → Non-racked Devices** - **Device → Contacts** ### Expected Behavior Only one add action should be presented: the contextual add button for the specific child view (e.g., **Add Prefix** on Child Prefixes). ### Observed Behavior Both a contextual add button (e.g., **Add Prefix**) and a generic **Add** button are displayed. The generic **Add** button opens the create form without pre-populating the parent context. <img width="1814" height="732" alt="Image" src="https://github.com/user-attachments/assets/0eaf91b0-ae16-4b58-b633-13e70c2fbd23" />

adam added the type: bug status: accepted severity: low labels 2025-12-29 21:46:53 +01:00

adam closed this issue

2025-12-29 21:46:54 +01:00

adam commented

2025-12-29 21:46:54 +01:00

@pheus commented on GitHub (Sep 4, 2025):

Thanks for the work on ObjectActions in #19774 !

While reviewing the duplicate “Add” buttons reported above, it appears that ObjectChildrenView now registers the generic AddObject action for child views. In prior releases, child views registered only their context‑specific add action.

Because most child views in core (and many plugins) already provide a context‑specific add action, the generic registration results in two “Add” buttons on child lists; the generic one also doesn’t pre‑populate the parent context.

Proposal: Remove the generic AddObject registration from ObjectChildrenView (or skip it when a view defines a specific add action).

ea50786b5c/netbox/netbox/views/generic/object_views.py (L106)

I’m happy to open a PR to implement this if the approach sounds reasonable. If there’s background or use‑cases I’m missing, please let me know. Thanks!

@pheus commented on GitHub (Sep 4, 2025): Thanks for the work on ObjectActions in #19774 ! While reviewing the duplicate “Add” buttons reported above, it appears that `ObjectChildrenView` now registers the generic `AddObject` action for child views. In prior releases, child views registered only their context‑specific add action. Because most child views in core (and many plugins) already provide a context‑specific add action, the generic registration results in two “Add” buttons on child lists; the generic one also doesn’t pre‑populate the parent context. **Proposal:** Remove the generic `AddObject` registration from `ObjectChildrenView` (or skip it when a view defines a specific add action). https://github.com/netbox-community/netbox/blob/ea50786b5c68af6ca7eca91cfde36f8211f6b44b/netbox/netbox/views/generic/object_views.py#L106 I’m happy to open a PR to implement this if the approach sounds reasonable. If there’s background or use‑cases I’m missing, please let me know. Thanks!

adam commented

2025-12-29 21:46:56 +01:00

@bctiemann commented on GitHub (Sep 5, 2025):

Sounds reasonable to me; we'll review the PR for any side effects it mght have. Thanks @pheus !

@bctiemann commented on GitHub (Sep 5, 2025): Sounds reasonable to me; we'll review the PR for any side effects it mght have. Thanks @pheus !

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11570