internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: jazzband/django-axes

Issue:
Username is not present in admin detail pages
As of now every model-admin of this packages defines the `fieldsets` options without providing the `username` field, this causes the field to not being displayed in any "detail" page.

https://github.com/jazzband/django-axes/blob/fcdeb4ae3f11724b99da54dfa61df90abcf54f7b/axes/admin.py#L25-L29

https://github.com/jazzband/django-axes/blob/fcdeb4ae3f11724b99da54dfa61df90abcf54f7b/axes/admin.py#L63-L66

https://github.com/jazzband/django-axes/blob/fcdeb4ae3f11724b99da54dfa61df90abcf54f7b/axes/admin.py#L98-L101

This may cause miss-understanding of what is being observed by the user if the `username` field is not used in the `__str__` method of that model.

To address this it should be enough to add `username` to the first fieldset.


Discussion:
Thanks for reporting @sevdog ! Would you have the opportunity of making a PR for updating the fieldsets?
@aleksihakli this is an "easy task", I should be able to find a time-slot for this.

Since this is an admin-display issue, do you require any unittests or it could be done event without tests?
The current test suite does not seem to contain too many tests for the admin:

https://github.com/jazzband/django-axes/blob/master/tests/test_admin.py

Adding one field to the fieldsets should be fine as-is; tests would be a nice bonus for the admin views of course, but Django already tests that the stock admin views should work properly.

Resolving patch:
diff --git a/axes/admin.py b/axes/admin.py
--- a/axes/admin.py
+++ b/axes/admin.py
@@ -23,7 +23,7 @@ class AccessAttemptAdmin(admin.ModelAdmin):
     date_hierarchy = "attempt_time"
 
     fieldsets = (
-        (None, {"fields": ("path_info", "failures_since_start")}),
+        (None, {"fields": ("username", "path_info", "failures_since_start")}),
         (_("Form Data"), {"fields": ("get_data", "post_data")}),
         (_("Meta Data"), {"fields": ("user_agent", "ip_address", "http_accept")}),
     )
@@ -61,7 +61,7 @@ class AccessLogAdmin(admin.ModelAdmin):
     date_hierarchy = "attempt_time"
 
     fieldsets = (
-        (None, {"fields": ("path_info",)}),
+        (None, {"fields": ("username", "path_info")}),
         (_("Meta Data"), {"fields": ("user_agent", "ip_address", "http_accept")}),
     )
 
@@ -96,7 +96,7 @@ class AccessFailureLogAdmin(admin.ModelAdmin):
     date_hierarchy = "attempt_time"
 
     fieldsets = (
-        (None, {"fields": ("path_info",)}),
+        (None, {"fields": ("username", "path_info")}),
         (_("Meta Data"), {"fields": ("user_agent", "ip_address", "http_accept")}),
     )
 


Test patch:
Repository: jazzband/django-axes

Issue:
Duplicate names for tests in `AxesCoolOffTestCase`
https://github.com/jazzband/django-axes/blob/b5a3e7ddf55129235477ee9de572544ae2d55a41/tests/test_helpers.py#L926-L940


Discussion:

Resolving patch:
diff --git a/axes/helpers.py b/axes/helpers.py
--- a/axes/helpers.py
+++ b/axes/helpers.py
@@ -37,7 +37,7 @@ def get_cache_timeout() -> Optional[int]:
 
     The cache timeout can be either None if not configured or integer of seconds if configured.
 
