Skip to content

prepare_cloned_fields() should check for cloning support on model #18500

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

Closed
jeremystretch opened this issue Jan 27, 2025 · 0 comments · Fixed by #19252
Closed

prepare_cloned_fields() should check for cloning support on model #18500

jeremystretch opened this issue Jan 27, 2025 · 0 comments · Fixed by #19252
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Milestone

Comments

@jeremystretch
Copy link
Member

Deployment Type

NetBox Cloud

NetBox Version

v4.2.2

Python Version

3.10

Steps to Reproduce

  1. Define a clone() method on a plugin model, returning None.
  2. Install the plugin.
  3. Attempt to view an instance of that model.

Expected Behavior

The object should render successfully.

Observed Behavior

An unhandled AttributeError exception is raised:

'NoneType' object has no attribute 'items'

This is because NetBox expects the clone() method, if defined on a model, to return a set of attributes suitable for pre-populating the creation form for the model. However, a plugin author might want to introduce a clone() method for unrelated reasons.

NetBox should inspect the model and attempt to call clone() only for models which inherit from CloningMixin.

@jeremystretch jeremystretch added severity: low Does not significantly disrupt application functionality, or a workaround is available status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation type: bug A confirmed report of unexpected behavior in the application labels Jan 27, 2025
@arthanson arthanson self-assigned this Apr 21, 2025
@arthanson arthanson removed the status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation label Apr 21, 2025
@jeremystretch jeremystretch added the status: accepted This issue has been accepted for implementation label Apr 22, 2025
@jeremystretch jeremystretch added this to the v4.2.8 milestone Apr 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants