Re: [Django] #21289: Add login rate limiting to contrib.auth

[Django]

#21289: Add login rate limiting to contrib.auth
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  dev
 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 ivanov17):

 I think this is still relevant, it would be great to have such
 functionality out of the box.

-- 
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/0107018d2476f74f-2b5d03ad-4183-46e0-8b06-ab923c4f659f-00%40eu-central-1.amazonses.com.

Re: [Django] #34819: GenericForeignKey.get_prefetch_queryset()

[Django]

#34819: GenericForeignKey.get_prefetch_queryset()
-+-
 Reporter:  Richard Laager   |Owner:
 |  rajdesai24
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  3.2
  contrib.contenttypes   |
 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
-+-
Changes (by rajdesai24):

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


Comment:

 I agree with what Richard is suggesting, and it works. I will generate a
 PR regarding the solution provided and a valid test case

-- 
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/0107018d23457390-d4f379f8-9912-4f52-b515-2778a15a863a-00%40eu-central-1.amazonses.com.

Re: [Django] #35126: forms.NullBooleanField's validation logic is surprising

[Django]

#35126: forms.NullBooleanField's validation logic is surprising
--+--
 Reporter:  Jeremy Lainé  |Owner:  Gaurav sah
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  5.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 Tim Graham):

 It seems like a useful improvement, if feasible. Jeremy, it would have
 been most helpful if you did some investigation regarding the backwards
 compatibility comment rather than simply describing it as "some obscure
 reason." Using `git blame` leads to
 35a08b8541c856a51b2ab718e0a2fe060debfa2a (#17210). If you're able to
 provide a proof of concept solution, feel free to ping me (@timgraham) on
 a draft GitHub pull request.

-- 
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/0107018d22b11be3-c36c6a9f-448f-4da2-9c7f-d2630b54d40e-00%40eu-central-1.amazonses.com.

Re: [Django] #35129: Support customize ForeignKey DDL when db_constraint=False

[Django]

#35129: Support customize ForeignKey DDL when db_constraint=False
-+-
 Reporter:  elonzh   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Simon Charette):

 I think this will eventually come in a form or the other eventually
 through a `Relation` object
 [http://charettes.name/djangoconus2022/slides.html#39 that can be defined
 at the model level] but in the mean time your best bet is to use (at your
 own risks) the undocumented `django.db.models.ForeignObject` object to
 define such relationships.

 {{{#!python
 class Journal(Model):
 issn = models.CharField(max_length=9, primary_key=True)
 name = models.CharField(max_length=255)

 class Biblio(Model):
 issn = models.CharField(max_length=50, default="", blank=True)
 journal = models.ForeignObject(
 Journal,
 models.DO_NOTHING,
 from_fields=["issn"],
 to_fields=["issn"],
 )
 }}}

 Under the hood `ForeignKey` is `Field` + `ForeignObject` + the equivalent
 of a `ForeignKeyConstraint(ForeignObject)` entry in
 `Model._meta.constraints` so if you care about the ORM + JOIN generation
 part and don't want a database constraint it's likely what you're looking
 for.

-- 
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/0107018d227db47f-ca9f6b6e-dba6-4882-9444-a751d299cbc9-00%40eu-central-1.amazonses.com.

Re: [Django] #35129: Support customize ForeignKey DDL when db_constraint=False

[Django]

#35129: Support customize ForeignKey DDL when db_constraint=False
-+-
 Reporter:  elonzh   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Natalia Bidart):

 Replying to [comment:2 elonzh]:
 > [...] I want is joining tables without db_constraint. Django doesn't
 provide a method to achieve this, so I define a fake ForeignKey as a
 workround.

 Another way of achieving this is by using a slightly more manual approach
 involving subqueries. You could also consider seeking more help or ideas
 in how to resolve this without using a foreign key by posting your
 question n the [https://forum.djangoproject.com/c/users/using-the-orm/17
 Django Forum], or using any of the user support channels from
 [https://docs.djangoproject.com/en/dev/faq/help/#how-do-i-do-x-why-
 doesn-t-y-work-where-can-i-go-to-get-help this link].

-- 
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/0107018d226e773b-18634eda-6ddb-4ceb-b762-6d908b902250-00%40eu-central-1.amazonses.com.

Re: [Django] #35129: Support customize ForeignKey DDL when db_constraint=False

[Django]

#35129: Support customize ForeignKey DDL when db_constraint=False
-+-
 Reporter:  elonzh   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 elonzh):

 Replying to [comment:1 Mariusz Felisiak]:
 > `db_constraint` is only to disable creation of foreign key constraints
 in the tables and to allow for handling legacy database structures (if you
 don't other choice). It has nothing to do with a column data type that
 should always match a data type of the referenced column. Moreover,
 `max_length` is not a proper keyword argument for `ForeignKey` and as such
 is ignored.

 I know those parameters are intentionally ignored, what I want is joining
 tables without db_constraint. Django doesn't provide a method to achieve
 this, so I define a fake ForeignKey as a workround.

 I am curious that since it is allowed to set db_constraint=True for
 handling legacy database structures, why `max_length` should be always
 match a data type of the referenced column.

 This behavior will make unnessary migrations for legacy database
 structures, right?

-- 
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/0107018d2203f3a0-51f64e4f-a573-470a-aeb4-534eb6cf2ef7-00%40eu-central-1.amazonses.com.

Re: [Django] #25493: Model instances created with unittest.mock can raise confusing errors

[Django]

#25493: Model instances created with unittest.mock can raise confusing errors
-+-
 Reporter:  Josh Smeaton |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (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
-+-
Changes (by Marcelo Galigniana):

 * owner:  nobody => Marcelo Galigniana
 * 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/0107018d21eee2b2-cf46e89e-c884-4e2d-a3bf-fec7025f219c-00%40eu-central-1.amazonses.com.

[Django] #35130: Document how to manually close database connections

[Django]

#35130: Document how to manually close database connections
+
   Reporter:  Baptiste Mispelon |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  5.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 |
+
 I was reading about manual database connection management today and came
 upon this section (emphasis mine) [1]:

 > If a connection is created in a long-running process, outside of
 Django’s request-response cycle, the connection will remain open **until
 explicitly closed**, or timeout occurs.

 From what I understand, manually closing open db connections is done by
 calling `django.db.close_old_connections()`, but that function does not
 seem to be documented officially.
 I'm not sure if the function is undocumented by design (it is after all a
 pretty unusual use-case and most users should never have to call it
 themselves), or if that was just an omission.



 [1] https://docs.djangoproject.com/en/dev/ref/databases/#caveats

-- 
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/0107018d21d24965-715cd558-a1e8-4ddb-a834-1b09109aa84a-00%40eu-central-1.amazonses.com.

Re: [Django] #5865: cycle template tag should accept a single argument

[Django]

#5865: cycle template tag should accept a single argument
-+-
 Reporter:  Gary Wilson  |Owner:  Alexander
 |  Lazarević
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  dev
 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
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  1 => 0


Comment:

 There is nothing to review, at least for now.

-- 
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/0107018d219ea93f-e3bbc7af-ee76-43c9-8996-d8438760e22c-00%40eu-central-1.amazonses.com.

Re: [Django] #35129: Support customize ForeignKey DDL when db_constraint=False

[Django]

#35129: Support customize ForeignKey DDL when db_constraint=False
-+-
 Reporter:  elonzh   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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:

 `db_constraint` is only to disable creation of foreign key constraints in
 the tables and to allow for handling legacy database structures (if you
 don't other choice). It has nothing to do with a column data type that
 should always match a data type of the referenced column. Moreover,
 `max_length` is not a proper keyword argument for `ForeignKey` and as such
 is ignored.

-- 
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/0107018d2197a6cd-4baa4779-5e12-4442-9c70-a20998f90253-00%40eu-central-1.amazonses.com.

Re: [Django] #34613: add support for Partitioned cookies

[Django]

#34613: add support for Partitioned cookies
-+-
 Reporter:  Oleg Korsak  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  chips, cookies,  | Triage Stage:  Accepted
  csrf, partitioned  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Terence Honles):

 Replying to [comment:9 Michael Wheeler]:
 > I wonder if it would be possible to follow a similar approach to the one
 that was used to add support for `SameSite`
 
https://github.com/django/django/commit/9a56b4b13ed92d2d5bb00d6bdb905a73bc5f2f0a.
 >
 > Not sure if anyone was already planning on tackling this, but if not I'd
 be curious about taking it on as a first time contributor.

 Thanks for the pointer here. I was actually going to write a WSGI
 middleware, but following what was done for `SameSite` I used the
 following:

 middleware.py:
 {{{
 ...
 from http import cookies

 ...
 cookies.Morsel._flags.add("partitioned")
 cookies.Morsel._reserved.setdefault("partitioned", "Partitioned")

 class CookiePartitioningMiddleware(MiddlewareMixin):
 def process_response(
 self, request: HttpRequest, response: HttpResponseBase
 ) -> HttpResponseBase:
 for name in (
 getattr(settings, f"{prefix}_COOKIE_NAME")
 for prefix in ("CSRF", "SESSION", "LANGUAGE")
 if getattr(settings, f"{prefix}_COOKIE_SECURE")
 ):
 if cookie := response.cookies.get(name):
 cookie["Partitioned"] = True

 return response
 }}}

 and added the middleware to my application.

 Adding and respecing a `${NAME}_COOKIE_PARTITIONED` would make sense for a
 PR, but for our use case we want to partition all cookies. It ''may'' also
 make sense to make sure `${NAME}_COOKIE_SAMESITE` is `'None'` since that
 is [https://developers.google.com/privacy-
 
sandbox/3pcd/chips#:~:text=Note%3A%20Adding%20SameSite%3DNone%20will%20allow%20your%20cookie%20to%20be%20sent%20in%20third%2Dparty%20contexts%20where%20the%20Partitioned%20attribute%20is%20not%20supported%2C%20as%20long%20as%20third%2Dparty%20cookies%20are%20allowed%20in%20browser%20settings.
 recommended for browsers which don't support partitioning via CHIPS]

-- 
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/0107018d21407f07-c870d7d8-d122-4e12-b748-342cb2416b30-00%40eu-central-1.amazonses.com.

Re: [Django] #35125: Parent model fields are ignored when preparing the update_fields

[Django]

#35125: Parent model fields are ignored when preparing the update_fields
-+-
 Reporter:  Gustavo Silva|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  update_or_create | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gustavo Silva):

 Hi Natalia, thank you very much for your reply!

 Replying to [comment:1 Natalia Bidart]:
 > Hello Gustavo! Thanks for your report.
 >
 > If I understand your second part of the report correctly, your issue is
 similar to the one described in this forum post:
 https://forum.djangoproject.com/t/update-or-create-behavior/25944/ (while
 the first post is about a new feature request, I think the underlying
 issue is the same and you may benefit from the posted answers). If yes,
 could you please add your proposal/concern to that topic? Or you could
 also create a new topic to present your idea, since you'll reach a wider
 audience and likely get extra feedback in the forum than here.

 Thank you for pointing me in that direction. I will take a look to that
 post and will try to see if it is the same problem - and being so I can
 propose a fix there, sure.

 Replying to [comment:1 Natalia Bidart]:
 > For the first part of the report, could you please cite the exact part
 of the linked doc that you find confusing?

 I highlighted the bits that was confusing but perhaps they are only
 confusing when considering the release notes and/or the queryset
 reference. So, the model field reference says this about `auto_now`:

 > The field is only automatically updated when calling Model.save(). The
 field isn’t updated when making updates to other fields in other ways such
 as QuerySet.update(), though you can specify a custom value for the field
 in an update like that.

 
https://docs.djangoproject.com/en/4.2/ref/models/fields/#django.db.models.DateField.auto_now

 But the release notes mention this, about the fields that are picked up
 for updates: https://docs.djangoproject.com/en/4.2/releases/4.2/#setting-
 update-fields-in-model-save-may-now-be-required

 The docs for phttps://docs.djangoproject.com/en/5.0/ref/models/querysets
 /#update-or-create/ the `update_or_create` method also mention that after
 4.2 only some fields are selected for update.

 All of this in conjunction, led me to believe auto_now fields do not get
 picked up for updates after 4.2 but maybe it's only my interpretation, I
 don't know.

-- 
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/0107018d212a008a-1a64d7f2-35ac-43e5-a9f2-7f1373b14d7a-00%40eu-central-1.amazonses.com.

[Django] #35129: Support customize ForeignKey DDL when db_constraint=False

[Django]

#35129: Support customize ForeignKey DDL when db_constraint=False
-+-
   Reporter:  elonzh |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  5.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Sometimes we want to join tables without foreignkeys, so we define a
 ForeignKey field with db_constraint=False to achieve this.

 For example:

 {{{
 class Journal(Model):
 issn = models.CharField(max_length=9, primary_key=True)
 name = models.CharField(max_length=255)

 class Biblio(Model):
 # There already exists a field called issn in the Biblio model
 # issn = models.CharField(max_length=50, default="", blank=True)
 journal = models.ForeignKey(
 Journal,
 related_name="+",
 db_column="issn",
 db_constraint=False,
 db_index=False,
 on_delete=models.DO_NOTHING,
 default="",
 blank=True,
 max_length=50,
 )
 }}}

 In this example, we define a journal field from issn field and we want to
 do a fake migration.

 But the migratation will generate DDL like this:


 {{{
 --
 -- Remove field issn from biblio
 --
 ALTER TABLE `userlibrary_biblio` DROP COLUMN `issn`;
 --
 -- Add field issn_record to biblio
 --
 ALTER TABLE `userlibrary_biblio` ADD COLUMN `issn` varchar(9) DEFAULT ''
 NOT NULL;
 ALTER TABLE `userlibrary_biblio` ALTER COLUMN `issn` DROP DEFAULT;
 }}}

 which is kind of awkward because that means Django will force max_length=9
 and this is not we want.

-- 
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/0107018d211d1508-e20f7985-d0e0-45b1-8cc2-d52284ba8305-00%40eu-central-1.amazonses.com.

Re: [Django] #29280: Add a database OPTIONS to specify the transaction mode one SQLite.

[Django]

#29280: Add a database OPTIONS to specify the transaction mode one SQLite.
-+-
 Reporter:  Ove Kåven|Owner:  Anže
 |  Pečar
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, databases| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anže Pečar):

 * owner:  nobody => Anže Pečar
 * 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/0107018d20fa31eb-f160e3d9-2a47-497b-b096-d58594d46494-00%40eu-central-1.amazonses.com.