Re: [Django] #34171: QuerySet.bulk_create() crashes on mixed case columns in unique_fields/update_fields.

[Django]

#34171: QuerySet.bulk_create() crashes on mixed case columns in
unique_fields/update_fields.
-+-
 Reporter:  Joshua Brooks|Owner:  Bhuvnesh
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Bhuvnesh):

 * owner:  nobody => Bhuvnesh
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849e531641-f08aa386-0f5c-4b58-98c6-9c92dd4e4340-00%40eu-central-1.amazonses.com.

Re: [Django] #34171: QuerySet.bulk_create() crashes on mixed case columns in unique_fields/update_fields.

[Django]

#34171: QuerySet.bulk_create() crashes on mixed case columns in
unique_fields/update_fields.
-+-
 Reporter:  Joshua Brooks|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Bhuvnesh):

 I guess no one is working on this one so i'll just open a quick PR.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849e5300db-62f746b5-3d26-46a2-8429-35e1d33d0fe8-00%40eu-central-1.amazonses.com.

Re: [Django] #34174: async process_exception being called as sync from async view/middleware

[Django]

#34174: async process_exception being called as sync from async view/middleware
-+-
 Reporter:  Gabriel Rado |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  middleware async | Triage Stage:  Accepted
  process_exception  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hi Gabriel. OK, seems right, are you happy to suggest a docs adjustment?
 (… but if you could add a test to demonstrate what you're seeing
 explicitly, that would be good too.) Thanks.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849e35c37c-e2d3c23a-2dcc-4e56-80b6-a810ec5e92a3-00%40eu-central-1.amazonses.com.

Re: [Django] #34175: Cannot make whole test set to pass

[Django]

#34175: Cannot make whole test set to pass
---+--
 Reporter:  gzuccarelli|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  4.1
 Severity:  Normal |   Resolution:  invalid
 Keywords:  unittest   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Hi, please don't use Trac as a support channel. Use one of these to debug
 your issue and eventually provide details about why and where Django is at
 fault, thanks.

 Closing per TicketClosingReasons/UseSupportChannels.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849dc247df-23c207e4-c7ec-4cf6-9bce-51204ca1f97b-00%40eu-central-1.amazonses.com.

Re: [Django] #33747: Display exception notes on the technical 500 debug page on Python 3.11+.

[Django]

#33747: Display exception notes on the technical 500 debug page on Python 3.11+.
-+
 Reporter:  Adam Johnson |Owner:  Giebisch
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849db9e814-6b76ef98-353a-4870-9ed8-dd96608c7e32-00%40eu-central-1.amazonses.com.

[Django] #34175: Cannot make whole test set to pass

[Django]

#34175: Cannot make whole test set to pass
-+--
   Reporter:  gzuccarelli|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  4.1
   Severity:  Normal |   Keywords:  unittest
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
 I tried with two ubi8 base images, the python38 one and the python39 one.
 Both with same results:

 git clone --branch stable/4.1.x --depth 1
 https://github.com/django/django.git

 cd ./django
 python -m venv ~/.virtualenvs/djangodev
 source ~/.virtualenvs/djangodev/bin/activate

 python -m pip install -e .
 cd tests
 python -m pip install -r requirements/py3.txt

 ./runtests.py

 FAILED (failures=3, skipped=1187, expected failures=5)

 You can see the errors report here: https://pastebin.com/GmnfHQ7e

 What should I do to make all the tests pass?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849dad001b-dfc4eed7-077c-45b1-a0b2-0d3b5c47a723-00%40eu-central-1.amazonses.com.

Re: [Django] #34172: Documentation of AdminSite.get_urls() encourages security vulnerabilities

[Django]

#34172: Documentation of AdminSite.get_urls() encourages security 
vulnerabilities
+--
 Reporter:  Sylvain Fankhauser  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  contrib.admin   |  Version:  4.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Mariusz Felisiak):

 `get_urls()` docs contains a step by step example with further required
 elements, first an example without `admin_view()`, than comments what is
 missing:

 > ''However, the self.my_view function registered above suffers from two
 problems:''
 > ''- It will not perform any permission checks, so it will be accessible
 to the general public.''

 and a second example with the `admin_view()` wrapper. I wouldn't change
 anything, IMO it's nicely constructed.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849b892bdf-652c3738-2dbc-4334-b91b-d9ef4255aab3-00%40eu-central-1.amazonses.com.

Re: [Django] #34173: SessionMiddleware only returns 400 or 500 error in case of DB issues.

[Django]

#34173: SessionMiddleware only returns 400 or 500 error in case of DB issues.
--+--
 Reporter:  SessionIssue  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.sessions  |  Version:  4.1
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Thanks for this ticket, however it is a support question and Trac is not a
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channel].

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849b7d3bd0-571e2051-a69d-4ab3-beb9-8fd93bf3de1b-00%40eu-central-1.amazonses.com.

Re: [Django] #33747: Display exception notes on the technical 500 debug page on Python 3.11+.

[Django]

#33747: Display exception notes on the technical 500 debug page on Python 3.11+.
-+
 Reporter:  Adam Johnson |Owner:  Giebisch
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Giebisch):

 * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849af85e81-4209547c-c78a-4fd7-b6ac-974bff7f81e7-00%40eu-central-1.amazonses.com.

Re: [Django] #34174: async process_exception being called as sync from async view/middleware

[Django]

#34174: async process_exception being called as sync from async view/middleware
-+-
 Reporter:  Gabriel Rado |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  middleware async | Triage Stage:
  process_exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Gabriel Rado:

Old description:

> following this bold part of the
> docs[https://docs.djangoproject.com/en/4.1/topics/http/middleware
> /#asynchronous-support]:
>

> process_view, process_template_response and process_exception methods, if
> they are provided, **should also be adapted to match the sync/async
> mode**. However, Django will individually adapt them as required if you
> do not, at an additional performance penalty.
>
> I' using this middleware to parse errors from sync and async views:
>

> {{{
> @sync_and_async_middleware
> def custom_error(get_response):
> if asyncio.iscoroutinefunction(get_response):
>
> async def middleware(request):
> response = await get_response(request)
> return response
>
> async def _process_exception(request, exception):
> return my_custom_process_exception(exception)
>
> else:
>
> def middleware(request):
> response = get_response(request)
> return response
>
> def _process_exception(request, exception):
> return my_custom_process_exception(exception)
>
> middleware.process_exception = _process_exception
> return middleware
> }}}
>
> and I'm getting "ValueError: The view my_view.view_func didn't return an
> HttpResponse object. It returned an unawaited coroutine instead. You may
> need to add an 'await' into your view." from
> here[https://github.com/django/django/blob/main/django/core/handlers/base.py#L257]
>
> i thought that with an async middleware + async view, all my hooks
> (process_view, process_template_response and process_exception) should be
> also async, but it appears that is mandatory to use sync
> process_exception with async capable middlewares. if this is intended,
> could the official docs be changed to expose this mandatory behavior?

New description:

 following this bold part from
 [https://docs.djangoproject.com/en/4.1/topics/http/middleware
 /#asynchronous-support]:
 > process_view, process_template_response and process_exception methods,
 if they are provided, **should also be adapted to match the sync/async
 mode**. However, Django will individually adapt them as required if you do
 not, at an additional performance penalty.

 I'm using this middleware to parse errors from sync and async views:


 {{{
 @sync_and_async_middleware
 def custom_error(get_response):
 if asyncio.iscoroutinefunction(get_response):

 async def middleware(request):
 response = await get_response(request)
 return response

 async def _process_exception(request, exception):
 return my_custom_process_exception(exception)

 else:

 def middleware(request):
 response = get_response(request)
 return response

 def _process_exception(request, exception):
 return my_custom_process_exception(exception)

 middleware.process_exception = _process_exception
 return middleware
 }}}

 and I'm getting "ValueError: The view my_view.view_func didn't return an
 HttpResponse object. It returned an unawaited coroutine instead. You may
 need to add an 'await' into your view." from
 [https://github.com/django/django/blob/main/django/core/handlers/base.py#L257]

 i thought that with an async middleware + async view, all my hooks
 (process_view, process_template_response and process_exception) should be
 also async, but it appears that is mandatory to use sync process_exception
 with async capable middlewares. if this is intended, could the official
 docs be changed to expose this mandatory behavior?

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

[Django] #34174: async process_exception being called as sync from async view/middleware

[Django]

#34174: async process_exception being called as sync from async view/middleware
-+-
   Reporter:  Gabriel|  Owner:  nobody
  Rado   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  4.1
  Documentation  |   Keywords:  middleware async
   Severity:  Normal |  process_exception
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 following this bold part of the
 docs[https://docs.djangoproject.com/en/4.1/topics/http/middleware
 /#asynchronous-support]:


 process_view, process_template_response and process_exception methods, if
 they are provided, **should also be adapted to match the sync/async
 mode**. However, Django will individually adapt them as required if you do
 not, at an additional performance penalty.

 I' using this middleware to parse errors from sync and async views:


 {{{
 @sync_and_async_middleware
 def custom_error(get_response):
 if asyncio.iscoroutinefunction(get_response):

 async def middleware(request):
 response = await get_response(request)
 return response

 async def _process_exception(request, exception):
 return my_custom_process_exception(exception)

 else:

 def middleware(request):
 response = get_response(request)
 return response

 def _process_exception(request, exception):
 return my_custom_process_exception(exception)

 middleware.process_exception = _process_exception
 return middleware
 }}}

 and I'm getting "ValueError: The view my_view.view_func didn't return an
 HttpResponse object. It returned an unawaited coroutine instead. You may
 need to add an 'await' into your view." from
 
here[https://github.com/django/django/blob/main/django/core/handlers/base.py#L257]

 i thought that with an async middleware + async view, all my hooks
 (process_view, process_template_response and process_exception) should be
 also async, but it appears that is mandatory to use sync process_exception
 with async capable middlewares. if this is intended, could the official
 docs be changed to expose this mandatory behavior?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a90f7e4-e68d4713-a0b0-4631-8d23-9cb4a19a8fa4-00%40eu-central-1.amazonses.com.

[Django] #34173: SessionMiddleware only returns 400 or 500 error in case of DB issues.

[Django]

#34173: SessionMiddleware only returns 400 or 500 error in case of DB issues.
+
   Reporter:  SessionIssue  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.sessions  |Version:  4.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Hi guys,

 I have the following situation. In one of my applications I'm having an
 issue with returning the right status code.
 For example I had this situation where I wanted to list 1000 results, this
 normally takes a couple of seconds, but during this request, my DB went
 offline or got stuck for some reason. Currently, this resulted in a 500
 status code.
 As I have a custom controller that only retries tasks on specific status
 codes (like 503), I want to return a 503 status code (I also think that
 503 is a more suitable one than 500 in this case), but this resulted in
 returning a 400 status code. The reason for that is the SessionMiddleware
 and particularly this part:

 {{{
 if response.status_code != 500:
 try:
 request.session.save()
 except UpdateError:
 raise SessionInterrupted(
 "The request's session was deleted before the
 "
 "request completed. The user may have logged "
 "out in a concurrent request, for example."
 )
 response.set_cookie(
 settings.SESSION_COOKIE_NAME,
 request.session.session_key, max_age=max_age,
 expires=expires,
 domain=settings.SESSION_COOKIE_DOMAIN,
 path=settings.SESSION_COOKIE_PATH,
 secure=settings.SESSION_COOKIE_SECURE or None,
 httponly=settings.SESSION_COOKIE_HTTPONLY or None,
 samesite=settings.SESSION_COOKIE_SAMESITE,
 )
 }}}
 As my DB is offline, this results in a 400 error, as the session can't be
 saved.
 I rewrote this small piece in a custom middleware that inherits the
 SessionMiddleware, but this is not a futureproof solution:

 {{{
 **if response.status_code not in [500, 503]:**
 try:
 request.session.save()
 except UpdateError:
 raise SessionInterrupted(
 "The request's session was deleted before the
 "
 "request completed. The user may have logged "
 "out in a concurrent request, for example."
 )
 response.set_cookie(
 settings.SESSION_COOKIE_NAME,
 request.session.session_key, max_age=max_age,
 expires=expires,
 domain=settings.SESSION_COOKIE_DOMAIN,
 path=settings.SESSION_COOKIE_PATH,
 secure=settings.SESSION_COOKIE_SECURE or None,
 httponly=settings.SESSION_COOKIE_HTTPONLY or None,
 samesite=settings.SESSION_COOKIE_SAMESITE,
 )
 }}}

 It's a small change, but it will make it hard for us to keep track of all
 the Django updates.

 Do you have a generic solution for this issue?

 Thanks in advance.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a7c64b1-c4086b99-1047-415a-9367-b65b237a6a72-00%40eu-central-1.amazonses.com.

Re: [Django] #34172: Documentation of AdminSite.get_urls() encourages security vulnerabilities

[Django]

#34172: Documentation of AdminSite.get_urls() encourages security 
vulnerabilities
+--
 Reporter:  Sylvain Fankhauser  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  contrib.admin   |  Version:  4.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by David Sanders):

 I think you have a valid point 

 Interested in submitting a documentation PR?

 Just FYI small documentation fixes don't require a ticket, I think this
 could fall under that category of not needing one 

 For reference the documentation follows the Diátaxis framework:
 https://diataxis.fr/

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a798f35-e50b2c65-b905-48cb-99b8-b13df2f017c9-00%40eu-central-1.amazonses.com.

Re: [Django] #34152: Add the ability to store logs in a table

[Django]

#34152: Add the ability to store logs in a table
-+-
 Reporter:  Alireza Safari   |Owner:  Alireza
 |  Safari
 Type:  New feature  |   Status:  closed
Component:  Utilities|  Version:  4.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  serilog, database-   | Triage Stage:
  logging, log   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mohamed El-Kalioby):

 You can use django-model-trackwr which allows you to know how and when a
 change happened. Also, it allows you to revert to a previous version of
 the object.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a6afc2b-f1be1519-dfb3-450d-8a16-f46b667ac46d-00%40eu-central-1.amazonses.com.

[Django] #34172: Documentation of AdminSite.get_urls() encourages security vulnerabilities

[Django]

#34172: Documentation of AdminSite.get_urls() encourages security 
vulnerabilities
--+
   Reporter:  Sylvain Fankhauser  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  contrib.admin   |Version:  4.1
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 The documentation for AdminSite.get_urls()
 
(https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_urls)
 starts with an example that doesn’t use `self.admin_site.admin_view` and
 only mentions later that this code doesn’t actually have any permission
 check applied.

 I think showing vulnerable code is a bad idea, as some people might stop
 reading there and end up with admin views publicly reachable. Also the
 docs themselves say below the example "this is usually not what you want".

 My proposal would be to change the default example and show the code with
 `admin_site.admin_view` first, with an explanation below of what it does
 (without any code that would make the view publicly reachable).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a66d365-404b0a43-b122-4580-90bd-246a561e2405-00%40eu-central-1.amazonses.com.

Re: [Django] #34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields.

[Django]

#34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields.
-+-
 Reporter:  Martin Lehoux|Owner:  Martin
 |  Lehoux
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Martin Lehoux):

 Alright thank you for you explanation, I'd be happy to have a look. I will
 get back to you if I find something interesting

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a541cf2-a179f396-c3f5-407d-8140-1942561d5d08-00%40eu-central-1.amazonses.com.

Re: [Django] #34167: Set a reasonable default for EMAIL_TIMEOUT

[Django]

#34167: Set a reasonable default for EMAIL_TIMEOUT
-+-
 Reporter:  Federico Capoano |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  4.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Federico Capoano:

Old description:

> For the record, I started a discussion here: https://groups.google.com/g
> /django-developers/c/XZbKeM8fVxU/m/jp0h8U4tBgAJ

New description:

 Why there's no default for EMAIL_TIMEOUT?

 Applications built in Django can potentially stall indefinitely if email
 sending starts to hang (eg: if the SMTP server is overloaded), when this
 happens, since there's no timeout, there's also no error being logged, so
 it's very hard and time consuming to debug.

 Wouldn't it be better to set a timeout? Some high value like 2 minutes
 which wouldn't really make sense to wait any longer, so at least if and
 when this happens, developers will find error traces in the logs and
 quickly understand where the problem is coming from, instead of spending
 hours to debug it like I did in the past week.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a53343a-31e6fc0b-7826-4db0-ad5f-49dd25344db3-00%40eu-central-1.amazonses.com.

Re: [Django] #34167: Set a reasonable default for EMAIL_TIMEOUT

[Django]

#34167: Set a reasonable default for EMAIL_TIMEOUT
-+-
 Reporter:  Federico Capoano |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  4.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Why there's no default for EMAIL_TIMEOUT?
>
> Applications built in Django can potentially stall indefinitely if email
> sending starts to hang (eg: if the SMTP server is overloaded), when this
> happens, since there's no timeout, there's also no error being logged, so
> it's very hard and time consuming to debug.
>
> Wouldn't it be better to set a timeout? Some high value like 2 minutes
> which wouldn't really make sense to wait any longer, so at least if and
> when this happens, developers will find error traces in the logs and
> quickly understand where the problem is coming from, instead of spending
> hours to debug it like I did in the past week.

New description:

 For the record, I started a discussion here: https://groups.google.com/g
 /django-developers/c/XZbKeM8fVxU/m/jp0h8U4tBgAJ

--

Comment (by Federico Capoano):

 For the record, I started a discussion in the Django Developers Mailing
 List: https://groups.google.com/g/django-
 developers/c/XZbKeM8fVxU/m/jp0h8U4tBgAJ .

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a47aad0-e62c5329-7e70-439a-af2a-c4b24ae8c840-00%40eu-central-1.amazonses.com.

Re: [Django] #32935: Test suite fails with sqlite 3.36 and spatialite 5.

[Django]

#32935: Test suite fails with sqlite 3.36 and spatialite 5.
-+--
 Reporter:  David Smith  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by S. Andrew Sheppard):

 Yes, InitSpatialMetaDataFull would remain as the preferred option.  The
 fallback would be only for systems like Ubuntu 22.04 where using
 InitSpatialMetaDataFull per the docs is not an option, because the
 implementation in spatialite 5.0.1 (the latest released version) is
 incompatible with sqlite 3.36 (and newer versions).  In spite of the stern
 warning on the PROJ.6 page, other parts of the documentation explain that
 InitSpatialMetaDataFull and InitSpatialMetaData are highly compatible:

 https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Upgrading+existing
 +DB-files+to+5.0.0

 Basically, it seems that the 5.0 schema created by InitSpatialMetaDataFull
 is the same as the 4.0 schema created by InitSpatialMetaData, but with
 additional tables needed to support librasterlite2.  Many GeoDjango users
 will probably be fine without raster support, so falling back to
 InitSpatialMetaData seems like it should be reasonable for most cases.

 That said, it is fair to argue that initializing a database with Django
 and spatialite 5.0 should result in a full 5.0-compatible schema.
 Fortunately, it appears that the CreateMissingSystemTables method also
 described in that documentation does not break, so it could be used as
 part of the fallback.  Perhaps something like this would be appropriate:

 {{{
 cursor.execute("PRAGMA table_info(geometry_columns);")
 if cursor.fetchall() == []:
 if self.ops.spatial_version < (5,):
 cursor.execute("SELECT InitSpatialMetaData(1)")
 else:
 try:
 cursor.execute("SELECT
 InitSpatialMetaDataFull(1)")
 except OperationalError as e:
 if "ISO_metadata_reference_row_id_value_insert" in
 e.args[0]:
# Workaround for sqlite 3.36 and spatialite
 5.0.1
cursor.execute("SELECT InitSpatialMetaData(1)")
cursor.execute("SELECT
 CreateMissingSystemTables(1)")
 else:
 raise
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a42e763-a0622498-c097-48e8-952b-f49279052c79-00%40eu-central-1.amazonses.com.

Re: [Django] #29062: "database table locked errors" when using sqlite in-memory database with LiveServerTestCase

[Django]

#29062: "database table locked errors" when using sqlite in-memory database with
LiveServerTestCase
-+-
 Reporter:  Juozas Masiulis  |Owner:
 |  Christophe Baldy
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, testing, | Triage Stage:  Accepted
  databases  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849a10c0d3-9d3e6ffe-276b-4d79-8ae2-d08b2b42cb86-00%40eu-central-1.amazonses.com.

Re: [Django] #34168: Add support for list of parameters to the QuerySet.raw().

[Django]

#34168: Add support for list of parameters to the QuerySet.raw().
-+-
 Reporter:  Marek Rouchal|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Marek Rouchal):

 The specific problem I am facing is that I need to access an existing
 database whose schema I cannot alter; I used the Django tool to extract
 the tables to create models.py, which worked great, and I already hacked
 the model definitions, e.g. to replace a simple IntegerField with a
 ForeignKey. But there are specific tables, where there is an IntegerField
 which may contain a ForeignKey from more than one table (think of a group
 and a user table; whether it is a user or a group, is defined by another
 column):

 class Permission(models.Model):
 ...
 user_or_group_id = models.IntegerField(db_column='user_or_group_id',
 blank=True, null=True)
 is_group = models.IntegerField(db_column='is_group', blank=True,
 null=True)


 So what I would need here is something like a union on ForeignKey (coming
 from either a User or a Group table).
 So I used raw SQL for the required joins; I have not been able to
 formulate a Django queryset to join on a field which is not modeled with
 ForeignKey.
 That is why I was asking for some better support of raw SQL...

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070184999cf1ce-572080fe-65b5-4f02-849a-0176c2aa636d-00%40eu-central-1.amazonses.com.

Re: [Django] #31090: Log when DB transactions are commited and rollbacked.

[Django]

#31090: Log when DB transactions are commited and rollbacked.
-+-
 Reporter:  Petter Strandmark|Owner:  Ilya Bass
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"798e38c2b9c46ab72e2ee8c33dc822f01b194b1e" 798e38c2]:
 {{{
 #!CommitTicketReference repository=""
 revision="798e38c2b9c46ab72e2ee8c33dc822f01b194b1e"
 Fixed #31090 -- Logged transaction management queries.

 Thanks to Petter Strandmark for the original idea and Mariusz Felisiak
 for advice during the DjangoConUS 2022 Sprint!
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070184999641f2-dbcfec16-5e67-4b4e-b4f1-f87edaddad42-00%40eu-central-1.amazonses.com.

Re: [Django] #32935: Test suite fails with sqlite 3.36 and spatialite 5.

[Django]

#32935: Test suite fails with sqlite 3.36 and spatialite 5.
-+--
 Reporter:  David Smith  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Mariusz Felisiak):

 > Can this ticket be reopened?

 As far as I'm aware, changing to the `InitSpatialMetaData()` in Django is
 not an option. According to the `SpatiaLite`'s docs:

 > ''"InitSpatialMetaData is still maintained so to not break historical
 compatibility, but **should no longer be used**."''

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018499936494-da7ff58d-d8df-421c-b921-db80f2b3952b-00%40eu-central-1.amazonses.com.

Re: [Django] #32935: Test suite fails with sqlite 3.36 and spatialite 5.

[Django]

#32935: Test suite fails with sqlite 3.36 and spatialite 5.
-+--
 Reporter:  David Smith  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by sheppard):

 I can confirm this is broken on Ubuntu 22.04 with the default apt library
 versions.   Here's another comment from spatialite-users that explains
 what is going on:

 https://groups.google.com/g/spatialite-users/c/5rKuVlIzwZY/m/ydEa4ir_AAAJ

 I think this means that InitSpatialMetaDataFull(1) basically will not work
 on Ubuntu 22.04 until the next version of libsqlite3-mod-spatialite is
 released and packaged.  While this isn't strictly a bug in Django, I think
 it would be appropriate and helpful to fall back to InitSpatialMetaData(1)
 if the "ISO_metadata_reference_row_id_value_insert" error is detected.
 Can this ticket be reopened?

 In the meantime, here's a one-liner that can be executed before running
 ./manage.py migrate on Ubuntu 22.04.

 {{{
 ./manage.py shell -c "import
 django;django.db.connection.cursor().execute('SELECT
 InitSpatialMetaData(1);')";
 ./manage.py migrate
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849941dbbc-f4ffbf86-62e2-472d-a4c0-71e7fe06a5ba-00%40eu-central-1.amazonses.com.

Re: [Django] #31090: Log when DB transactions are commited and rollbacked.

[Django]

#31090: Log when DB transactions are commited and rollbacked.
-+-
 Reporter:  Petter Strandmark|Owner:  Ilya Bass
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701849935a213-a526cb35-a1a7-4ad6-849e-04981ee0becc-00%40eu-central-1.amazonses.com.