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

Issue:
Add Search filter to VLAN Group overview
### NetBox version

2.11.2

### Feature type

New functionality

### Proposed functionality

Add the ability to do a text search in the VLAN Group overview <netbox>/ipam/vlan-groups/.

### Use case

With a large number of VLAN groups the ability to search the vlan group name would be very useful.

### Database changes

None

### External dependencies

None


Discussion:
I believe it would be a simple
```
q = forms.CharField(
        required=False,
        label='Search'
    )
```
in `ipam/forms.py` under VLANGroupFilterForm.
This requires the introduction of a `q` filter on VLANGroupFilterForm as well, to specify what fields are to be evaluated.

Resolving patch:
diff --git a/netbox/ipam/filtersets.py b/netbox/ipam/filtersets.py
--- a/netbox/ipam/filtersets.py
+++ b/netbox/ipam/filtersets.py
@@ -536,6 +536,10 @@ def _assigned_to_interface(self, queryset, name, value):
 
 
 class VLANGroupFilterSet(OrganizationalModelFilterSet):
+    q = django_filters.CharFilter(
+        method='search',
+        label='Search',
+    )
     scope_type = ContentTypeFilter()
     region = django_filters.NumberFilter(
         method='filter_scope'
@@ -563,6 +567,15 @@ class Meta:
         model = VLANGroup
         fields = ['id', 'name', 'slug', 'description', 'scope_id']
 
+    def search(self, queryset, name, value):
+        if not value.strip():
+            return queryset
+        qs_filter = (
+            Q(name__icontains=value) |
+            Q(description__icontains=value)
+        )
+        return queryset.filter(qs_filter)
+
     def filter_scope(self, queryset, name, value):
         return queryset.filter(
             scope_type=ContentType.objects.get(model=name),
diff --git a/netbox/ipam/forms.py b/netbox/ipam/forms.py
--- a/netbox/ipam/forms.py
+++ b/netbox/ipam/forms.py
@@ -1270,6 +1270,10 @@ class Meta:
 
 
 class VLANGroupFilterForm(BootstrapMixin, forms.Form):
+    q = forms.CharField(
+        required=False,
+        label=_('Search')
+    )
     region = DynamicModelMultipleChoiceField(
         queryset=Region.objects.all(),
         required=False,


Test patch:
Repository: netbox-community/netbox

Issue:
ValueError exception when migrating to v2.11.5 with one or more VRFs defined
### NetBox version

v2.11.5

### Python version

3.7

### Steps to Reproduce

1. Start with NetBox v2.11.4 or earlier
2. Create a VRF
3. Create one or more prefixes within that VRF
4. Upgrade to NetBox v2.11.5

### Expected Behavior

The upgrade should complete successfully.

### Observed Behavior

A ValueError exception is raised due to a bug in the way VRFs are retrieved in the migration:

```
ValueError: Cannot query "VRF object (1)": Must be "VRF" instance.
```

It seems that Django does not like using the "faked" VRF instance returned by `apps.get_model()` for filtering. It's being cast as a string by `filter()` rather than its numeric ID beign evaluated.

```python
VRF = apps.get_model('ipam', 'VRF')
...
    # Iterate through all VRFs, rebuilding each
    for vrf in VRF.objects.all():
        rebuild_prefixes(vrf)
```

Altering the migration to reference the ID directly resolves the issue:

```python
        rebuild_prefixes(vrf.pk)
```

```
$ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, circuits, contenttypes, dcim, extras, ipam, secrets, sessions, taggit, tenancy, users, virtualization
Running migrations:
  Applying ipam.0048_prefix_populate_depth_children...
Updating 3157 prefixes...
 OK
```


Discussion:

Resolving patch:
diff --git a/netbox/ipam/management/commands/rebuild_prefixes.py b/netbox/ipam/management/commands/rebuild_prefixes.py
--- a/netbox/ipam/management/commands/rebuild_prefixes.py
+++ b/netbox/ipam/management/commands/rebuild_prefixes.py
@@ -22,6 +22,6 @@ def handle(self, *model_names, **options):
         for vrf in VRF.objects.all():
             vrf_count = Prefix.objects.filter(vrf=vrf).count()
             self.stdout.write(f'VRF {vrf}: {vrf_count} prefixes...')
-            rebuild_prefixes(vrf)
+            rebuild_prefixes(vrf.pk)
 
         self.stdout.write(self.style.SUCCESS('Finished.'))
diff --git a/netbox/ipam/migrations/0048_prefix_populate_depth_children.py b/netbox/ipam/migrations/0048_prefix_populate_depth_children.py
--- a/netbox/ipam/migrations/0048_prefix_populate_depth_children.py
+++ b/netbox/ipam/migrations/0048_prefix_populate_depth_children.py
@@ -20,7 +20,7 @@ def populate_prefix_hierarchy(apps, schema_editor):
 
     # Iterate through all VRFs, rebuilding each
     for vrf in VRF.objects.all():
-        rebuild_prefixes(vrf)
+        rebuild_prefixes(vrf.pk)
 
 
 class Migration(migrations.Migration):
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.11.5'
+VERSION = '2.11.6'
 
 # Hostname
 HOSTNAME = platform.node()


Test patch:
Repository: netbox-community/netbox

Issue:
Include docs in main release package
### NetBox version

v2.11

### Feature type

New functionality

### Proposed functionality

Include the HTML rendered online documentation available on https://netbox.readthedocs.io/en/stable/ within the main package of the netbox.

The goal is to adapt the URL <Docs> seen bellow to the HTML local documentation and have it as rendered docs available at /docs on a live instance
 ![image](https://user-images.githubusercontent.com/44149262/116776610-85528d80-aa69-11eb-9543-d234960a13c3.png)



### Use case

The following use cases are applicable:
* Provide the correct documentation that is always related to the specific version being used, instead of the online version that refers the latest version.
* Provide access to the documentation to system installed in a isolated management environment that do not have internet access.


### Database changes

none.
Only file structure changes to create a new /docs directory and changing the url.

### External dependencies

_No response_


Discussion:
It seems like the best way to approach this is to have the upgrade script build the docs locally. This means that `mkdocs` and its related packages (see `docs/requirements.txt`) will become required dependencies.

We'll also need to tweak the way static file collection is currently handled, introducing a new `docs/` path for the rendered documentation.

Resolving patch:
diff --git a/netbox/netbox/settings.py b/netbox/netbox/settings.py
--- a/netbox/netbox/settings.py
+++ b/netbox/netbox/settings.py
@@ -379,10 +379,11 @@ def _setting(name, default=None):
 
 # Static files (CSS, JavaScript, Images)
 STATIC_ROOT = BASE_DIR + '/static'
-STATIC_URL = '/{}static/'.format(BASE_PATH)
+STATIC_URL = f'/{BASE_PATH}static/'
 STATICFILES_DIRS = (
-    os.path.join(BASE_DIR, "project-static", "dist"),
-    os.path.join(BASE_DIR, "project-static", "img"),
+    os.path.join(BASE_DIR, 'project-static', 'dist'),
+    os.path.join(BASE_DIR, 'project-static', 'img'),
+    ('docs', os.path.join(BASE_DIR, 'project-static', 'docs')),  # Prefix with /docs
 )
 
 # Media


Test patch:
Repository: netbox-community/netbox

Issue:
/32 IP's not automatically represented in /32 subnet.
### NetBox version

v2.11.7

### Python version

3.7

### Steps to Reproduce

1) Have a /32 IP address,

2) Create a /32 Subnet for that IP address

3) In the new subnet on the IP addresses tab observe IP's. 

### Expected Behavior

IP address reference should be observed and not the ability to assign an IP address in the subnet.

### Observed Behavior

'Available IP' Button is present instead of a reference to the IP address as per 1).


Discussion:
Why shouldn't a user be able to create a /32 IP address for assignment to an interface in addition to a /32 route to advertise that address?
I think the issue here is that the /32 IP address gets created in the /32 subnet, but then does not display when navigating back to the Subnet

Example:

1. Make /32 Prefix

![image](https://user-images.githubusercontent.com/32685892/122830132-03c9fe00-d33c-11eb-8810-e45c5e5680d5.png)

2. Make /32 IP address within that prefix

![image](https://user-images.githubusercontent.com/32685892/122830200-1d6b4580-d33c-11eb-880d-d052227ebd61.png)

3. Go back to parent prefix, newly created IP address does not display under /32 prefixes IP address's, however IP address has been created.

![image](https://user-images.githubusercontent.com/32685892/122830314-48559980-d33c-11eb-8413-ac92c17e607a.png)
Sorry I should have included pictures. We have no issue with duplicate /32's just that they are not displaying within a subnet as per WillIrvine's images above.

Hi

https://github.com/netbox-community/netbox/issues/6455#issuecomment-855275592

This solution seems to work and AFAIA does not look to cause any undesired issues.
This looks to however be more of a design question as expressed by Jeremy - Should a /32 Prefix contain a /32 IP.

I think it should as people are using IP's and Prefix's for separate purposes, and it maintains a familiar workflow to track both individually. But if not we should at least limit the UI from displaying that there is 1 available address within the prefix.

Happy to put in a PR for this if accepted.

I also ran into this. We are using prefixes to document NAT translations (even though netbox doesn't support it specifically), and, it's perfectly valid to have a 1-1 nat with a /32 prefix, i.e. 1-1 NAT. However, the single IP Address in the prefix gets lost the way it is coded currently.

Resolving patch:
diff --git a/netbox/ipam/lookups.py b/netbox/ipam/lookups.py
--- a/netbox/ipam/lookups.py
+++ b/netbox/ipam/lookups.py
@@ -151,7 +151,7 @@ def as_sql(self, qn, connection):
         lhs, lhs_params = self.process_lhs(qn, connection)
         rhs, rhs_params = self.process_rhs(qn, connection)
         params = lhs_params + rhs_params
-        return 'CAST(HOST(%s) AS INET) << %s' % (lhs, rhs), params
+        return 'CAST(HOST(%s) AS INET) <<= %s' % (lhs, rhs), params
 
 
 class NetFamily(Transform):


Test patch:
Repository: netbox-community/netbox

Issue:
Page title + favicon in API pages
### NetBox version

v3.0-beta1

### Feature type

Change to existing functionality

### Proposed functionality

Add a favicon to both GraphiQL workspace and REST API. Plus add a page title to the GraphiQL playground.

### Use case

When testing Netbox API calls the tabs in a browser do not stand out very recognizable. The page title for the REST API pages reflects the path one is on. The GraphiQL playground has no title so it renders the full query URL in the tab title.

### Database changes

N/A

### External dependencies

N/A


Discussion:
@sdktr want to try taking this on? I'm not really sure how involved it would be.
While we're at it we should see if it's feasible to serve the GraphiQL UI's static resources locally (as opposed to via a CDN), to better support isolated NetBox deployments.
@jeremystretch - I'm not sure there is a clean solution for that other than creating a pull request for graphene-django or forking it. Maybe it's possible to overwrite the path to the template and having a local version with the changes (local resources, favicon and title). 

https://github.com/graphql-python/graphene-django/blob/e7f7d8da07ba1020f9916153f17e97b0ec037712/graphene_django/views.py#L58

But from my quick look any solution (including the above) would require monkey patching which seems like a bad idea.
We're already [subclassing the stock GraphQLView](https://github.com/netbox-community/netbox/blob/22d160b1da32e46399a5cd20858b34c9ea4ffa2d/netbox/netbox/graphql/views.py#L11), so it should be pretty easy to swap in our own template. The [template](https://github.com/graphql-python/graphene-django/blob/main/graphene_django/templates/graphene/graphiql.html) actually looks pretty minimal; should be easy to tweak. We just need to ensure we keep resources in sync for future releases; that will be the more tricky part.

Resolving patch:
diff --git a/netbox/netbox/graphql/views.py b/netbox/netbox/graphql/views.py
--- a/netbox/netbox/graphql/views.py
+++ b/netbox/netbox/graphql/views.py
@@ -12,6 +12,8 @@ class GraphQLView(GraphQLView_):
     """
     Extends graphene_django's GraphQLView to support DRF's token-based authentication.
     """
+    graphiql_template = 'graphiql.html'
+
     def dispatch(self, request, *args, **kwargs):
 
         # Enforce GRAPHQL_ENABLED


Test patch:
Repository: netbox-community/netbox

Issue:
Adding Power Port Types C21/C22
### NetBox version

v2.11.3

### Feature type

Data model extension

### Proposed functionality

Adding support in the power port types field for the C21/C22 form factor end points.
Governed under [IEC_60320](https://en.wikipedia.org/wiki/IEC_60320)

### Use case

[Dell MX7000](https://www.dell.com/support/manuals/en-us/poweredge-mx7000/pemx7000_ts_pub/psu-specifications?guid=guid-c478c564-a848-43b4-b4cd-be33d965bace&lang=en-us) chassis and it uses C22 power ports in it's PSUs. C21 would be the connector counter part if that's applicable in another field type.

### Database changes

N/A. New type in existing field.

### External dependencies

N/A


Discussion:
I've got a PR on this, see my note though.

Resolving patch:
diff --git a/netbox/dcim/choices.py b/netbox/dcim/choices.py
--- a/netbox/dcim/choices.py
+++ b/netbox/dcim/choices.py
@@ -252,6 +252,7 @@ class PowerPortTypeChoices(ChoiceSet):
     TYPE_IEC_C14 = 'iec-60320-c14'
     TYPE_IEC_C16 = 'iec-60320-c16'
     TYPE_IEC_C20 = 'iec-60320-c20'
+    TYPE_IEC_C22 = 'iec-60320-c22'
     # IEC 60309
     TYPE_IEC_PNE4H = 'iec-60309-p-n-e-4h'
     TYPE_IEC_PNE6H = 'iec-60309-p-n-e-6h'
@@ -351,6 +352,7 @@ class PowerPortTypeChoices(ChoiceSet):
             (TYPE_IEC_C14, 'C14'),
             (TYPE_IEC_C16, 'C16'),
             (TYPE_IEC_C20, 'C20'),
+            (TYPE_IEC_C22, 'C22'),
         )),
         ('IEC 60309', (
             (TYPE_IEC_PNE4H, 'P+N+E 4H'),
@@ -467,6 +469,7 @@ class PowerOutletTypeChoices(ChoiceSet):
     TYPE_IEC_C13 = 'iec-60320-c13'
     TYPE_IEC_C15 = 'iec-60320-c15'
     TYPE_IEC_C19 = 'iec-60320-c19'
+    TYPE_IEC_C21 = 'iec-60320-c21'
     # IEC 60309
     TYPE_IEC_PNE4H = 'iec-60309-p-n-e-4h'
     TYPE_IEC_PNE6H = 'iec-60309-p-n-e-6h'
@@ -558,6 +561,7 @@ class PowerOutletTypeChoices(ChoiceSet):
             (TYPE_IEC_C13, 'C13'),
             (TYPE_IEC_C15, 'C15'),
             (TYPE_IEC_C19, 'C19'),
+            (TYPE_IEC_C21, 'C21'),
         )),
         ('IEC 60309', (
             (TYPE_IEC_PNE4H, 'P+N+E 4H'),


Test patch:
Repository: netbox-community/netbox

Issue:
Example ADMINS should show a tuple
### Change Type

Correction

### Area

Configuration parameters

### Proposed Changes

[configuration.example.py](https://github.com/netbox-community/netbox/blob/v2.11.10/netbox/netbox/configuration.example.py#L69-L73) says "Specify one or more name and email address tuples representing NetBox administrators"

However the example given shows a list, not a tuple:

```
    # ['John Doe', 'jdoe@example.com'],
```

This does work, but a tuple would be correct according to the [Django documentation](https://docs.djangoproject.com/en/3.2/ref/settings/#admins)


Discussion:

Resolving patch:
diff --git a/netbox/netbox/configuration.example.py b/netbox/netbox/configuration.example.py
--- a/netbox/netbox/configuration.example.py
+++ b/netbox/netbox/configuration.example.py
@@ -69,7 +69,7 @@
 # Specify one or more name and email address tuples representing NetBox administrators. These people will be notified of
 # application errors (assuming correct email settings are provided).
 ADMINS = [
-    # ['John Doe', 'jdoe@example.com'],
+    # ('John Doe', 'jdoe@example.com'),
 ]
 
 # URL schemes that are allowed within links in NetBox


Test patch:
Repository: netbox-community/netbox

Issue:
Add front/rear port URM connector type
### NetBox version

v2.11.12

### Feature type

Change to existing functionality

### Proposed functionality

Please add the [URM connector](https://de.wikipedia.org/wiki/LWL-Steckverbinder#URM) to the list of available types for front and rear ports.

There are URM-P2, URM-P4 and URM-P8 connectors available.

### Use case

Adding those connectors would improve the possibilities to design a data center with a high density of fibre optics with a minimum of needed space.

### Database changes

None

### External dependencies

None


Discussion:
One thing I like about maintaining NetBox is that I keep learning stuff like this exists.

Resolving patch:
diff --git a/netbox/dcim/choices.py b/netbox/dcim/choices.py
--- a/netbox/dcim/choices.py
+++ b/netbox/dcim/choices.py
@@ -958,6 +958,9 @@ class PortTypeChoices(ChoiceSet):
     TYPE_SPLICE = 'splice'
     TYPE_CS = 'cs'
     TYPE_SN = 'sn'
+    TYPE_URM_P2 = 'urm-p2'
+    TYPE_URM_P4 = 'urm-p4'
+    TYPE_URM_P8 = 'urm-p8'
 
     CHOICES = (
         (
@@ -998,6 +1001,9 @@ class PortTypeChoices(ChoiceSet):
                 (TYPE_ST, 'ST'),
                 (TYPE_CS, 'CS'),
                 (TYPE_SN, 'SN'),
+                (TYPE_URM_P2, 'URM-P2'),
+                (TYPE_URM_P4, 'URM-P4'),
+                (TYPE_URM_P8, 'URM-P8'),
                 (TYPE_SPLICE, 'Splice'),
             )
         )


Test patch:
Repository: netbox-community/netbox

Issue:
Point users to discussion group on errors
### Change Type

Correction

### Area

Administration/development

### Proposed Changes

There are a couple of error messages that still point users to the google mailing list if they encounter problems:
* `netbox/utilities/management/commands/makemigrations.py`
* `netbox/templates/500.html`

I suggest pointing these to github discussions instead.

Elsewhere (in CONTRIBUTING.md) it says:

> we're encouraging people to use GitHub discussions where possible, as it's much easier for newcomers to review past discussions.


Discussion:

Resolving patch:
diff --git a/netbox/utilities/management/commands/makemigrations.py b/netbox/utilities/management/commands/makemigrations.py
--- a/netbox/utilities/management/commands/makemigrations.py
+++ b/netbox/utilities/management/commands/makemigrations.py
@@ -21,8 +21,8 @@ def handle(self, *args, **kwargs):
             raise CommandError(
                 "This command is available for development purposes only. It will\n"
                 "NOT resolve any issues with missing or unapplied migrations. For assistance,\n"
-                "please post to the NetBox mailing list:\n"
-                "    https://groups.google.com/g/netbox-discuss"
+                "please post to the NetBox discussion forum on GitHub:\n"
+                "    https://github.com/netbox-community/netbox/discussions"
             )
 
         super().handle(*args, **kwargs)


Test patch:
Repository: netbox-community/netbox

Issue:
Decimal values for cable lengths are not allowed in bulk edit
### NetBox version

v3.0.0

### Python version

3.7

### Steps to Reproduce

1. Navigate to .../dcim/cables/
2. Mark a selection of cables and click on the "Edit Selected" button
3. Set Length to for example, '1.5' and Length unit to 'Meters'

### Expected Behavior

According to enhancement #6154, cable lengths should now allow decimal values.

### Observed Behavior

NetBox responds with the following warning "Please enter a valid value. The two nearest valid values are 1 and 2."


Discussion:
CableModel specifies a Decimal: https://github.com/netbox-community/netbox/blob/db2993035d03552a78ca99f1f243fbec9d08493a/netbox/dcim/models/cables.py#L77

The CableBulkEditForm specifies the Integer: https://github.com/netbox-community/netbox/blob/db2993035d03552a78ca99f1f243fbec9d08493a/netbox/dcim/forms.py#L4589

Can you assign this to me @jeremystretch so I can propose a PR?

Resolving patch:
diff --git a/netbox/dcim/forms.py b/netbox/dcim/forms.py
--- a/netbox/dcim/forms.py
+++ b/netbox/dcim/forms.py
@@ -4586,8 +4586,8 @@ class CableBulkEditForm(BootstrapMixin, AddRemoveTagsForm, CustomFieldModelBulkE
     color = ColorField(
         required=False
     )
-    length = forms.IntegerField(
-        min_value=1,
+    length = forms.DecimalField(
+        min_value=0,
         required=False
     )
     length_unit = forms.ChoiceField(


Test patch:
Repository: netbox-community/netbox

Issue:
`applied_filters` template tag does not handle `null_option` on form fields
### NetBox version

v3.0.2-dev

### Python version

3.9

### Steps to Reproduce

Prior to 2a293d5, you won't be able to reproduce this because `null_option` is not properly handled in the UI. After updating...

1. Navigate to IPAM → IP Addresses → Filter
2. Select 'Global' VRF in 'Available VRFs' field
3. Click Search

### Expected Behavior

When `null_option` is present on a selected form field and is not `None`, the applied filters should display the `null_option` value.

### Observed Behavior

`KeyError` is raised because `vrf_id` is not in the cleaned form data.


Discussion:

Resolving patch:
diff --git a/netbox/utilities/forms/fields.py b/netbox/utilities/forms/fields.py
--- a/netbox/utilities/forms/fields.py
+++ b/netbox/utilities/forms/fields.py
@@ -477,3 +477,13 @@ class DynamicModelMultipleChoiceField(DynamicModelChoiceMixin, forms.ModelMultip
     """
     filter = django_filters.ModelMultipleChoiceFilter
     widget = widgets.APISelectMultiple
+
+    def clean(self, value):
+        """
+        When null option is enabled and "None" is sent as part of a form to be submitted, it is sent as the
+        string 'null'.  This will check for that condition and gracefully handle the conversion to a NoneType.
+        """
+        if self.null_option is not None and settings.FILTERS_NULL_CHOICE_VALUE in value:
+            value = [v for v in value if v != settings.FILTERS_NULL_CHOICE_VALUE]
+            return [None, *value]
+        return super().clean(value)
diff --git a/netbox/utilities/forms/utils.py b/netbox/utilities/forms/utils.py
--- a/netbox/utilities/forms/utils.py
+++ b/netbox/utilities/forms/utils.py
@@ -1,6 +1,7 @@
 import re
 
 from django import forms
+from django.conf import settings
 from django.forms.models import fields_for_model
 
 from utilities.choices import unpack_grouped_choices
@@ -120,13 +121,20 @@ def get_selected_values(form, field_name):
     if not hasattr(form, 'cleaned_data'):
         form.is_valid()
     filter_data = form.cleaned_data.get(field_name)
-
+    field = form.fields[field_name]
     # Selection field
-    if hasattr(form.fields[field_name], 'choices'):
+    if hasattr(field, 'choices'):
         try:
-            choices = dict(unpack_grouped_choices(form.fields[field_name].choices))
+            choices = unpack_grouped_choices(field.choices)
+
+            if hasattr(field, 'null_option'):
+                # If the field has a `null_option` attribute set and it is selected,
+                # add it to the field's grouped choices.
+                if field.null_option is not None and None in filter_data:
+                    choices.append((settings.FILTERS_NULL_CHOICE_VALUE, field.null_option))
+
             return [
-                label for value, label in choices.items() if str(value) in filter_data
+                label for value, label in choices if str(value) in filter_data or None in filter_data
             ]
         except TypeError:
             # Field uses dynamic choices. Show all that have been populated.


Test patch: