starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Custom Field Object Type / Custom Relationship UI confusion #6093

New Issue
Closed
opened 2025-12-29 19:36:41 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:36:41 +01:00
Owner
Copy Link

Originally created by @ryanmerolle on GitHub (Feb 15, 2022).

NetBox version

v3.2-beta1

Feature type

Change to existing functionality

Proposed functionality

The current UI field for custom fields Object Type (Type of the related object (for object/multi-object fields only)) is confusing.

I am not quite sure how to improve the wording yet, but it should reference something about it being if you want to leverage a custom object field and it should mention fields field types that can be selected with this function.

Use case

Without the wording being changed, users will be confused.

Database changes

No response

External dependencies

No response

Originally created by @ryanmerolle on GitHub (Feb 15, 2022). ### NetBox version v3.2-beta1 ### Feature type Change to existing functionality ### Proposed functionality The current UI field for custom fields Object Type (Type of the related object (for object/multi-object fields only)) is confusing. I am not quite sure how to improve the wording yet, but it should reference something about it being if you want to leverage a custom object field and it should mention fields field types that can be selected with this function. ### Use case Without the wording being changed, users will be confused. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: under review labels 2025-12-29 19:36:41 +01:00
adam closed this issue 2025-12-29 19:36:41 +01:00
adam commented 2025-12-29 19:36:42 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Feb 18, 2022):

When testing the CustomObjects, I was confused with the 'model(s)' field.. I assumed that was the one to select the object type I wanted...
So maybe rename 'Model(s)' to 'Link to model(s)'
and 'Object Type' to 'Applied Object Type' ?

@PieterL75 commented on GitHub (Feb 18, 2022): When testing the CustomObjects, I was confused with the 'model(s)' field.. I assumed that was the one to select the object type I wanted... So maybe rename 'Model(s)' to 'Link to model(s)' and 'Object Type' to 'Applied Object Type' ?
adam commented 2025-12-29 19:36:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 23, 2022):

It would help to hide the "object type" field for all but the relevant custom field type selections. There's some work currently underway on #8710 that might facilitate this.

@jeremystretch commented on GitHub (Feb 23, 2022): It would help to hide the "object type" field for all but the relevant custom field type selections. There's some work currently underway on #8710 that might facilitate this.
adam commented 2025-12-29 19:36:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 3, 2022):

It doesn't look like the change in #8710 can be repurposed for this.

@thatmattlove how much effort would it be to hide the object_type field in the custom field form when a non-applicable field type is selected?

@jeremystretch commented on GitHub (Mar 3, 2022): It doesn't look like the change in #8710 can be repurposed for this. @thatmattlove how much effort would it be to hide the `object_type` field in the custom field form when a non-applicable field type is selected?
adam commented 2025-12-29 19:36:43 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Mar 8, 2022):

Thinking more broadly than this one case, what if we used an attribute such as data-visibility that contains stringified JSON such as:

[
  {
    "selector": "#example",
    "value": "expected value",
    "action": "show"
  },
  {
    "selector": "#other-selector",
    "value": "other expected value",
    "action": "hide"
  }
]

Then on the JS side, we could attach event listeners to any listed elements so that when their value equals the provided value, perform the action (show or hide).

The JSON could be set on the Django form field as a list/dict like we do in other instances.

I don't think this would be super difficult to implement, if this is acceptable.

@thatmattlove commented on GitHub (Mar 8, 2022): Thinking more broadly than this one case, what if we used an attribute such as `data-visibility` that contains stringified JSON such as: ```json [ { "selector": "#example", "value": "expected value", "action": "show" }, { "selector": "#other-selector", "value": "other expected value", "action": "hide" } ] ``` Then on the JS side, we could attach event listeners to any listed elements so that when their value equals the provided value, perform the action (show or hide). The JSON could be set on the Django form field as a list/dict like we do in other instances. I don't think this would be super difficult to implement, if this is acceptable.
adam commented 2025-12-29 19:36:43 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 5, 2022):

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. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 5, 2022): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:36:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 7, 2022):

It doesn't look like there's anything we can feasibly do in the near term to address this, and we haven't seen any further feedback on it, so I'm going to close this out for now. Happy to revisit once we have some more robust UI form controls in place.

@jeremystretch commented on GitHub (Jun 7, 2022): It doesn't look like there's anything we can feasibly do in the near term to address this, and we haven't seen any further feedback on it, so I'm going to close this out for now. Happy to revisit once we have some more robust UI form controls in place.
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: under review 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#6093
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?