Re: [Django] #33534: Formset form with initial values doesnt save

[Django]

#33534: Formset form with initial values doesnt save
-+-
 Reporter:  saschahofmann|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  formset initial  | Triage Stage:
  save   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by saschahofmann):

 I guess that makes sense if an extra_form is invalid/not filled out but if
 I submit a correctly filled out form I would expect it to be saved or not?
 Maybe it'd be nice to be able to configure that behaviour? Right now, I am
 going to overwrite the save_new_objects function and remove the line.

 Replying to [comment:1 Tim Graham]:
 > Formsets can have extra forms that may not be changed. In that case,
 they shouldn't be treated as new data that the user submitted.

-- 
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/071.a9386f5f3ca6453d93a46d5c581c5137%40djangoproject.com.

Re: [Django] #33476: Formatting Code with Black

[Django]

#33476: Formatting Code with Black
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 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 GitHub ):

 In [changeset:"d11944be3466ce8e874474949134811ed6e90e92" d11944be]:
 {{{
 #!CommitTicketReference repository=""
 revision="d11944be3466ce8e874474949134811ed6e90e92"
 Refs #33476 -- Added warning to optimizemigration/squashmigrations
 commands when black cannot be applied.
 }}}

-- 
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/065.9969c20af700d2df1f7f5b7a6349c84c%40djangoproject.com.

Re: [Django] #33508: MariaDB 10.8+ supports ordering on individual columns in the index.

[Django]

#33508: MariaDB 10.8+ supports ordering on individual columns in the index.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Alokik
 Type:   |  Roy
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mariadb  | 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):

 * 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/065.440d37d9814f30d45979ba0b2f899a8c%40djangoproject.com.

Re: [Django] #33536: Running help() against django.db.models.PositiveIntegerField results in error

[Django]

#33536: Running help() against django.db.models.PositiveIntegerField results in
error
-+-
 Reporter:  Brenden Hyde |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 Thanks for the feedback. This is caused by translatable class attributes
 like `description = _("Positive integer")` which access the setting. I
 don't see a feasible solution, but these classes don't have docstrings
 anyway.

-- 
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/067.ceea888e475427e87c70ca3ad12266d0%40djangoproject.com.

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Daniel.

 It wasn't really that 6b6be692fcd102436c7abef1d7b3fa1d37ad4bdf ignored all
 exceptions. Rather it stopped the source exception being masked, with the
 explicit intention that the new chained behaviour would be preferred when
 it was available:

 {{{
 # Ignore clean up errors and raise the original error instead.
 # Python 2 doesn't chain exceptions. Remove this error
 # silencing when dropping Python 2 compatibility.
 }}}

 Given that it's clearly not a regression in
 d170c63351944fd91b2206d10f89e7ff75b53b76 — that was the intended change
 all along.

 You're then asking for a change in behaviour to **remove** information
 from the traceback. Maybe that's OK if there's a good reason, but
 otherwise the presumption would be wontfix.

 I'm not sure about the patch itself: it would be easier to consider in a
 fresh PR, with a regression test.

-- 
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/065.9793b2e73455a0a4ee494d6db7e979d8%40djangoproject.com.

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniel Hahler):

 https://code.djangoproject.com/ticket/16614#comment:31 is about "Refs
 #16614 -- Prevented database errors from being masked by cursor close.".

 The fix there ignored all exceptions
 
(https://github.com/django/django/commit/6b6be692fcd102436c7abef1d7b3fa1d37ad4bdf).
 The fix I've done for the regression is a bit smarter to still raise in
 case of unexpected errors.
 (This could also be removed in case you want a more concise patch, but
 even when it is unlikely that it would swallow something unwanted, I've
 meant to put attention to detail there - just in line with the difference
 that we've previously discussed here)

-- 
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/065.110f13a2335a47b2a40e35cc067ee566%40djangoproject.com.

Re: [Django] #33522: Unexpected behaviour when logging in

[Django]

#33522: Unexpected behaviour when logging in
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  authentication log   | Triage Stage:
  in CSRF token  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michael):

 Sorry yes that would be pointless.

 With the "SameSite: Lax", and some JavaScript to set the X-CSRFToken
 header, and not use GZIP for HTML responses (I think the masked CSRF Token
 is to counter BREACH attacks),  I think it would mitigate CSRF token
 errors, and be just as secure. I understand the Django admin site is not
 keen on JavaScript, so its up to custom code if one prefers that.

-- 
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/068.b99ef58de86bd44ebf478f26fd0ee3aa%40djangoproject.com.

Re: [Django] #33533: Should it be impossible for a session dict to return more than one value for a key?

[Django]

#33533: Should it be impossible for a session dict to return more than one value
for a key?
--+--
 Reporter:  Michael   |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  contrib.sessions  |  Version:  4.0
 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
--+--

Comment (by Michael):

 Replying to [comment:1 Tim Graham]:
 > See TicketClosingReasons/UseSupportChannels for ways to get help if you
 cannot debug the issue yourself. Please only use this ticket tracker for
 reporting confirmed bugs. Thanks!

 I actually opened a stack overflow question about a week ago and got no
 responses, and I think it's due to the fact you can't debug a dictionary
 lookup, it seems like quite an atomic action. I was hestitant on creating
 this issue, but after giving it some thought, I suspected it must be a bug
 not the code, since the code is basically set a key in the session, then
 read the key.

-- 
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/068.ed85d3b12bde4ac4725e681067ed6e84%40djangoproject.com.

[Django] #33536: Running help() against django.db.models.PositiveIntegerField results in error

[Django]

#33536: Running help() against django.db.models.PositiveIntegerField results in
error
-+
   Reporter:  Brenden Hyde   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  4.0
   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  |
-+
 **Issue Description:**

 As a Django user, I would like to read built-in docstrings for Django
 classes without having an existing Django project.

 When creating a new Django project, it can be helpful to read the built-in
 docstrings for each class in a package before beginning. For example, if I
 have never used django.db.models.PositiveIntegerField and want to know
 what the "null" or "blank" kwargs do, I can open a Python or IPython REPL
 and type the following:

 {{{
 from django.db import models
 help(models.PositiveIntegerField)
 }}}

 The above, in theory, should print the help doc for the
 PositiveIntegerField class. However, the current state of things causes a
 traceback instead:

 {{{
 ImproperlyConfigured: Requested setting USE_I18N, but settings are not
 configured. You must either define the environment variable
 DJANGO_SETTINGS_MODULE or call settings.configure() before accessing
 settings.
 }}}

 According to the Django
 [https://docs.djangoproject.com/en/4.0/topics/settings/#envvar-
 DJANGO_SETTINGS_MODULE/ docs], this issue is caused by not telling Django
 where your settings come from. However, if a user is just trying to read
 generic documentation for a given class, I don't think they should have to
 implement a concrete settings file first. Ideally, a user should be able
 to read these docs locally without creating anything at all. I realize
 that online documentation through the Django website is available, but it
 would be nice to be able to read the docstrings in a REPL.


 **Steps to Reproduce**
 1. Create a new virtual environment (I use pipenv, but any should work)
 2. Install django~=4.0.0 and ipython to your virtualenv
 3. open the ipython REPL by running "ipython" from the command line
 4. In the REPL, run the following 2 lines of code:

 {{{
 from django.db import models
 help(models.PositiveIntegerField)
 }}}
 5. The above should result in a traceback ending with this error message:

 {{{
 ImproperlyConfigured: Requested setting USE_I18N, but settings are not
 configured. You must either define the environment variable
 DJANGO_SETTINGS_MODULE or call settings.configure() before accessing
 settings.
 }}}

-- 
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/052.427ac490e032bc461d49861a0d509f65%40djangoproject.com.

Re: [Django] #33535: Add Basic support for DB View

[Django]

#33535: Add Basic support for DB View
-+-
 Reporter:  Vasanth  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  ORM, DB View | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 The [https://groups.google.com/g/django-
 developers/c/asYZNgJH2_4/m/qo4Q6yiGAQAJ django-developers discussion]
 hasn't received much feedback. You'll need to flesh out your proposal and
 get a consensus there before we can accept a ticket.

-- 
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/064.655e51131e2b9ce77895a376d8fcf4a8%40djangoproject.com.

[Django] #33535: Add Basic support for DB View

[Django]

#33535: Add Basic support for DB View
-+-
   Reporter:  Vasanth|  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  ORM, DB View
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Since Django ORM lends itself to easy data manipulation and query
 generation,  we can define Managers similar to DB Views. However, it is
 simpler to offload complicated Queries critical to the app to the DB.

 It allows developers to,

 1. Expose denormalised data via APIs (REST and GraphQL).
 2. Reuse the virtual tables with third-party applications.

 All of Django's officially DBs support DB Views. So basic CR*D support can
 be added for DB Views. In addition, abstract functions can be used for
 modifying data through views which allows to side-step sqlite not
 supporting it.

 Non-goals:
 1. Support for Materialized views

-- 
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/049.10fac48602ac6153726cb2ab0f245334%40djangoproject.com.

Re: [Django] #29208: Mistake in the documentation, request.POST['username'] is not working, but request.POST.get('username') is working!

[Django]

#29208: Mistake in the documentation, request.POST['username'] is not working, 
but
request.POST.get('username') is working!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Documentation |  Version:  4.0
 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 Tim Graham):

 Maybe it's unclear that this code is for example purposes only and isn't
 meant to be copied into your project. This is an example of how to use the
 low-level `login()` function. It's not meant as a robust
 
[https://docs.djangoproject.com/en/stable/topics/auth/default/#django.contrib.auth.views.LoginView
 LoginView].

-- 
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/073.5ea8419d7f8b6d4a0925e055c678f9d9%40djangoproject.com.

Re: [Django] #33534: Formset form with initial values doesnt save

[Django]

#33534: Formset form with initial values doesnt save
-+-
 Reporter:  saschahofmann|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  formset initial  | Triage Stage:
  save   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Formsets can have extra forms that may not be changed. In that case, they
 shouldn't be treated as new data that the user submitted.

-- 
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/071.9b75077d46bfa6ae75c8bbd2359578b6%40djangoproject.com.

[Django] #33534: Formset form with initial values doesnt save

[Django]

#33534: Formset form with initial values doesnt save
-+-
   Reporter: |  Owner:  nobody
  saschahofmann  |
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  4.0
   Severity:  Normal |   Keywords:  formset initial
   Triage Stage: |  save
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Calling `formset.save()` on a formset with an extra_form that only hasn't
 changed any of the initial values doesn't save.

 I believe the cause is in
 [https://github.com/django/django/blob/main/django/forms/models.py#L942].
 `form.has_changed()` checks whether data is different compared to initial
 values. This behaviour is incosistent with `form.save()` e.g. you could
 call something like `formset.extra_forms[0].save()` and this would save
 the form.

 It seems reasonable to me to simple remove that line! Why would a new item
 not be saved on Submit?

 Happy to submit the according 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/056.1f5976f96d5d3a51f10b4f238e9bab8b%40djangoproject.com.

Re: [Django] #29208: Mistake in the documentation, request.POST['username'] is not working, but request.POST.get('username') is working!

[Django]

#29208: Mistake in the documentation, request.POST['username'] is not working, 
but
request.POST.get('username') is working!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Documentation |  Version:  4.0
 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
--+--
Changes (by Mogoh Viol):

 * cc: Mogoh Viol (added)


-- 
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/073.8385cd9fba8cef47e2b902c18bb3bb9b%40djangoproject.com.

Re: [Django] #29208: Mistake in the documentation, request.POST['username'] is not working, but request.POST.get('username') is working!

[Django]

#29208: Mistake in the documentation, request.POST['username'] is not working, 
but
request.POST.get('username') is working!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Documentation |  Version:  4.0
 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
--+--
Changes (by Mogoh Viol):

 * status:  closed => new
 * version:  2.0 => 4.0
 * resolution:  wontfix =>


-- 
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/073.56a2c5d9ce875c7d23f94c3250775e78%40djangoproject.com.

Re: [Django] #29208: Mistake in the documentation, request.POST['username'] is not working, but request.POST.get('username') is working!

[Django]

#29208: Mistake in the documentation, request.POST['username'] is not working, 
but
request.POST.get('username') is working!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Documentation |  Version:  2.0
 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 Mogoh Viol):

 I stumbled into this just this week and I say this is still a problem and
 bad style.

 The reason, why this is a problem, because it depends on the POST request
 the user sends.
 ''Normally'', what the user sends is depending on the form provide by the
 server.
 But it is trivially to craft a POST request that does not contain a
 username or a password or whatever.

 A malicious attacker could just provoke a application crash and an
 internal server error (which happened to me).
 This in itself is of course not a security breach but an attacker should
 never be able to provoke a crash like this.

 In my case this curl commands provoked the crash:


 This one is for obtaining csfr cookies and tokens:

 {{{
 curl -sS --location --cookie-jar cookies.txt
 http://localhost:8080/en/intern/login/ | grep 'csrfmiddlewaretoken'
 }}}

 Here we send the POST request with omiting the password:

 {{{
 curl -X POST --data "csrfmiddlewaretoken=<--TOKEN
 HERE--->=x" --cookie cookies.txt -sS --location --dump-
 header - http://localhost:8080/en/intern/login/ -o /dev/null
 }}}



 And the fix as Marat Mkhitaryan suggestes is as trivial as the attack.
 So please let's change this.

-- 
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/073.f97f0f610f271e5cc2d2d9c5f909b8c6%40djangoproject.com.

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 > The main thing … is not raising errors from cursor.close() in the first
 place … e.g. when it gets used for display in the short test summary etc.

 So the request is suppressing the chained nested exception — you don't
 want the newer Python 3 behaviour in this case — which would be a new
 feature, rather than a fixing a regression from #16614.

 And the reason you want this if because your test runner (presumably
 pytest) formats its output in a given way? (Is that it?)

-- 
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/065.e1408392b3c6fc0427b26d973159b7e9%40djangoproject.com.

Re: [Django] #33328: Use native JS events to trigger 'formset:added'/'formset:removed'

[Django]

#33328: Use native JS events to trigger 'formset:added'/'formset:removed'
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 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 Carlton Gibson):

 * 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/065.3a49cb2d7d03c4c64e92ef353ceec0e7%40djangoproject.com.

Re: [Django] #31202: Bulk update suffers from poor performance with large numbers of models and columns

[Django]

#31202: Bulk update suffers from poor performance with large numbers of models 
and
columns
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   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 jerch):

 Some early tests with COPY FROM indicate, that it even outperforms UPDATE
 FROM VALUES by far (at least 4 times faster). But the code is even more
 degenerated and violates django paradigms in almost every aspect. This is
 probably nothing for django itself, but maybe a third party lib, that
 people can use if they are aware of basic restrictions.

 What I find bothersome with COPY FROM:
 - needs dealing with temporary tables, columns partially bootstrapped from
 target tables
 - might need own cast/escape rules for more complex field types (have not
 yet looked at psycopg3's copy cursor mechanics)
 - might not work for all field types / payloads (this most likely depends
 on alot on the used transport format/delimiters)
 - impact of index on pk field of temp table uncertain (whether index
 creation outweighs the index gain on the final update)

 Yeah well, this needs alot more investigation, before it will be useable
 with a nice interface...

-- 
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/061.2aa3bc4e270edf6418038adfdd02c1d3%40djangoproject.com.

Re: [Django] #33508: MariaDB 10.8+ supports ordering on individual columns in the index.

[Django]

#33508: MariaDB 10.8+ supports ordering on individual columns in the index.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Alokik
 Type:   |  Roy
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mariadb  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alokik Roy):

 * 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/065.4db504e57c12144120f6d202c5d46a22%40djangoproject.com.

Re: [Django] #27844: Add a management command to optimize a migration

[Django]

#27844: Add a management command to optimize a migration
-+-
 Reporter:  Raphael Gaschignard  |Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  dev
 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:"7c318a8bdd66f8c5241864c9970dddb525d0ca4c" 7c318a8b]:
 {{{
 #!CommitTicketReference repository=""
 revision="7c318a8bdd66f8c5241864c9970dddb525d0ca4c"
 Fixed #27844 -- Added optimizemigration management command.
 }}}

-- 
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/062.cb62dcc82c51bb3b698ab622a975fd3b%40djangoproject.com.

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniel Hahler):

 The main thing this is meant to fix is not raising errors from
 `cursor.close()` in the first place.
 The difference between "caused by" and "then triggered also" is only
 relevant for when it should not get swallowed (based on if it is expected
 because there was an error already).

 What you currently get during a test run with a missing migration:
 {{{
 Traceback (most recent call last):
   File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedColumn: column foo.bar does not exist
 LINE 1: ...
  ^


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "…/Vcs/django/django/db/models/sql/compiler.py", line 1361, in
 execute_sql
 cursor.execute(sql, params)
 …
   File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: column foo.bar does not exist
 LINE 1: ...
  ^


 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "…/project/.venv/lib/python3.10/site-
 packages/pytest_django/fixtures.py", line 122, in django_db_setup
 db_cfg = setup_databases(
 …
   File "…/Vcs/django/django/db/models/sql/compiler.py", line 1364, in
 execute_sql
 cursor.close()
 psycopg2.errors.InvalidCursorName: cursor
 "_django_curs_140147764090688_sync_10" does not exist
 }}}

 `psycopg2.errors.InvalidCursorName` is expected to happen here, and
 obfuscates/hides the real error (e.g. when it gets used for display in the
 short test summary etc).

 The (current) patch changes it to:
 {{{
 Traceback (most recent call last):
   File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedColumn: column foo.bar does not exist
 LINE 1: ...
  ^


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "…/project/.venv/lib/python3.10/site-
 packages/pytest_django/fixtures.py", line 122, in django_db_setup
 db_cfg = setup_databases(
 …
   File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: column foo.bar does not exist
 LINE 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/065.61ad0bde2429328a2a3199fc7082d9fa%40djangoproject.com.

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  raydeal
 Type:   |   Status:  closed
  Cleanup/optimization   |
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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"7ba6ebe9149ae38257d70100e8bfbfd0da189862" 7ba6ebe9]:
 {{{
 #!CommitTicketReference repository=""
 revision="7ba6ebe9149ae38257d70100e8bfbfd0da189862"
 Fixed #19580 -- Unified behavior of reverse foreign key and many-to-many
 relations for unsaved instances.
 }}}

-- 
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/066.732ac24886a63bd3fc910cc84ca1a26c%40djangoproject.com.

Re: [Django] #33522: Unexpected behaviour when logging in

[Django]

#33522: Unexpected behaviour when logging in
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  authentication log   | Triage Stage:
  in CSRF token  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 > Thinking about this some more, what if the CSRF middleware got the token
 from the cookie, instead of from the form data? This would solve the CSRF
 errors that pop up every now and then.

 Then it would compare the cookie against the cookie providing no security
 :) It has to compare the cookie (something the attacker cannot control) to
 the POST data (or header as fallback).

-- 
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/068.70277cef85d0b6e7b9b5804efeae2226%40djangoproject.com.

Re: [Django] #33522: Unexpected behaviour when logging in

[Django]

#33522: Unexpected behaviour when logging in
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  authentication log   | Triage Stage:
  in CSRF token  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Others can comment, but this looks like exactly expected behaviour to me.
 I'm not sure we can, or it's worth trying to work around.

 I don't see that we're ever going to be able to update forms rendered
 before a login with a fresh CSRF token. (Some JS maybe, but it's not clear
 that's going to be 100% safe ever.)

 > ... what if the CSRF middleware got the token from the cookie, instead
 of from the form data?

 This would totally defeat the point no? I get you to submit a form from my
 evil site to yours; your browser sends the cookie; the only thing that
 saves you is that I don't know the right token to add to the form data.

-- 
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/068.dbe60dd33cfffcfce7b0931c08cb4b15%40djangoproject.com.

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  raydeal
 Type:   |   Status:  assigned
  Cleanup/optimization   |
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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/066.5a6fa443799def2d983d19a2fe5a6a73%40djangoproject.com.