-    Notice that the settings.AXES_COOLOFF_TIME can be None, timedelta, integer, callable, or str path,
+    Notice that the settings.AXES_COOLOFF_TIME can be None, timedelta, float, integer, callable, or str path,
     and this function offers a unified _integer or None_ representation of that configuration
     for use with the Django cache backends.
     """
@@ -54,7 +54,7 @@ def get_cool_off() -> Optional[timedelta]:
 
     The return value is either None or timedelta.
 
-    Notice that the settings.AXES_COOLOFF_TIME is either None, timedelta, or integer of hours,
+    Notice that the settings.AXES_COOLOFF_TIME is either None, timedelta, or integer/float of hours,
     and this function offers a unified _timedelta or None_ representation of that configuration
     for use with the Axes internal implementations.
 


Test patch:
diff --git a/tests/test_helpers.py b/tests/test_helpers.py
--- a/tests/test_helpers.py
+++ b/tests/test_helpers.py
@@ -928,15 +928,15 @@ def test_get_cool_off_int(self):
         self.assertEqual(get_cool_off(), timedelta(hours=2))
 
     @override_settings(AXES_COOLOFF_TIME=2.0)
-    def test_get_cool_off_int(self):
+    def test_get_cool_off_float(self):
         self.assertEqual(get_cool_off(), timedelta(minutes=120))
 
     @override_settings(AXES_COOLOFF_TIME=0.25)
-    def test_get_cool_off_int(self):
+    def test_get_cool_off_float_lt_0(self):
         self.assertEqual(get_cool_off(), timedelta(minutes=15))
 
     @override_settings(AXES_COOLOFF_TIME=1.7)
-    def test_get_cool_off_int(self):
+    def test_get_cool_off_float_gt_0(self):
         self.assertEqual(get_cool_off(), timedelta(seconds=6120))
 
     @override_settings(AXES_COOLOFF_TIME=lambda: timedelta(seconds=30))
Repository: jazzband/django-axes

Issue:
FEATURE REQUEST: Logging without sensitive data by default (privacy by design)
Hi @aleksihakli 

we found out that AXES logs IP and username to the configured Django log on a failed attempt. The IP address is critical by definition but the username is very often the email address of the user - so it's even more critical.

I would love to see a solution where we avoid logging any sensitive information - unless you explicitly want this and enable it.

So my suggestion:
* `AXES_VERBOSE` is set to `False` by default
* The `get_client_str` method does not print the username when verbose mode is off but the User ID. This will help you as much as the username to find the specific user but you avoid spilling the data everywhere (like some fancy server or cloud logs)

What do you think? Would you be open for a PR?

Best  
Ronny



Discussion:
Sure thing, like I said in #438 if you have an idea for the improvement we're always open for PRs.

Resolving patch:
diff --git a/axes/conf.py b/axes/conf.py
--- a/axes/conf.py
+++ b/axes/conf.py
@@ -124,7 +124,7 @@
 settings.AXES_SENSITIVE_PARAMETERS = getattr(
     settings,
     "AXES_SENSITIVE_PARAMETERS",
-    [],
+    ["username", "ip_address"],
 )
 
 # set the callable for the readable string that can be used in


Test patch:
diff --git a/tests/test_helpers.py b/tests/test_helpers.py
--- a/tests/test_helpers.py
+++ b/tests/test_helpers.py
@@ -82,6 +82,7 @@ def test_iso8601(self):
                 self.assertEqual(get_cool_off_iso8601(delta), iso_duration)
 
 
+@override_settings(AXES_SENSITIVE_PARAMETERS=[])
 class ClientStringTestCase(AxesTestCase):
     @staticmethod
     def get_expected_client_str(*args, **kwargs):
@@ -1020,6 +1021,7 @@ def setUp(self):
             "other_sensitive_data": "sensitive",
         }
 
+    @override_settings(AXES_SENSITIVE_PARAMETERS=[])
     def test_cleanse_parameters(self):
         cleansed = cleanse_parameters(self.parameters)
         self.assertEqual("test_user", cleansed["username"])
@@ -1041,6 +1043,7 @@ def test_cleanse_parameters_override_both(self):
         self.assertEqual("********************", cleansed["password"])
         self.assertEqual("********************", cleansed["other_sensitive_data"])
 
+    @override_settings(AXES_SENSITIVE_PARAMETERS=[])
     @override_settings(AXES_PASSWORD_FORM_FIELD=None)
     def test_cleanse_parameters_override_empty(self):
         cleansed = cleanse_parameters(self.parameters)
Repository: jazzband/django-axes

Issue:
TransactionManagementError when writing database is not "default"
When starting atomic transactions in `AxesDatabaseHandler`, the database is not specified. This can cause a `TransactionManagementError` if the writing database is not the default one after `select_for_update()` is called.

The solution would be to call `db.router.db_for_write()` to get the database name:

```
with transaction.atomic(using=db.router.db_for_write(AccessAttempt)):
    (
        attempt,
        created,
    ) = AccessAttempt.objects.select_for_update().get_or_create(
...
```


```[tasklist]
### Tasks
```



Discussion:
Good catch @hmarty-ea! Would you happen to have the opportunity for opening a PR for fixing this?

Resolving patch:
diff --git a/axes/handlers/database.py b/axes/handlers/database.py
--- a/axes/handlers/database.py
+++ b/axes/handlers/database.py
@@ -1,8 +1,8 @@
 from logging import getLogger
 from typing import Optional
 
-from django.db import transaction
-from django.db.models import F, Sum, Value, Q
+from django.db import router, transaction
+from django.db.models import F, Q, Sum, Value
 from django.db.models.functions import Concat
 from django.utils import timezone
 
@@ -171,7 +171,7 @@ def user_login_failed(self, sender, credentials: dict, request=None, **kwargs):
                 "AXES: Username is None and username is the only one lockout parameter, new record will NOT be created."
             )
         else:
-            with transaction.atomic():
+            with transaction.atomic(using=router.db_for_write(AccessAttempt)):
                 (
                     attempt,
                     created,
@@ -243,7 +243,7 @@ def user_login_failed(self, sender, credentials: dict, request=None, **kwargs):
 
         # 5. database entry: Log for ever the attempt in the AccessFailureLog
         if settings.AXES_ENABLE_ACCESS_FAILURE_LOG:
-            with transaction.atomic():
+            with transaction.atomic(using=router.db_for_write(AccessFailureLog)):
                 AccessFailureLog.objects.create(
                     username=username,
                     ip_address=request.axes_ip_address,


Test patch:
Repository: wemake-services/wemake-django-template

Issue:
Default site URL announced by docker should not be trusted
Docker on start announces `Starting development server at http://0.0.0.0:8000/`. It is wrong and it is available under  http://127.0.0.1:8000/. This should be reflected somewhere in documentation.


Discussion:
@Hiyorimi why do you think this is wrong? Docker-compose forwards 8000 port and that's it.
[Here](https://github.com/wemake-services/wemake-django-template/blob/master/%7B%7Bcookiecutter.project_name%7D%7D/docker/django/gunicorn.sh#L28) we start an app on `0.0.0.0` host, so it's available on host machine at `0.0.0.0` **and** `127.0.0.1`

Also, @sobolevn how do you think, should hosts `0.0.0.0` or `127.0.0.1` be in `environments/development.py` under `ALLOWED_HOSTS`?
@AlwxSin yes, this is the proposed solution from my side as well. `0.0.0.0` should be allowed.
@AlwxSin Running website in docker is not available  at http://0.0.0.0:8000/ at least on Mac. So it causes confusion.
@Hiyorimi For me running website in docker **is** available at `http://0.0.0.0:8000/` on Mac. Can you provide more info. What your browser shows you when you open page?
I guess that can be resolved with adding '0.0.0.0' to ALLOWED_HOSTS as default parameter to development settings file. 

Can I do it ?
@Hiyorimi please, feel free.

Resolving patch:
diff --git a/{{cookiecutter.project_name}}/server/settings/environments/development.py b/{{cookiecutter.project_name}}/server/settings/environments/development.py
--- a/{{cookiecutter.project_name}}/server/settings/environments/development.py
+++ b/{{cookiecutter.project_name}}/server/settings/environments/development.py
@@ -9,12 +9,19 @@
 import logging
 from typing import List
 
-from server.settings.components.common import INSTALLED_APPS, MIDDLEWARE
+from server.settings.components.common import INSTALLED_APPS, MIDDLEWARE, config
 
 # Setting the development status:
 
 DEBUG = True
 
+ALLOWED_HOSTS = [
+    config('DOMAIN_NAME'),
+    'localhost',
+    '0.0.0.0',
+    '127.0.0.1',
+    '[::1]',
+]
 
 # Static files:
 # https://docs.djangoproject.com/en/1.11/ref/settings/#std:setting-STATICFILES_DIRS


Test patch:
Repository: wemake-services/wemake-django-template

Issue:
Consider adding django-feature-policy
https://pypi.org/project/django-feature-policy/


Discussion:
Related: https://adamj.eu/tech/2019/04/10/how-to-score-a+-for-security-headers-on-your-django-website/

Resolving patch:
diff --git a/{{cookiecutter.project_name}}/server/settings/components/common.py b/{{cookiecutter.project_name}}/server/settings/components/common.py
--- a/{{cookiecutter.project_name}}/server/settings/components/common.py
+++ b/{{cookiecutter.project_name}}/server/settings/components/common.py
@@ -10,7 +10,7 @@
 https://docs.djangoproject.com/en/1.11/ref/settings/
 """
 
-from typing import Tuple
+from typing import Dict, Tuple, Union, List
 
 from server.settings.components import BASE_DIR, config
 
@@ -54,6 +54,7 @@
 
     # Django:
     'django.middleware.security.SecurityMiddleware',
+    'django_feature_policy.FeaturePolicyMiddleware',  # django-feature-policy
     'django.contrib.sessions.middleware.SessionMiddleware',
     'django.middleware.locale.LocaleMiddleware',
     'django.middleware.common.CommonMiddleware',
@@ -178,6 +179,9 @@
 
 X_FRAME_OPTIONS = 'DENY'
 
+# https://github.com/adamchainz/django-feature-policy#setting
+FEATURE_POLICY: Dict[str, Union[str, List[str]]] = {}
+
 
 # Timeouts
 EMAIL_TIMEOUT = 5


Test patch:
Repository: wemake-services/wemake-django-template

Issue:
Enable "Referrer-Policy" header with "no-referrer" value
There's a plugin for that: https://pypi.org/project/django-referrer-policy/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy


Discussion:
This should be added back again when `django-referrer-policy` will work with `django@2.2`
Original issue: https://github.com/ubernostrum/django-referrer-policy/pull/3
Actually this package has a lot of problems inside: 
1. It ships `runtests.py` and `tests/` folder
2. It does not support django1.11 for our old users
3. The last release was 1 year ago
4. The whole package consists of just one file
A fork maybe?
Why do not integrate as own middleware inside project with new style of middleware?
I do not like to have boilerplate in my projects.
It is better to create a new maintainable project for this.

Requirements:
1. It should be tested with latest django releases and LTS ones
2. Python3.5 (6?)+ support
3. Available on PyPI

@DmytroLitvinov it might be a good one-day project if you want to take this!
Ok, closing as unsolved. We are not going to use `django-referrer-policy` because it is unmaintained. 
@sobolevn we could install it via pypi.
It is fork of origin library.
https://pypi.org/project/django-http-referrer-policy/
@DmytroLitvinov PR is welcome!

Resolving patch:
diff --git a/{{cookiecutter.project_name}}/server/settings/components/common.py b/{{cookiecutter.project_name}}/server/settings/components/common.py
--- a/{{cookiecutter.project_name}}/server/settings/components/common.py
+++ b/{{cookiecutter.project_name}}/server/settings/components/common.py
@@ -48,6 +48,9 @@
     'health_check.db',
     'health_check.cache',
     'health_check.storage',
+
+    # Third party apps
+    'django_http_referrer_policy',
 )
 
 MIDDLEWARE: Tuple[str, ...] = (
@@ -67,6 +70,9 @@
 
     # Axes:
     'axes.middleware.AxesMiddleware',
+
+    # Django HTTP Referrer Policy:
+    'django_http_referrer_policy.middleware.ReferrerPolicyMiddleware',
 )
 
 ROOT_URLCONF = 'server.urls'
@@ -184,6 +190,9 @@
 
 X_FRAME_OPTIONS = 'DENY'
 
+# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Syntax
+REFERRER_POLICY = 'no-referrer'
+
 # https://github.com/adamchainz/django-feature-policy#setting
 FEATURE_POLICY: Dict[str, Union[str, List[str]]] = {}  # noqa: TAE002
 


Test patch:
Repository: wemake-services/wemake-django-template

Issue:
Default site URL announced by docker should not be trusted
Docker on start announces `Starting development server at http://0.0.0.0:8000/`. It is wrong and it is available under  http://127.0.0.1:8000/. This should be reflected somewhere in documentation.


Discussion:
@Hiyorimi why do you think this is wrong? Docker-compose forwards 8000 port and that's it.
[Here](https://github.com/wemake-services/wemake-django-template/blob/master/%7B%7Bcookiecutter.project_name%7D%7D/docker/django/gunicorn.sh#L28) we start an app on `0.0.0.0` host, so it's available on host machine at `0.0.0.0` **and** `127.0.0.1`

Also, @sobolevn how do you think, should hosts `0.0.0.0` or `127.0.0.1` be in `environments/development.py` under `ALLOWED_HOSTS`?
@AlwxSin yes, this is the proposed solution from my side as well. `0.0.0.0` should be allowed.
@AlwxSin Running website in docker is not available  at http://0.0.0.0:8000/ at least on Mac. So it causes confusion.
@Hiyorimi For me running website in docker **is** available at `http://0.0.0.0:8000/` on Mac. Can you provide more info. What your browser shows you when you open page?
I guess that can be resolved with adding '0.0.0.0' to ALLOWED_HOSTS as default parameter to development settings file. 

Can I do it ?
@Hiyorimi please, feel free.

Resolving patch:
diff --git a/{{cookiecutter.project_name}}/server/settings/environments/development.py b/{{cookiecutter.project_name}}/server/settings/environments/development.py
--- a/{{cookiecutter.project_name}}/server/settings/environments/development.py
+++ b/{{cookiecutter.project_name}}/server/settings/environments/development.py
@@ -19,6 +19,7 @@
 ALLOWED_HOSTS = [
     config('DOMAIN_NAME'),
     'localhost',
+    '0.0.0.0',  # noqa: S104
     '127.0.0.1',
     '[::1]',
 ]
@@ -79,3 +80,6 @@ def custom_show_toolbar(request):
 NPLUSONE_RAISE = True  # comment out if you want to allow N+1 requests
 NPLUSONE_LOGGER = logging.getLogger('django')
 NPLUSONE_LOG_LEVEL = logging.WARN
+NPLUSONE_WHITELIST = [
+    {'model': 'admin.*'},
+]


Test patch:
Repository: wemake-services/wemake-django-template

Issue:
Default site URL announced by docker should not be trusted
Docker on start announces `Starting development server at http://0.0.0.0:8000/`. It is wrong and it is available under  http://127.0.0.1:8000/. This should be reflected somewhere in documentation.


Discussion:
@Hiyorimi why do you think this is wrong? Docker-compose forwards 8000 port and that's it.
[Here](https://github.com/wemake-services/wemake-django-template/blob/master/%7B%7Bcookiecutter.project_name%7D%7D/docker/django/gunicorn.sh#L28) we start an app on `0.0.0.0` host, so it's available on host machine at `0.0.0.0` **and** `127.0.0.1`

Also, @sobolevn how do you think, should hosts `0.0.0.0` or `127.0.0.1` be in `environments/development.py` under `ALLOWED_HOSTS`?
@AlwxSin yes, this is the proposed solution from my side as well. `0.0.0.0` should be allowed.
@AlwxSin Running website in docker is not available  at http://0.0.0.0:8000/ at least on Mac. So it causes confusion.
@Hiyorimi For me running website in docker **is** available at `http://0.0.0.0:8000/` on Mac. Can you provide more info. What your browser shows you when you open page?
I guess that can be resolved with adding '0.0.0.0' to ALLOWED_HOSTS as default parameter to development settings file. 

Can I do it ?
@Hiyorimi please, feel free.

Resolving patch:
diff --git a/{{cookiecutter.project_name}}/server/apps/main/urls.py b/{{cookiecutter.project_name}}/server/apps/main/urls.py
--- a/{{cookiecutter.project_name}}/server/apps/main/urls.py
+++ b/{{cookiecutter.project_name}}/server/apps/main/urls.py
@@ -3,8 +3,6 @@
 
 from server.apps.main.views import index
 
-# Place your URLs here:
-
 app_name = 'main'
 
 urlpatterns = [
diff --git a/{{cookiecutter.project_name}}/server/apps/main/views.py b/{{cookiecutter.project_name}}/server/apps/main/views.py
--- a/{{cookiecutter.project_name}}/server/apps/main/views.py
+++ b/{{cookiecutter.project_name}}/server/apps/main/views.py
@@ -2,8 +2,6 @@
 from django.http import HttpRequest, HttpResponse
 from django.shortcuts import render
 
-# Create your views here.
-
 
 def index(request: HttpRequest) -> HttpResponse:
     """


Test patch:
Repository: wemake-services/wemake-django-template

Issue:
Support python3.8
Since `python3.9` is released, now it is time to move to `3.8`


Discussion:

Resolving patch:
diff --git a/{{cookiecutter.project_name}}/server/settings/components/common.py b/{{cookiecutter.project_name}}/server/settings/components/common.py
--- a/{{cookiecutter.project_name}}/server/settings/components/common.py
+++ b/{{cookiecutter.project_name}}/server/settings/components/common.py
@@ -191,7 +191,7 @@
 X_FRAME_OPTIONS = 'DENY'
 
 # https://github.com/DmytroLitvinov/django-http-referrer-policy
-# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Syntax
+# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
 REFERRER_POLICY = 'same-origin'
 
 # https://github.com/adamchainz/django-feature-policy#setting
@@ -199,4 +199,6 @@
 
 
 # Timeouts
+# https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-EMAIL_TIMEOUT
+
 EMAIL_TIMEOUT = 5


Test patch:
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -7,7 +7,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        python-version: [3.7]
+        python-version: [3.8]
 
     steps:
     - uses: actions/checkout@v2
Repository: wemake-services/wemake-django-template

Issue:
Add django-stubs-ext project
We need to add it to both:
- https://github.com/wemake-services/wemake-django-template/blob/master/%7B%7Bcookiecutter.project_name%7D%7D/server/wsgi.py
- https://github.com/wemake-services/wemake-django-template/blob/master/%7B%7Bcookiecutter.project_name%7D%7D/manage.py

Link: https://github.com/typeddjango/django-stubs/tree/master/django_stubs_ext

And also fix this file: https://github.com/wemake-services/wemake-django-template/blob/master/%7B%7Bcookiecutter.project_name%7D%7D/server/apps/main/admin.py#L7


Discussion:

Resolving patch:
diff --git a/{{cookiecutter.project_name}}/manage.py b/{{cookiecutter.project_name}}/manage.py
--- a/{{cookiecutter.project_name}}/manage.py
+++ b/{{cookiecutter.project_name}}/manage.py
@@ -3,6 +3,8 @@
 import os
 import sys
 
+import django_stubs_ext
+
 
 def main() -> None:
     """
@@ -28,4 +30,5 @@ def main() -> None:
 
 
 if __name__ == '__main__':
+    django_stubs_ext.monkeypatch()
     main()
diff --git a/{{cookiecutter.project_name}}/server/wsgi.py b/{{cookiecutter.project_name}}/server/wsgi.py
--- a/{{cookiecutter.project_name}}/server/wsgi.py
+++ b/{{cookiecutter.project_name}}/server/wsgi.py
@@ -9,7 +9,9 @@
 
 import os
 
+import django_stubs_ext
 from django.core.wsgi import get_wsgi_application
 
+django_stubs_ext.monkeypatch()
 os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'server.settings')
 application = get_wsgi_application()


Test patch: