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

Issue:
Bulk assigning tags to interfaces deletes tagged VLANs
<!--
    NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED.

    This form is only for reproducible bugs. If you need assistance with
    NetBox installation, or if you have a general question, DO NOT open an
    issue. Instead, post to our mailing list:

        https://groups.google.com/forum/#!forum/netbox-discuss

    Please describe the environment in which you are running NetBox. Be sure
    that you are running an unmodified instance of the latest stable release
    before submitting a bug report, and that any plugins have been disabled.
-->
### Environment
* Python version: unknown - using a pre-installed system
* NetBox version: 2.8.7

<!--
    Describe in detail the exact steps that someone else can take to reproduce
    this bug using the current stable release of NetBox. Begin with the
    creation of any necessary database objects and call out every operation
    being performed explicitly. If reporting a bug in the REST API, be sure to
    reconstruct the raw HTTP request(s) being made: Don't rely on a client
    library such as pynetbox.
-->
### Steps to Reproduce
1. On a switch or other device with multiple interfaces, assign tagged VLANs to some or all interfaces.
2. Select some interfaces and "edit selected" to assign a tag to them.
3. Revisit the tagged VLAN assigments: they are gone on the interfaces which had tags assigned.

<!-- What did you expect to happen? -->
### Expected Behavior
Expected the VLAN tags not to be lost during bulk editing as long as the bulk editing doesn't change the tagged VLANs.


<!-- What happened instead? -->
### Observed Behavior
The interfaces where tags were assigned with bulk editing lost their existing tagged VLAN assignments.


Discussion:
I can reproduce this in the latest version.

Resolving patch:
diff --git a/netbox/utilities/views.py b/netbox/utilities/views.py
--- a/netbox/utilities/views.py
+++ b/netbox/utilities/views.py
@@ -721,8 +721,8 @@ def post(self, request, **kwargs):
 
                                 # ManyToManyFields
                                 elif isinstance(model_field, ManyToManyField):
-                                    getattr(obj, name).set(form.cleaned_data[name])
-
+                                    if form.cleaned_data[name].count() > 0:
+                                        getattr(obj, name).set(form.cleaned_data[name])
                                 # Normal fields
                                 elif form.cleaned_data[name] not in (None, ''):
                                     setattr(obj, name, form.cleaned_data[name])


Test patch:
Repository: netbox-community/netbox

Issue:
Mismatch between VM counts in cluster search results, and actual counts.
### Environment
* Python version: 3.8.2
* NetBox version: 2.8.9

### Steps to Reproduce
1. Search for a cluster in the search box.

### Expected Behavior
The virtual machines count to match the detail page.

### Observed Behavior
The virtual machines count was zero. The counts in the table after clicking "refine search" were correct (non-zero).

This feels similar to issue #4894.


Discussion:

Resolving patch:
diff --git a/netbox/netbox/views.py b/netbox/netbox/views.py
--- a/netbox/netbox/views.py
+++ b/netbox/netbox/views.py
@@ -34,6 +34,7 @@
 from tenancy.filters import TenantFilterSet
 from tenancy.models import Tenant
 from tenancy.tables import TenantTable
+from utilities.utils import get_subquery
 from virtualization.filters import ClusterFilterSet, VirtualMachineFilterSet
 from virtualization.models import Cluster, VirtualMachine
 from virtualization.tables import ClusterTable, VirtualMachineDetailTable
@@ -120,7 +121,10 @@
     # Virtualization
     ('cluster', {
         'permission': 'virtualization.view_cluster',
-        'queryset': Cluster.objects.prefetch_related('type', 'group'),
+        'queryset': Cluster.objects.prefetch_related('type', 'group').annotate(
+            device_count=get_subquery(Device, 'cluster'),
+            vm_count=get_subquery(VirtualMachine, 'cluster')
+        ),
         'filterset': ClusterFilterSet,
         'table': ClusterTable,
         'url': 'virtualization:cluster_list',


Test patch:
Repository: netbox-community/netbox

Issue:
Prefixes per VLAN no longer listed in VLANs list after upgrade to 2.9.2
<!--
    NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED.

    This form is only for reproducible bugs. If you need assistance with
    NetBox installation, or if you have a general question, DO NOT open an
    issue. Instead, post to our mailing list:

        https://groups.google.com/forum/#!forum/netbox-discuss

    Please describe the environment in which you are running NetBox. Be sure
    that you are running an unmodified instance of the latest stable release
    before submitting a bug report, and that any plugins have been disabled.
-->
### Environment
* Python version: 3.8.2
* NetBox version: 2.8.6 / 2.9.2

<!--
    Describe in detail the exact steps that someone else can take to reproduce
    this bug using the current stable release of NetBox. Begin with the
    creation of any necessary database objects and call out every operation
    being performed explicitly. If reporting a bug in the REST API, be sure to
    reconstruct the raw HTTP request(s) being made: Don't rely on a client
    library such as pynetbox.
-->
### Steps to Reproduce
1. [Netbox 2.8.6] Create VLAN Group with name "test"
2. [Netbox 2.8.6] Create VLAN with ID 1, name "test", group "test"
3. [Netbox 2.8.6] Create Prefix 10.0.0.0/24 with VLAN group "test" and vlan "test (1)".
4. [Netbox 2.8.6] Go to IPAM -> VLAN Groups -> test
5. [Netbox 2.8.6] Observe and take note of the "Prefixes" column for VLAN "test".
6. Upgrade Netbox from 2.8.6 to 2.9.2
7. [Netbox 2.9.2] Go to IPAM -> VLAN Groups -> test
8. [Netbox 2.9.2] Again, observe and take note of the "Prefixes" column for VLAN "test".


<!-- What did you expect to happen? -->
### Expected Behavior
Prefixes per VLAN are still listed in the "Prefixes" column after upgrade to Netbox 2.9.2.

<!-- What happened instead? -->
### Observed Behavior
Prefixes per VLAN are no longer listed in the "Prefixes" column after upgrade to Netbox 2.9.2.


Discussion:

Resolving patch:
diff --git a/netbox/ipam/tables.py b/netbox/ipam/tables.py
--- a/netbox/ipam/tables.py
+++ b/netbox/ipam/tables.py
@@ -99,7 +99,7 @@
 """
 
 VLAN_PREFIXES = """
-{% for prefix in record.prefixes.unrestricted %}
+{% for prefix in record.prefixes.all %}
     <a href="{% url 'ipam:prefix' pk=prefix.pk %}">{{ prefix }}</a>{% if not forloop.last %}<br />{% endif %}
 {% empty %}
     &mdash;


Test patch:
Repository: netbox-community/netbox

Issue:
Long Response Time for Viewing IP Addresses with A Large Number of Duplicate Assignments
### Environment
* Python version: 3.6.8 
* NetBox version: 2.8.6

### Steps to Reproduce
1. Create any IP Address in Netbox and assign it to a large number of interfaces (1000+)
2. View the IP Address object

![Capture](https://user-images.githubusercontent.com/33135168/94573233-81426100-0237-11eb-8b08-ff8cc8b3e88f.PNG)


<!-- What did you expect to happen? -->
### Expected Behavior
- The page to load faster
- The list of duplicate IP addresses to be paginated (similar to the changelog view on the home page)

<!-- What happened instead? -->
### Observed Behavior
- Long response time (3m15s for 16K duplicates)
   - We have a lot of access points....
- Gunicorn worker at 100% for the duration of the response



Discussion:
It probably makes sense to just cap the number of duplicates returned to, say, 10, and link to a filtered list to "see all duplicates" if there are more than that.
That seems reasonable and would work for my environment. 
Thanks for the quick reply!

Resolving patch:
diff --git a/netbox/ipam/views.py b/netbox/ipam/views.py
--- a/netbox/ipam/views.py
+++ b/netbox/ipam/views.py
@@ -527,7 +527,8 @@ def get(self, request, pk):
         # Exclude anycast IPs if this IP is anycast
         if ipaddress.role == IPAddressRoleChoices.ROLE_ANYCAST:
             duplicate_ips = duplicate_ips.exclude(role=IPAddressRoleChoices.ROLE_ANYCAST)
-        duplicate_ips_table = tables.IPAddressTable(list(duplicate_ips), orderable=False)
+        # Limit to a maximum of 10 duplicates displayed here
+        duplicate_ips_table = tables.IPAddressTable(duplicate_ips[:10], orderable=False)
 
         # Related IP table
         related_ips = IPAddress.objects.restrict(request.user, 'view').exclude(
@@ -547,6 +548,7 @@ def get(self, request, pk):
             'ipaddress': ipaddress,
             'parent_prefixes_table': parent_prefixes_table,
             'duplicate_ips_table': duplicate_ips_table,
+            'more_duplicate_ips': duplicate_ips.count() > 10,
             'related_ips_table': related_ips_table,
         })
 


Test patch:
Repository: netbox-community/netbox

Issue:
AttributeError raised on initialization when LDAP authentication is in place
### Environment
* Python version: 3.6.9
* NetBox version: 2.9.5

### Steps to Reproduce
1. Enable LDAP authentication and restart NetBox

### Expected Behavior
NetBox should start normally and LDAP authentication should work.

### Observed Behavior
An AttributeError exception is raised due to the change made in 23a9cb2fad6d75302e79e1fee8e6dcb66d6b3a9c


Discussion:

Resolving patch:
diff --git a/netbox/netbox/authentication.py b/netbox/netbox/authentication.py
--- a/netbox/netbox/authentication.py
+++ b/netbox/netbox/authentication.py
@@ -175,6 +175,6 @@ def __new__(cls, *args, **kwargs):
         # Enable logging for django_auth_ldap
         ldap_logger = logging.getLogger('django_auth_ldap')
         ldap_logger.addHandler(logging.StreamHandler())
-        ldap_logger.setLevel(logging.INFO if settings.DEBUG is False else logging.DEBUG)
+        ldap_logger.setLevel(logging.INFO)
 
         return obj
diff --git a/netbox/netbox/settings.py b/netbox/netbox/settings.py
--- a/netbox/netbox/settings.py
+++ b/netbox/netbox/settings.py
@@ -16,7 +16,7 @@
 # Environment setup
 #
 
-VERSION = '2.9.5'
+VERSION = '2.9.6'
 
 # Hostname
 HOSTNAME = platform.node()


Test patch:
Repository: netbox-community/netbox

Issue:
Plugins must define app_name in api/urls.py to be included in API root view
### Environment
* Python version: 3.6.9
* NetBox version: 2.9.7

### Steps to Reproduce
I'm actually not certain whether this is better classified as a bug or a lapse in the documentation, but I'm opting to propose it as a bug because I think it can be addressed by a code change.

1. Create/install a plugin which provides at least one REST API endpoint. (Assume the plugin's name is `myplugin`.)
2. Within `api/urls.py`, set `app_name = myplugin-api`
3. Visit `/api/plugins/` in the browser. The plugin should be included.
4. Remove the `app_name` definition from `api/urls.py`.
5. Visit `/api/plugins/` in the browser again. The plugin no longer appears.

### Expected Behavior
Plugin API endpoints should be detected automatically. AFAICT there's no reason a plugin should need to declare `app_name`. (The core apps do this, but only because they're being included dynamically.)

### Observed Behavior
Plugin API endpoints disappear from the list when `app_name` is not declared.

It seems like the need for the `app_name` variable could be obviated within `PluginsAPIRootView._get_plugin_entry()` by changing

```
api_app_name = import_object(f"{plugin}.api.urls.app_name")
```

to

```
api_app_name = f'{app_config.name}-api'
```

This actually raises another point: the full URL name for a plugin API endpoint is currently in the format `plugins-api:myplugin-api:url-name`, which seems a bit unwieldy: `plugins-api:myplugin:url-name` should suffice. However, this would be a breaking change for any plugins which rely on reverse URL resolution to their REST API endpoints.


Discussion:

Resolving patch:
diff --git a/netbox/extras/plugins/views.py b/netbox/extras/plugins/views.py
--- a/netbox/extras/plugins/views.py
+++ b/netbox/extras/plugins/views.py
@@ -10,8 +10,6 @@
 from rest_framework.reverse import reverse
 from rest_framework.views import APIView
 
-from extras.plugins.utils import import_object
-
 
 class InstalledPluginsAdminView(View):
     """
@@ -62,11 +60,7 @@ def get_view_name(self):
     @staticmethod
     def _get_plugin_entry(plugin, app_config, request, format):
         # Check if the plugin specifies any API URLs
-        api_app_name = import_object(f"{plugin}.api.urls.app_name")
-        if api_app_name is None:
-            # Plugin does not expose an API
-            return None
-
+        api_app_name = f'{app_config.name}-api'
         try:
             entry = (getattr(app_config, 'base_url', app_config.label), reverse(
                 f"plugins-api:{api_app_name}:api-root",


Test patch:
Repository: netbox-community/netbox

Issue:
Allow editing of Site in device bulk edit
### Environment
* Python version: 3.6.8
* NetBox version: 2.10.4

### Proposed Functionality
When bulk editing devices, allow changing sites. So, go to Devices -> Search for your desired term -> Select devices wanting to edit -> Edit Selected -> Here Site would be added as an editable field.

### Use Case
- Moving multiple devices between sites
- Creating a more granular structure where smaller sites are created and devices need to be moved into these smaller sites

### Database Changes
None.

### External Dependencies
None.

The only thing I can see as a challenge here is when a device is racked. It would mean you would either have to not allow changing the site when devices are racked, or move it out from the rack and set the rack space as empty and available.


Discussion:
I added the following to the DeviceBulkEditForm in `netbox/dcim/forms.py` just to test:
```
    site = DynamicModelChoiceField(
        queryset=Site.objects.all(),
        required=False
    )
```
This seems to do the trick as it allows me to move devices from one site to another in bulk. It also fails on validation if trying to  move a racked device, a behaviour I feel is sensible and predictable. Any objections to "accepting" this feature?
I really missed this feature this week when I had to change approx. 40 devices, editing one by one. I just want to add that not only sites should be added but at least also rack groups and racks.
@dreng You should create a separate FR for editing rack groups and racks to keep this to the one feature requested.

Resolving patch:
diff --git a/netbox/dcim/forms.py b/netbox/dcim/forms.py
--- a/netbox/dcim/forms.py
+++ b/netbox/dcim/forms.py
@@ -2088,6 +2088,10 @@ class DeviceBulkEditForm(BootstrapMixin, AddRemoveTagsForm, CustomFieldBulkEditF
         queryset=DeviceRole.objects.all(),
         required=False
     )
+    site = DynamicModelChoiceField(
+        queryset=Site.objects.all(),
+        required=False
+    )
     tenant = DynamicModelChoiceField(
         queryset=Tenant.objects.all(),
         required=False


Test patch:
Repository: netbox-community/netbox

Issue:
Virtual chassis search displays duplicate entries
### NetBox version

v2.10.6

### Python version

3.8

### Steps to Reproduce

1. Create a device named test-vc-1-1
2. Create a device named test-vc-1-2
3. Create a virtual chassis named test-vc-1 and bundle the two device created in 1. and 2.
4. In the virtual chassis view perform a search by name using test-vc-1

### Expected Behavior

The list view should display only one entry for the virtual chassis (check the screenshot of the search using Nebox 2.9 release)

### Observed Behavior

The list view displays twice the same entry for the virtual chassis, one per member (check the screenshot of the search using Nebox 2.10.6 release)

### Expected behaviour in netbox 2.9

![Netbox 2.9](https://user-images.githubusercontent.com/4469833/111668228-d558f600-8815-11eb-9e81-def201f1e744.png)

### Observed behaviour in netbox 2.10

![image](https://user-images.githubusercontent.com/4469833/111668410-033e3a80-8816-11eb-8768-78493606ad7c.png)

### Solution hint

After some code investigation it seems that the `VirtualChassisFilterSet.search` method in `dcim/filter.py` has something wrong with the [forged queryset](https://github.com/netbox-community/netbox/blob/91fe80f73c12bb4182ee892ca612252e9a30126b/netbox/dcim/filters.py#L1078).

```python
    def search(self, queryset, name, value):
        if not value.strip():
            return queryset
        qs_filter = (
            Q(name__icontains=value) |
            Q(members__name__icontains=value) |
            Q(domain__icontains=value)
        )
        return queryset.filter(qs_filter)
```

When you modify the queryset with the following code, the entry is not duplicated anymore in the WebUI.

```python
    def search(self, queryset, name, value):
        if not value.strip():
            return queryset
        qs_filter = (
            Q(name__icontains=value) |
            Q(members__name__icontains=value) |
            Q(domain__icontains=value)
        )
        return queryset.filter(qs_filter).distinct() # adding distinct de-duplicate the VC
```


Discussion:
I confirm to have seen the same behavior and I indeed would like have it fixed as well ! Nice finding !
Yep, funny enough I was demoing netbox for a colleague today and experienced this as well. 

We are running 2.10.6
same problem here !!! easy fix
Open for volunteers
@jeremystretch I can take the lead on this one if you agree. Quick and easy fix.

Resolving patch:
diff --git a/netbox/dcim/filters.py b/netbox/dcim/filters.py
--- a/netbox/dcim/filters.py
+++ b/netbox/dcim/filters.py
@@ -1075,7 +1075,7 @@ def search(self, queryset, name, value):
             Q(members__name__icontains=value) |
             Q(domain__icontains=value)
         )
-        return queryset.filter(qs_filter)
+        return queryset.filter(qs_filter).distinct()
 
 
 class CableFilterSet(BaseFilterSet):


Test patch:
Repository: netbox-community/netbox

Issue:
Cable Trace view crash
### NetBox version

v2.10.7

### Python version

3.8

### Steps to Reproduce

This is the only path I have tested:
1. Create a circuit
2. Create an interface and a Device to link to
3. Create a Site
5: Create a Circuit Termination Site (Side A) in the circuit record
6: Create an Interface termination (Side B) in the circuit record
7: Upgrade to netbox v2.10.7
8: Click on the Trace route icon in the Circuits view


### Expected Behavior

Trace route tamplete should display instead of crashing the page

### Observed Behavior


The Trace route view will crash on TypeError: failed to unpack non-iterable:

netbox/dcim/views.py: PathTraceView
```python
total_length, is_definitive = path.get_total_length if path else (None, False)
```

This fixes the issue for me:
```python
        try:
            total_length, is_definitive = path.get_total_length if path else (None, False)
        except TypeError as te:
            total_length, is_definitive = (None, False)
            
```
 I have checked the Cable model objects in the netbox shell and they show _path ids before and after upgrading netbox and it shows an id (which means that a path exists for this cable).
 
 Also I ran the management command that checks for missing paths and it does not show any issues.


Discussion:

Resolving patch:
diff --git a/netbox/dcim/views.py b/netbox/dcim/views.py
--- a/netbox/dcim/views.py
+++ b/netbox/dcim/views.py
@@ -2135,7 +2135,7 @@ def get_extra_context(self, request, instance):
                 path = related_paths.first()
 
         # Get the total length of the cable and whether the length is definitive (fully defined)
-        total_length, is_definitive = path.get_total_length if path else (None, False)
+        total_length, is_definitive = path.get_total_length() if path else (None, False)
 
         return {
             'path': path,
diff --git a/netbox/netbox/settings.py b/netbox/netbox/settings.py
--- a/netbox/netbox/settings.py
+++ b/netbox/netbox/settings.py
@@ -16,7 +16,7 @@
 # Environment setup
 #
 
-VERSION = '2.10.7'
+VERSION = '2.10.8'
 
 # Hostname
 HOSTNAME = platform.node()


Test patch:
Repository: netbox-community/netbox

Issue:
Add interface type for SFP56 (50GE)
### NetBox version

v2.11.0-beta

### Python version

3.9

### Steps to Reproduce

Hello Team,

we have found a false speed in the transceiver-list of the [public netbox beta](beta.netbox.de).
In the list are two QSPF28 Transceivers with 50G and 100G, but there should be only one with 100G. Also the Transceiver-Type `SFP56 (50G)` is missing. We have proposed an update to this List.

Thanks for the awesome project,
Adrian & Hendrik

![Port-Speed](https://user-images.githubusercontent.com/6275838/114903774-6c19d200-9e17-11eb-83be-9460e462b6d9.png)

### Expected Behavior

Correct values for all interface types

### Observed Behavior

false values for some interface types


Discussion:
> In the list are two QSPF28 Transceivers with 50G and 100G, but there should be only one with 100G.

QSFP28 also [supports 50GE](https://www.fs.com/c/50g-qsfp28-3793). It belongs in the list.

Resolving patch:
diff --git a/netbox/dcim/choices.py b/netbox/dcim/choices.py
--- a/netbox/dcim/choices.py
+++ b/netbox/dcim/choices.py
@@ -662,6 +662,7 @@ class InterfaceTypeChoices(ChoiceSet):
     TYPE_10GE_XENPAK = '10gbase-x-xenpak'
     TYPE_10GE_X2 = '10gbase-x-x2'
     TYPE_25GE_SFP28 = '25gbase-x-sfp28'
+    TYPE_50GE_SFP56 = '50gbase-x-sfp56'
     TYPE_40GE_QSFP_PLUS = '40gbase-x-qsfpp'
     TYPE_50GE_QSFP28 = '50gbase-x-sfp28'
     TYPE_100GE_CFP = '100gbase-x-cfp'
@@ -766,6 +767,7 @@ class InterfaceTypeChoices(ChoiceSet):
                 (TYPE_10GE_XENPAK, 'XENPAK (10GE)'),
                 (TYPE_10GE_X2, 'X2 (10GE)'),
                 (TYPE_25GE_SFP28, 'SFP28 (25GE)'),
+                (TYPE_50GE_SFP56, 'SFP56 (50GE)'),
                 (TYPE_40GE_QSFP_PLUS, 'QSFP+ (40GE)'),
                 (TYPE_50GE_QSFP28, 'QSFP28 (50GE)'),
                 (TYPE_100GE_CFP, 'CFP (100GE)'),


Test patch: