internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: netbox-community/netbox

Issue:
#10031 precludes the use of Content-Type: multipart/form-data
### NetBox version

v3.3.1

### Python version

3.8

### Steps to Reproduce

I recently deployed Netbox v3.3.1 to my dev environment, where I have scripts to rebuild the environment from scratch. 

One of the scripts `POST` images to the `/extras/image-attachments/` REST endpoint. 

This requires `Content-Type` `multipart/form-data` which is set by the requests library given the presence of `file=` in the `POST`.

[#10031](https://github.com/netbox-community/netbox/issues/10031) - Enforce `application/json` content type for REST API requests precludes the ability to `POST` `multipart/form-data`.

I reverted the changes in [#10031](https://github.com/netbox-community/netbox/issues/10031) and had no issues with my image uploader script.

Is there a preferential or superior method to upload thousands of images? When researching/writing the existing script, suggestions were sparse.

### Expected Behavior

ability to POST `multipart/form-data`

### Observed Behavior

exception raised:

`Unsupported media type \"multipart/form-data; boundary=89cv423z57692384759"`

which, in my humble opinion can be as confusing as the errors [#10031](https://github.com/netbox-community/netbox/issues/10031) seeks to address.


Discussion:
Admittedly, this was an oversight on my part. I think it makes sense to leave the default parsers list as is, and [add](https://www.django-rest-framework.org/api-guide/parsers/#setting-the-parsers) the MultiPartParser only for endpoints which accept files (such as `/api/extras/image-attachments/`).
To avoid confusion among plugin developers, it's probably best to include MultiPartParser by default. We can restore this while still addressing the root issue captured under #10031.

Resolving patch:
diff --git a/netbox/netbox/settings.py b/netbox/netbox/settings.py
--- a/netbox/netbox/settings.py
+++ b/netbox/netbox/settings.py
@@ -535,6 +535,7 @@ def _setting(name, default=None):
     'DEFAULT_PAGINATION_CLASS': 'netbox.api.pagination.OptionalLimitOffsetPagination',
     'DEFAULT_PARSER_CLASSES': (
         'rest_framework.parsers.JSONParser',
+        'rest_framework.parsers.MultiPartParser',
     ),
     'DEFAULT_PERMISSION_CLASSES': (
         'netbox.api.authentication.TokenPermissions',


Test patch:
Repository: netbox-community/netbox

Issue:
Tracing single cable to multiple front-ports with separate rear-ports causes exception
### NetBox version

v3.3.1

### Python version

3.10

### Steps to Reproduce

1. Create Site
2. Create Device Role
3. Create Device Type for switch (at least 1 interface)
4. Create Device Type for patch panel (at least 2 rear ports with 1 position each connected to 2 front ports)
5. Create 2 Devices for patch panel
6. Create 1 Device for switch
7. Connect interface on switch to 2 front ports
8. Connect rear ports on patch panel 1 to rear ports on patch panel 2
9. Attempt a trace

### Expected Behavior

Trace completes successfully

### Observed Behavior

Trace fails with exception:

```
ValueError at /dcim/interfaces/2374/trace/
Cannot query "<FrontPort on Panel 1>": Must be "RearPort" instance.
Request Method:	GET
Request URL:	http://127.0.0.1:8000/dcim/interfaces/2374/trace/
Django Version:	4.0.7
Exception Type:	ValueError
Exception Value:	
Cannot query "<FrontPort on Panel 1>": Must be "RearPort" instance.
```


Discussion:
I have a diagram for clarity.


Not working:

![Diagram](https://user-images.githubusercontent.com/11049792/187531275-2bcc9707-0429-4a52-907b-8056e35832f3.PNG)


Working:

![Diagram - Works](https://user-images.githubusercontent.com/11049792/187532262-d73548aa-38a3-4d3f-b6df-3a2d98a5ebba.PNG)

To be clear, tracing across the first topology is not supported as the path splits across multiple cables. However, tracing in this situation should inform the user of a split path and present options for continuing the trace, rather than raising an exception.

Resolving patch:
diff --git a/netbox/dcim/models/cables.py b/netbox/dcim/models/cables.py
--- a/netbox/dcim/models/cables.py
+++ b/netbox/dcim/models/cables.py
@@ -677,6 +677,12 @@ def get_split_nodes(self):
         """
         Return all available next segments in a split cable path.
         """
-        rearports = self.path_objects[-1]
-
-        return FrontPort.objects.filter(rear_port__in=rearports)
+        nodes = self.path_objects[-1]
+
+        # RearPort splitting to multiple FrontPorts with no stack position
+        if type(nodes[0]) is RearPort:
+            return FrontPort.objects.filter(rear_port__in=nodes)
+        # Cable terminating to multiple FrontPorts mapped to different
+        # RearPorts connected to different cables
+        elif type(nodes[0]) is FrontPort:
+            return RearPort.objects.filter(pk__in=[fp.rear_port_id for fp in nodes])


Test patch:
Repository: netbox-community/netbox

Issue:
VirtualMachine model does not check family of ip address assigned as primary_ip4/6
### NetBox version

v3.3.1

### Python version

3.10

### Steps to Reproduce

1. Create virtual machine "vm1"
2. Create VM interface "vm_int1"
3. Create IP address "127.0.0.1/8"
4. Assign 127.0.0.1/8 to VM interface "vm_int1"
5. Execute PATCH request to /api/virtualization/virtual-machines/ (Insert respective Ids of VM and IP):
```
curl -X PATCH \
      -H  "accept: application/json" -H  "Authorization: Token $NETBOX_TOKEN" \
      --data '{"primary_ip6": 1}' -H "Content-Type: application/json" 
      "http://localhost:8000/api/virtualization/virtual-machines/1/"
```

### Expected Behavior

An error is returned that an IPv4 address can not be assigned as primary_ipv6

### Observed Behavior

IPv4 address is assigned as primary_ip6
![image](https://user-images.githubusercontent.com/67868947/187533885-e97c04b8-816d-460a-aec5-aaa8d7e086b1.png)



Discussion:
We may be able to reuse some of the validation that we have in place for this on the Device model, however that also checks for interfaces on virtual chassis members, which doesn't apply to virtual machines.

Resolving patch:
diff --git a/netbox/virtualization/models.py b/netbox/virtualization/models.py
--- a/netbox/virtualization/models.py
+++ b/netbox/virtualization/models.py
@@ -368,9 +368,14 @@ def clean(self):
 
         # Validate primary IP addresses
         interfaces = self.interfaces.all()
-        for field in ['primary_ip4', 'primary_ip6']:
+        for family in (4, 6):
+            field = f'primary_ip{family}'
             ip = getattr(self, field)
             if ip is not None:
+                if ip.address.version != family:
+                    raise ValidationError({
+                        field: f"Must be an IPv{family} address. ({ip} is an IPv{ip.address.version} address.)",
+                    })
                 if ip.assigned_object in interfaces:
                     pass
                 elif ip.nat_inside is not None and ip.nat_inside.assigned_object in interfaces:


Test patch:
Repository: netbox-community/netbox

Issue:
Units range in rack reservation return an empty field error if put in decreasing order
### NetBox version

v3.2.7

### Python version

3.10

### Steps to Reproduce

1. Create a rack reservation
2. Put a unit range with bigger number first (like 7-2)
3. Click create

### Expected Behavior

The reservation should be created with the good unit values or return a more explicit error.

### Observed Behavior

Netbox gives an error like the field "Units" is empty.
It works if Units are given in the right order (2-7 here).

![image](https://user-images.githubusercontent.com/6941618/180258604-d81617b3-23d3-4cae-84d5-5d80debe385d.png)



Discussion:
I agree that the error message should be improved, however support for decreasing units was never intended so the validation failure is expected.

Resolving patch:
diff --git a/netbox/utilities/forms/widgets.py b/netbox/utilities/forms/widgets.py
--- a/netbox/utilities/forms/widgets.py
+++ b/netbox/utilities/forms/widgets.py
@@ -110,6 +110,12 @@ class SelectSpeedWidget(forms.NumberInput):
 
 class NumericArrayField(SimpleArrayField):
 
+    def clean(self, value):
+        if value and not self.to_python(value):
+            raise forms.ValidationError(f'Invalid list ({value}). '
+                                        f'Must be numeric and ranges must be in ascending order')
+        return super().clean(value)
+
     def to_python(self, value):
         if not value:
             return []


Test patch:
Repository: netbox-community/netbox

Issue:
ChangeLog false positive for wwn 
### NetBox version

v3.3.2

### Python version

3.8

### Steps to Reproduce

1. Update a Interface
2. Display the generated change log.


### Expected Behavior

Only changed properties are detected as changed.

### Observed Behavior

`wwn` is detected as a changed from `null` to `""`


Discussion:

Resolving patch:
diff --git a/netbox/dcim/forms/models.py b/netbox/dcim/forms/models.py
--- a/netbox/dcim/forms/models.py
+++ b/netbox/dcim/forms/models.py
@@ -1331,6 +1331,12 @@ class InterfaceForm(InterfaceCommonForm, NetBoxModelForm):
         label='VRF'
     )
 
+    wwn = forms.CharField(
+        empty_value=None,
+        required=False,
+        label='WWN'
+    )
+
     fieldsets = (
         ('Interface', ('device', 'module', 'name', 'type', 'speed', 'duplex', 'label', 'description', 'tags')),
         ('Addressing', ('vrf', 'mac_address', 'wwn')),


Test patch:
Repository: netbox-community/netbox

Issue:
'ui_visibility' help is missing in Custom Fields Bulk Import form
### NetBox version

v3.3.2

### Python version

3.10

### Steps to Reproduce

1. Browse to the Custom Field Bulk Import
2. Reach the documentation of the `ui_visibility` field
3. Notice that the blue help button is missing to describe the available choices


### Expected Behavior

A blue help button should be present to describe the available choices.

### Observed Behavior

The `ui_visibility` field should be a `CSVChoiceField` to allow for the Choices modal to display with its button.


Discussion:

Resolving patch:
diff --git a/netbox/extras/forms/bulk_import.py b/netbox/extras/forms/bulk_import.py
--- a/netbox/extras/forms/bulk_import.py
+++ b/netbox/extras/forms/bulk_import.py
@@ -3,7 +3,7 @@
 from django.contrib.postgres.forms import SimpleArrayField
 from django.utils.safestring import mark_safe
 
-from extras.choices import CustomFieldTypeChoices
+from extras.choices import CustomFieldVisibilityChoices, CustomFieldTypeChoices
 from extras.models import *
 from extras.utils import FeatureQuery
 from utilities.forms import CSVChoiceField, CSVContentTypeField, CSVModelForm, CSVMultipleContentTypeField, SlugField
@@ -38,6 +38,10 @@ class CustomFieldCSVForm(CSVModelForm):
         required=False,
         help_text='Comma-separated list of field choices'
     )
+    ui_visibility = CSVChoiceField(
+        choices=CustomFieldVisibilityChoices,
+        help_text='How the custom field is displayed in the user interface'
+    )
 
     class Meta:
         model = CustomField


Test patch:
Repository: netbox-community/netbox

Issue:
Virtual Chassis master field cannot be null according to the API
### NetBox version

v3.2.9

### Python version

3.10

### Steps to Reproduce

1. Submit API write request to the VirtualChassis with "master": null in it

### Expected Behavior

Requests is accepted and the master is unset for the specific VirtualChassis

### Observed Behavior

HTTP 400 is returned with the message: `[{"master":["This field may not be null."]}]`


Discussion:
It probably needs allow_null=True and default=None here: https://github.com/netbox-community/netbox/blob/master/netbox/dcim/api/serializers.py#L1079
@RobinGeuze do you want to take this issue?
I'll grab this if not, seems like a simple enough fix

Resolving patch:
diff --git a/netbox/dcim/api/serializers.py b/netbox/dcim/api/serializers.py
--- a/netbox/dcim/api/serializers.py
+++ b/netbox/dcim/api/serializers.py
@@ -1076,7 +1076,7 @@ def get_path(self, obj):
 
 class VirtualChassisSerializer(NetBoxModelSerializer):
     url = serializers.HyperlinkedIdentityField(view_name='dcim-api:virtualchassis-detail')
-    master = NestedDeviceSerializer(required=False)
+    master = NestedDeviceSerializer(required=False, allow_null=True, default=None)
     member_count = serializers.IntegerField(read_only=True)
 
     class Meta:


Test patch:
diff --git a/netbox/dcim/tests/test_api.py b/netbox/dcim/tests/test_api.py
--- a/netbox/dcim/tests/test_api.py
+++ b/netbox/dcim/tests/test_api.py
@@ -2057,6 +2057,7 @@ def setUpTestData(cls):
 
         cls.bulk_update_data = {
             'domain': 'newdomain',
+            'master': None
         }
Repository: netbox-community/netbox

Issue:
link 'assigned' checkbox to device rather than ip
### NetBox version

v3.3.5

### Feature type

Change to existing functionality

### Proposed functionality

When searching for an IP, the result shows the 'assigned' green checkbox if an IP address is assigned to a device/vm/...
The current link of the green check is to the IP address object.
I like to propose to change that to the device/vm/... the IP is assigned to.

### Use case

When the checkbox is clicked, it is more intuitive to go to the device it is assigned to.
Now it requires 2 additional clicks to go to the device.


### Database changes

_No response_

### External dependencies

_No response_


Discussion:
@jeremystretch I can work on implementing this
Got around to digging into the code and familiarizing myself with this portion. I see that there are already two columns (that are just hidden by default) that show both A. the device, and B. the interface. 

I do agree that clicking the checkmark to go to the device would be more intuitive, however is it more intuitive to send the user to the device, or the interface? Or perhaps, a third solution: if the IP is listed as the primary IP of a device, send them to a device, otherwise send them to the interface? Thoughts?
The checkbox is very slim. The device or interface table makes the table wider.
To be honest, the interface view has less added value than then device view. I don't see a reason to link it to the interface.

Maybe we can link it to the interface tab of the device?

Resolving patch:
diff --git a/netbox/ipam/tables/ip.py b/netbox/ipam/tables/ip.py
--- a/netbox/ipam/tables/ip.py
+++ b/netbox/ipam/tables/ip.py
@@ -375,7 +375,7 @@ class IPAddressTable(TenancyColumnsMixin, NetBoxTable):
     )
     assigned = columns.BooleanColumn(
         accessor='assigned_object_id',
-        linkify=True,
+        linkify=lambda record: record.assigned_object.get_absolute_url(),
         verbose_name='Assigned'
     )
     tags = columns.TagColumn(


Test patch:
Repository: netbox-community/netbox

Issue:
Render Specified Front and Rear Port Colors During Cable Trace 
### NetBox version

v3.3.7

### Feature type

Change to existing functionality

### Proposed functionality

Currently it is possible to specify colors for Front and Rear Ports. However, when running a cable trace, the port colors are not reflected in the rendered SVG.  Cable colors can be specified and are already rendered during cable traces, it only makes sense that the same logic should apply for the Front and Rear Ports. Additionally, when no color is specified, the port color should revert to the current default. 

## Current Functionality
![Current Functionality Netbox](https://user-images.githubusercontent.com/31785616/201547734-59d5c121-0f96-4e1c-a880-d44082291507.png)

## Proposed Functionality
![Proposed Functionality Netbox](https://user-images.githubusercontent.com/31785616/201547772-8e37eef6-e21e-485b-a5a1-12ba65120920.png)


### Use case

Sometimes specific patch panel ports and/or network drop keystone colors are used to help identify specific traces in the real world. Adding this functionality would not only be simple but would further help users visualize and identify traces.

### Database changes

None

### External dependencies

None


Discussion:

Resolving patch:
diff --git a/netbox/dcim/svg/cables.py b/netbox/dcim/svg/cables.py
--- a/netbox/dcim/svg/cables.py
+++ b/netbox/dcim/svg/cables.py
@@ -166,7 +166,7 @@ def _get_color(cls, instance):
         """
         if hasattr(instance, 'parent_object'):
             # Termination
-            return 'f0f0f0'
+            return getattr(instance, 'color', 'f0f0f0') or 'f0f0f0'
         if hasattr(instance, 'device_role'):
             # Device
             return instance.device_role.color


Test patch:
Repository: netbox-community/netbox

Issue:
Color of front and rear ports not nullable on bulk edit
### NetBox version

V3.3.5

### Python version

3.9

### Steps to Reproduce

Colors defined on front and rearports are not nullable on bulk edit.

1. Create more than 2 front or rear ports
2. Select 2 or more front or rear ports and do a bulk edit
3. Color can be changed but not cleared

I can prepare a PR, if accepted

### Expected Behavior

Color field on bulk edit of front and rear ports should be nullable and the checkbox "Set Null" is visible

### Observed Behavior

Color field on bulk edit of front and rear ports are not nullable. The check box "Set Null" is missing


Discussion:

Resolving patch:
diff --git a/netbox/dcim/forms/bulk_edit.py b/netbox/dcim/forms/bulk_edit.py
--- a/netbox/dcim/forms/bulk_edit.py
+++ b/netbox/dcim/forms/bulk_edit.py
@@ -1218,7 +1218,7 @@ class FrontPortBulkEditForm(
     fieldsets = (
         (None, ('module', 'type', 'label', 'color', 'description', 'mark_connected')),
     )
-    nullable_fields = ('module', 'label', 'description')
+    nullable_fields = ('module', 'label', 'description', 'color')
 
 
 class RearPortBulkEditForm(
@@ -1229,7 +1229,7 @@ class RearPortBulkEditForm(
     fieldsets = (
         (None, ('module', 'type', 'label', 'color', 'description', 'mark_connected')),
     )
-    nullable_fields = ('module', 'label', 'description')
+    nullable_fields = ('module', 'label', 'description', 'color')
 
 
 class ModuleBayBulkEditForm(


Test patch:
Repository: netbox-community/netbox

Issue:
Sorting the changelog list by `object` causes exception
### NetBox version

v3.3.9

### Python version

3.10

### Steps to Reproduce

1. Make one change of an object to ensure there is a list
2. Go to the changelog
3. Click the object header
4. Refresh the page

### Expected Behavior

List with changes

### Observed Behavior

<class 'django.core.exceptions.FieldError'>

Field 'changed_object' does not generate an automatic reverse relation and therefore cannot be used for reverse querying. If it is a GenericForeignKey, consider adding a GenericRelation.

Python version: 3.10.6
NetBox version: 3.3.9


Discussion:
Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.
Hello arthanson!

Thanks for your reply. Unfortunately, I can't find what could be causing this error. I worked with NetBox as usual, adding and removing devices and changing devices. At one point, when I wanted to see the Change Log, I got this error. Before that everything worked.
@mlvgn are you able to provide a complete stack trace? (You can enable this by temporarily setting `DEBUG = True` in `configuration.py` and restarting NetBox.)
Hello, [jeremystretch](https://github.com/jeremystretch)!

I solved this problem:
1. Opened my user preferences
2. Moved to Table Configurations
3. Clicked the checkmark next to ObjectChangeTable (ordering: object_repr)
4. Saved
I replicated what causes it and updated the steps in the post.

The object column is sortable, but it will throw an exception when trying to sort by object_repr. Maybe the object column should just not be sortable? @jeremystretch?
> Maybe the object column should just not be sortable?

That seems like the correct approach IMO.

Resolving patch:
diff --git a/netbox/extras/tables/tables.py b/netbox/extras/tables/tables.py
--- a/netbox/extras/tables/tables.py
+++ b/netbox/extras/tables/tables.py
@@ -195,7 +195,8 @@ class ObjectChangeTable(NetBoxTable):
     object_repr = tables.TemplateColumn(
         accessor=tables.A('changed_object'),
         template_code=OBJECTCHANGE_OBJECT,
-        verbose_name='Object'
+        verbose_name='Object',
+        orderable=False
     )
     request_id = tables.TemplateColumn(
         template_code=OBJECTCHANGE_REQUEST_ID,


Test patch:
Repository: netbox-community/netbox

Issue:
Allow quick filter for device in modules
### NetBox version

v3.3.5

### Feature type

Change to existing functionality

### Proposed functionality

The [modules list](https://demo.netbox.dev/dcim/modules/) should allow `Quick search` to filter by `device` name when typing.

### Use case

quickly select only relevant modules

### Database changes

_No response_

### External dependencies

_No response_


Discussion:

Resolving patch:
diff --git a/netbox/dcim/filtersets.py b/netbox/dcim/filtersets.py
--- a/netbox/dcim/filtersets.py
+++ b/netbox/dcim/filtersets.py
@@ -1098,6 +1098,7 @@ def search(self, queryset, name, value):
         if not value.strip():
             return queryset
         return queryset.filter(
+            Q(device__name__icontains=value.strip()) |
             Q(serial__icontains=value.strip()) |
             Q(asset_tag__icontains=value.strip()) |
             Q(comments__icontains=value)


Test patch: