-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Closed
Labels
severity: lowDoes not significantly disrupt application functionality, or a workaround is availableDoes not significantly disrupt application functionality, or a workaround is availablestatus: acceptedThis issue has been accepted for implementationThis issue has been accepted for implementationtype: bugA confirmed report of unexpected behavior in the applicationA confirmed report of unexpected behavior in the application
Description
NetBox version
v3.6.3
Python version
3.9
Steps to Reproduce
- Create a custom field choices object without base choices selected and with at least 1 extra choice defined.
- Create a custom field of the type "Multiple Selection" and associate with a content type (I used Virtual Machine, but the problem also appears for all other object types I've tested with such as IP addresses).
- Use the previously created custom field choices object as "Choice Set".
- Select the "Is cloneable" checkbox.
- Go to any object of the associated content type and try to clone it. It doesn't matter if the custom field has been provided with a value for that object or not.
- Cloning will fail with the message
<class 'TypeError'> 'in <string>' requires string as left operand, not NoneType - Disable the "Is cloneable" checkbox in the custom field that was created in step 2.
- Cloning the object will now work (but obviously without cloning the custom field).
Expected Behavior
I would expect the object to be cloneable when I use custom fields of the multiple selection type with the cloneable option enabled.
Observed Behavior
<class 'TypeError'>'in <string>' requires string as left operand, not NoneType occurs whenever trying to clone any object that uses a multiple selection custom field where "is cloneable" is enabled.
This worked fine in 3.5.9, so it seems it is probably related to the new custom field choices object introduced in 3.6.0.
The workaround for now is to disable "is cloneable" on all multiple selection custom fields until the cause of the error is fixed.
Metadata
Metadata
Assignees
Labels
severity: lowDoes not significantly disrupt application functionality, or a workaround is availableDoes not significantly disrupt application functionality, or a workaround is availablestatus: acceptedThis issue has been accepted for implementationThis issue has been accepted for implementationtype: bugA confirmed report of unexpected behavior in the applicationA confirmed report of unexpected behavior in the application