date:20220602

Re: [Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
-+-
 Reporter:  Mariusz Felisiak |Owner:  Ciaran
 Type:   |  McCormick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  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:  1|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/01070181280d4ff2-12da0345-efa0-49a0-9e23-a6f8b20840af-00%40eu-central-1.amazonses.com.

Re: [Django] #27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes

2022-06-02 Thread Django

#27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes
-+-
 Reporter:  Akshesh Doshi|Owner:  David
 Type:   |  Wobrock
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  index_together   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"a3a1290d47326c3f87824b3cf7ca969cb0d364aa" a3a1290d]:
 {{{
 #!CommitTicketReference repository=""
 revision="a3a1290d47326c3f87824b3cf7ca969cb0d364aa"
 Refs #27236 -- Moved models with Meta.index_together inside of test
 methods.
 }}}

-- 
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/01070181280b222b-c7de930e-7f00-4cec-b3a6-6bbc6c78073c-00%40eu-central-1.amazonses.com.

Re: [Django] #33589: Incomplete string escaping in formats for calendar.

2022-06-02 Thread Django

#33589: Incomplete string escaping in formats for calendar.
--+
 Reporter:  Shrikant Dhayje   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:  bug,regex,Inaccurate  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * owner:  Shrikant Dhayje => (none)
 * status:  assigned => new


-- 
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/0107018127baae91-397e8de7-bd15-41a6-af34-9ceb9142b346-00%40eu-central-1.amazonses.com.

Re: [Django] #33589: Incomplete string escaping in formats for calendar.

2022-06-02 Thread Django

#33589: Incomplete string escaping in formats for calendar.
-+-
 Reporter:  Shrikant Dhayje  |Owner:  Shrikant
 |  Dhayje
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  bug,regex,Inaccurate   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by fabtjar):

 Replying to [comment:1 Shrikant Dhayje]:
 > "Has patch" https://github.com/django/django/pull/15460
 Hey, are you still working on this ticket? The PR was closed in April due
 to inactivity. Maybe someone else can take 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/0107018126af046a-41e2c42b-b54b-431f-9df0-b795d43a96a0-00%40eu-central-1.amazonses.com.

Re: [Django] #33755: Move ASGI body-file cleanup into ASGIRequest

2022-06-02 Thread Django

#33755: Move ASGI body-file cleanup into ASGIRequest
-+-
 Reporter:  Carlton Gibson   |Owner:  Jonas
 Type:   |  Lundberg
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  ASGI | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jonas Lundberg):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/15756

-- 
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/01070181267ea552-da0771f2-55d3-4e56-990b-3b9f890b275a-00%40eu-central-1.amazonses.com.

Re: [Django] #27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes

2022-06-02 Thread Django

#27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes
-+-
 Reporter:  Akshesh Doshi|Owner:  David
 Type:   |  Wobrock
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  index_together   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


Comment:

 Here we go again! With 3 PRs:
 [https://github.com/django/django/pull/15703 The main PR]
 [https://github.com/django/django/pull/15754 Inlining test classes]
 [https://github.com/django/django/pull/15755 Splitting index/unique
 together autodetector tests]

-- 
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/01070181265902ce-5ba44ffa-a782-4de5-9d79-f85de80bb556-00%40eu-central-1.amazonses.com.

Re: [Django] #33755: Move ASGI body-file cleanup into ASGIRequest

2022-06-02 Thread Django

#33755: Move ASGI body-file cleanup into ASGIRequest
-+-
 Reporter:  Carlton Gibson   |Owner:  Jonas
 Type:   |  Lundberg
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  ASGI | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jonas Lundberg):

 This in body, since read can be used passing a chunk size ...

 Carlton, this is exactly my findings and thoughts as well :-D ... though
 I'm leaning towards adding a noop {{{LimitedStream.close()}}} instead of
 the {{{try...except}}} block.

 Then, adding a simple close() to ASGIRequest...

 Agree, this is probably enough instead of {{{__del__}}}, i.e. untouched
 {{{request.body}}} will be closed and cleaned up by the response resource
 closers.

 I will open a PR shortly.

-- 
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/0107018126314201-a8de3e78-efc1-438b-93fb-52c92a9e342b-00%40eu-central-1.amazonses.com.

Re: [Django] #33757: Clarify django.test.Client.post() file upload example

2022-06-02 Thread Django

#33757: Clarify django.test.Client.post() file upload example
-+-
 Reporter:  bastian-wattro   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"566437adc9dd15dc18388bc256835a9448de0f6e" 566437ad]:
 {{{
 #!CommitTicketReference repository=""
 revision="566437adc9dd15dc18388bc256835a9448de0f6e"
 [4.1.x] Fixed #33757 -- Clarified Client.post() file upload example.

 Backport of 61badf1d58e79b84874afa6a1e00b79f20e786d1 from main
 }}}

-- 
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/010701812560768f-d4fe895b-6f05-4766-9efa-50a126985b1f-00%40eu-central-1.amazonses.com.

Re: [Django] #33757: Clarify django.test.Client.post() file upload example

2022-06-02 Thread Django

#33757: Clarify django.test.Client.post() file upload example
-+-
 Reporter:  bastian-wattro   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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 GitHub ):

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


Comment:

 In [changeset:"61badf1d58e79b84874afa6a1e00b79f20e786d1" 61badf1]:
 {{{
 #!CommitTicketReference repository=""
 revision="61badf1d58e79b84874afa6a1e00b79f20e786d1"
 Fixed #33757 -- Clarified Client.post() file upload example.
 }}}

-- 
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/01070181255fc0ca-e0daf3cf-95c6-48a4-9724-82890b168bc3-00%40eu-central-1.amazonses.com.

Re: [Django] #33757: Clarify django.test.Client.post() file upload example

2022-06-02 Thread Django

#33757: Clarify django.test.Client.post() file upload example
-+-
 Reporter:  bastian-wattro   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Mariusz Felisiak):

 * owner:  nobody => Tim Graham
 * status:  new => assigned
 * stage:  Unreviewed => 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/0107018124fb0ec1-2fdc04d9-7ced-4c4c-9eea-5eb072aa95c9-00%40eu-central-1.amazonses.com.

Re: [Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
-+-
 Reporter:  Mariusz Felisiak |Owner:  Ciaran
 Type:   |  McCormick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * version:  4.0 => dev


-- 
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/0107018124fa3c2e-37ab42d8-827b-4dbf-b510-7ff73afbc73a-00%40eu-central-1.amazonses.com.

Re: [Django] #33714: Better admin support for ArrayFields where the base_field has choices

2022-06-02 Thread Django

Comment (by Mariusz Felisiak):

Replying to [comment:3 Jaap Roes]:
> I don't agree that this is a duplicate. This is about a much narrower
case where an ArrayField is used to wrap another field with choices.
Basically using the ArrayField as a M2M where the "other" side is a fixed
set of options, instead of a database table. The most similar ticket I
can find is #24858, which has been resolved but for a much more esoteric
case (imho) where the ArrayField itself has choices.

My understanding is that we could have a better widget. I don't think it's
worth improving only this rather niche 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/0107018124f2b825-5a5ad226-74ee-4931-a069-0f533a35787c-00%40eu-central-1.amazonses.com.

Re: [Django] #10244: FileFields can't be set to NULL in the db

2022-06-02 Thread Django

#10244: FileFields can't be set to NULL in the db
-+-
 Reporter:  oyvind   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  filefield NULL   | Triage Stage:  Accepted
  empty  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by dvg):

 From ten years ago:

 > ... only for people who set null=True on a FileField. The docs
 discourage that heavily ...

 As far as I can see, there is no mention of `null`, at all, in the
 *current* documentation for
 [https://docs.djangoproject.com/en/4.0/ref/models/fields/#filefield
 FileField].

 Yet Django's `FileField` behavior is still plainly inconsistent, compared
 to other fields, when it comes to `null=True`.

 A short summary:

 We can specify `null=True`, and we can assign `None` to the field, but
 this is stored as a `FieldFile` with `name=None` on the python side, and
 it is stored as an empty string `''` in the database.

 Some resulting inconveniences:

 - `MyModel.objects.create(my_filefield=None).my_filefield is not None`
 - `my_model_instance.my_filefield` is always "truthy", so we need to check
 e.g. `my_filefield.name` ([https://stackoverflow.com/q/8850415 example])
 - we cannot use the `__isnull` field lookup, but have to check for
 equality with the empty string `''` ([https://stackoverflow.com/q/4771464
 example])
 - `FileField(null=True, unique=True)` is broken, because the database
 entry is `''` instead of `null`, so we get a unique-constraint violation
 if we try to create another instance with `None`

 The latter is basically what is described in the
 
[https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.Field.null
 model field reference] (my emphasis):

 > ... One exception is when a `CharField` has both `unique=True` and
 `blank=True` set. In this situation, `null=True` is *required to avoid
 unique constraint violations when saving multiple objects with blank
 values*.

 So, currently, we cannot make a `FileField` unique and optional at the
 same time.

 Why not just bite the bullet and make a backward incompatible change, for
 the sake of consistency?


 [1]:
 
https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.FileField.storage
 [2]: https://docs.djangoproject.com/en/4.0/ref/models/fields/#filefield
 [3]: https://stackoverflow.com/q/8850415
 [4]:
 
https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.Field.null
 [5]: https://stackoverflow.com/q/4771464
 [7]:
 
https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.fields.files.FieldFile

-- 
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/0107018124e515ab-17f7291a-7abb-4798-923d-fe37b46e2ddc-00%40eu-central-1.amazonses.com.

Re: [Django] #33757: Clarify django.test.Client.post() file upload example (was: django.test.Client.post documentation is confusing)

2022-06-02 Thread Django

#33757: Clarify django.test.Client.post() file upload example
-+-
 Reporter:  bastian-wattro   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  closed => new
 * resolution:  invalid =>
 * version:  4.0 => dev
 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization


Comment:

 I offer a [https://github.com/django/django/pull/15753 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/0107018124d81595-41f05274-1352-4cf8-a723-1a796718717f-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

2022-06-02 Thread Django

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  CommonMiddleware | 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 ):

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


Comment:

 In [changeset:"fbac2a4dd846b52c4f379eacb5bab654fe9540cc" fbac2a4d]:
 {{{
 #!CommitTicketReference repository=""
 revision="fbac2a4dd846b52c4f379eacb5bab654fe9540cc"
 Fixed #33700 -- Skipped extra resolution for successful requests not
 ending with /.

 By moving a should_redirect_with_slash call out of an if block, commit
 9390da7fb6e251eaa9a785692f987296cb14523f negated the performance fix
 of commit 434d309ef6dbecbfd2b322d3a1da78aa5cb05fa8 (#24720).
 Meanwhile, the logging issue #26293 that it targeted was subsequently
 fixed more fully by commit 40b69607c751c4afa453edfd41d2ed155e58187e
 (#26504), so it is no longer needed.  This effectively reverts it.

 This speeds up successful requests not ending with / when APPEND_SLASH
 is enabled (the default, and still useful in projects with a mix of
 URLs with and without trailing /).  The amount of speedup varies from
 about 5% in a typical project to nearly 50% on a benchmark with many
 routes.

 Signed-off-by: Anders Kaseorg 
 }}}

-- 
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/01070181248e59a7-7a9de199-ac28-4a77-90fd-afc0179a5b6d-00%40eu-central-1.amazonses.com.

Re: [Django] #33714: Better admin support for ArrayFields where the base_field has choices

2022-06-02 Thread Django

#33714: Better admin support for ArrayFields where the base_field has choices
---+--
 Reporter:  Jaap Roes  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:  duplicate
 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 Jaap Roes):

 I don't agree that this is a duplicate. This is about a much narrower case
 where an ArrayField is used to wrap another field with choices. Basically
 using the ArrayField as a M2M where the "other" side is a fixed set of
 options, instead of a database table.  The most similar ticket I can find
 is #24858, which has been resolved but for a much more esoteric case
 (imho) where the ArrayField itself has choices.

-- 
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/01070181247bcd6b-bfe59507-f45b-472f-9d6d-29fccf18a387-00%40eu-central-1.amazonses.com.

Re: [Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
-+-
 Reporter:  Mariusz Felisiak |Owner:  Ciaran
 Type:   |  McCormick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ciaran McCormick):

 * 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/01070181245562a8-f47482ef-e081-4786-be20-ebf8c98571ff-00%40eu-central-1.amazonses.com.

Re: [Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
-+-
 Reporter:  Mariusz Felisiak |Owner:  Ciaran
 Type:   |  McCormick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ciaran McCormick):

 Hello all, I've opened a PR for this
 https://github.com/django/django/pull/15751, this is my first contribution
 so go easy on me :). Appreciate any feedback on the code change and also
 on whether I've followed correct procedure. 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/0107018124530da8-a8c90da7-f998-4fe3-8d3c-f314b33bf076-00%40eu-central-1.amazonses.com.

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

2022-06-02 Thread Django

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  qs-rf| Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by dvg):

 The "... spirit of not needlessly offering multiple ways to do the same
 thing ..." makes a lot of sense to me.

 However, there's this question on StackOverflow:

 [https://stackoverflow.com/questions/687295 How do I do a not equal in
 Django queryset filtering?]

 Current stats:

 - **555246 views**
 - 859 upvotes
 - bookmarked 179 times

 Just to be clear, this is a **really** high view count: top 0.02% (top
 5500 out of 23 million questions, according to
 https://data.stackexchange.com/stackoverflow)

 Apparently, the alternatives to an `__ne` lookup are not that obvious to
 many people.

 Perhaps it's worth re-opening this issue and, for example, implementing
 the `ne` from the [https://docs.djangoproject.com/en/4.0/howto/custom-
 lookups/#a-lookup-example custom lookup example]?

-- 
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/010701812409c941-7eb9f88b-8c09-4082-89b6-c5a0b18568c0-00%40eu-central-1.amazonses.com.

Re: [Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
-+-
 Reporter:  Mariusz Felisiak |Owner:  Ciaran
 Type:   |  McCormick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ciaran McCormick):

 * owner:  nobody => Ciaran McCormick
 * 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/0107018123f8a2b8-999dd476-d533-4976-8674-b9b7f3f93d8e-00%40eu-central-1.amazonses.com.

Re: [Django] #27325: Offer a solution for static file serving suitable for production use

2022-06-02 Thread Django

#27325: Offer a solution for static file serving suitable for production use
--+
 Reporter:  Tim Graham|Owner:  (none)
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  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 Carlton Gibson):

 * owner:  Aleksej Manaev => (none)
 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * status:  assigned => new


-- 
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/0107018123f1be43-02c95f1f-3985-4308-a8ee-65a70eac1c6a-00%40eu-central-1.amazonses.com.

Re: [Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
--+
 Reporter:  Mariusz Felisiak  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Old description:

> It's unused since fcd837cd0f9b2c706bc49af509628778d442bb3f, see also
> [https://code.djangoproject.com/ticket/33758?replyto=2#comment:2
> Carlton's comment].

New description:

 It's unused since fcd837cd0f9b2c706bc49af509628778d442bb3f, see also
 [https://code.djangoproject.com/ticket/33758?#comment:7 Carlton's
 comment].

--

-- 
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/0107018123e6ead1-2311fa60-e68c-40c6-befe-a30714876f3f-00%40eu-central-1.amazonses.com.

Re: [Django] #31788: Models migration with change field foreign to many and deleting unique together.

2022-06-02 Thread Django

#31788: Models migration with change field foreign to many and deleting unique
together.
+-
 Reporter:  budzichd|Owner:  David Wobrock
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  3.0
 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
+-

Comment (by Mariusz Felisiak ):

 In [changeset:"9fce76a237ddf19e167dcba53815cbfee586b928" 9fce76a2]:
 {{{
 #!CommitTicketReference repository=""
 revision="9fce76a237ddf19e167dcba53815cbfee586b928"
 [4.1.x] Fixed #31788 -- Fixed migration optimization after altering field
 to ManyToManyField.

 This makes AddField() used for altering to ManyToManyField, dependent
 on the prior RemoveField.
 Backport of 798b6c23ee52c675dd0f0e233c50cddd7ff15657 from main
 }}}

-- 
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/0107018123e645f4-7640c051-24e5-4d39-a55a-5b1a5f83eaff-00%40eu-central-1.amazonses.com.

Re: [Django] #31788: Models migration with change field foreign to many and deleting unique together.

2022-06-02 Thread Django

#31788: Models migration with change field foreign to many and deleting unique
together.
+-
 Reporter:  budzichd|Owner:  David Wobrock
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  3.0
 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 GitHub ):

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


Comment:

 In [changeset:"798b6c23ee52c675dd0f0e233c50cddd7ff15657" 798b6c2]:
 {{{
 #!CommitTicketReference repository=""
 revision="798b6c23ee52c675dd0f0e233c50cddd7ff15657"
 Fixed #31788 -- Fixed migration optimization after altering field to
 ManyToManyField.

 This makes AddField() used for altering to ManyToManyField, dependent
 on the prior RemoveField.
 }}}

-- 
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/0107018123e557b6-c94ee91f-468d-4615-919f-5b54e59fa606-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS

2022-06-02 Thread Django

#33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS
-+-
 Reporter:  Javier Torres|Owner:  Sosshi
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  4.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 Carlton Gibson):

 Ah, thanks Mariusz.

-- 
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/0107018123e48102-b01eeede-170e-42a2-95f6-88de7933a5d7-00%40eu-central-1.amazonses.com.

Re: [Django] #33757: django.test.Client.post documentation is confusing

2022-06-02 Thread Django

#33757: django.test.Client.post documentation is confusing
+--
 Reporter:  bastian-wattro  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  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 bastian-wattro):

 > Docs explicitly states that the name attachment here is not relevant.

 See that is what confuses me. `attachment` is very relevant, as it is the
 keyword in the FILES dict.
 This is implicitly stated ("use whatever name your file-processing code
 expects") but not clear if you jump in the docs without context
 information.

-- 
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/0107018123e47328-d84bc441-ff22-43f1-8498-eded7b297fde-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS (was: Deprecate make_random_password() method.)

2022-06-02 Thread Django

#33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS
-+-
 Reporter:  Javier Torres|Owner:  Sosshi
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  4.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
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => wontfix
 * stage:  Accepted => Unreviewed


Comment:

 Carlton, I added a separate ticket for deprecation, see #33764.

-- 
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/0107018123e26c95-3cbbe5c7-d9ab-46c1-a087-e08de3a02e18-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: Deprecate make_random_password() method.

2022-06-02 Thread Django

#33758: Deprecate make_random_password() method.
--+
 Reporter:  Javier Torres |Owner:  Sosshi
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  4.0
 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 Carlton Gibson):

 Release notes could point to
 [https://docs.python.org/3.10/library/secrets.html#recipes-and-best-
 practices the recipe in the Python stdlib `secrets` module docs] — which
 would be the recommended way to do something in this space if you did have
 a use-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/0107018123e0cf3c-b7b0d73e-beda-4c0f-a7ef-9f8176bf4ca4-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: Deprecate make_random_password() method. (was: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS)

2022-06-02 Thread Django

#33758: Deprecate make_random_password() method.
--+
 Reporter:  Javier Torres |Owner:  Sosshi
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  4.0
 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 Carlton Gibson):

 * status:  closed => new
 * resolution:  wontfix =>
 * stage:  Unreviewed => Accepted


Comment:

 OK — let's retitle and accept to deprecate then.

 @Javier, would you fancy taking that on? (See
 [https://docs.djangoproject.com/en/4.0/internals/contributing/writing-code
 /submitting-patches/#deprecating-a-feature Deprecating a feature] for
 guidance but happy to advise too.)

 Thanks all!

-- 
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/0107018123df6b8b-04697178-fd04-494b-bfce-ad84490e05e6-00%40eu-central-1.amazonses.com.

Re: [Django] #33755: Move ASGI body-file cleanup into ASGIRequest

2022-06-02 Thread Django

#33755: Move ASGI body-file cleanup into ASGIRequest
-+-
 Reporter:  Carlton Gibson   |Owner:  Jonas
 Type:   |  Lundberg
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  ASGI | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Jonas.

 I was digging a bit more here:

 > ...unfortunately the HttpRequest.body property drops the reference to
 the body_file by overwriting it with a BytesIO.

 Not closing `self._stream` looks like we should be able to fix in general
 (i.e. it's not ASGI-specific 樂)

 This passes:

 {{{
 diff --git a/django/http/request.py b/django/http/request.py
 index 4b160bc5f4..8354dfe57b 100644
 --- a/django/http/request.py
 +++ b/django/http/request.py
 @@ -340,6 +340,11 @@ class HttpRequest:
  self._body = self.read()
  except OSError as e:
  raise UnreadablePostError(*e.args) from e
 +finally:
 +try:
 +self._stream.close()
 +except:
 +pass
  self._stream = BytesIO(self._body)
  return self._body
 }}}

 This in `body`, since `read` can be used passing a chunk size, and in the
 `try...except` because WSGIHandler uses a `LimitedStream` wrapper that
 doesn't (currently) have a  `close`.

 Then, adding a simple `close()` to `ASGIRequest`...

 {{{
def close(self):
 super().close()
 self._stream.close()
 }}}

 ... and blocking out the `body_file.close()` in `handle()` clears up all
 the ResourceWarnings except two:

 * `test_static_file_response` — This because the `ASGIStaticFilesHandler`
 wraps `ASGIHandler` so (likely) isn't calling `response.close` correctly.
 (See also #33048, #27325)
 * `test_non_unicode_query_string` — We're not then handling the `close()`
 when there's a Unicode error in `create_request()`.

 Both of those should be addressable though.

 What do you think?

 Do you fancy continuing on this?

 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/0107018123db3924-446e17f7-96fc-4db9-a3d5-8f3b8b27f9be-00%40eu-central-1.amazonses.com.

Re: [Django] #33757: django.test.Client.post documentation is confusing

2022-06-02 Thread Django

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

Comment:

I don't see anything confusing in this docs.

> This made me assume that the file given via the file pointer will be
accessible via the keyword `fred`.

Docs explicitly states that the name `attachment` here is not relevant.
`fred` is not a keyword but a value for the `name` and it's used that way
in other examples.

> What I don't understand is why the keyword 'name' is there, and why
doesn't it simply say something like:

IMO it's valuable to show that other fields are handled properly and you
don't need to send files separately.

--
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/0107018123cc243e-5bdfaa63-adbf-4175-808b-97b443b93c0d-00%40eu-central-1.amazonses.com.

Re: [Django] #33757: django.test.Client.post documentation is confusing (was: django.test.Client.post documentation is wrong)

2022-06-02 Thread Django

#33757: django.test.Client.post documentation is confusing
+--
 Reporter:  bastian-wattro  |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 bastian-wattro):

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


Old description:

> Following
> [https://docs.djangoproject.com/en/4.0/topics/testing/tools/#django.test.Client.post]
> with Django version 4.0.4 to write my first unit tests, I failed to
> upload a file.
>
> As described there, I tried
> {{{#!python
> with open('mal.csv', 'rb') as fp:
>   self.client.post('/post/endpoint/', {'name': 'fred', 'attachment': fp})
> }}}
> And assumed that (as described there)
> > The name attachment here is not relevant; use whatever name your file-
> processing code expects.
>
> This made the test fail. Printing request.FILES returned:
> ` (text/csv)>]}>`
>
> What worked was the (way more intuitive)
> {{{#!python
> with open('mal.csv', 'rb') as fp:
>   self.client.post('/post/entpoint/', {'name': 'fred', 'attachment': fp})
> #  (text/csv)>]}>
> }}}
>
> I did not check:
> *  since when the documentation is obsolete
> * if this is intended behavior

New description:

 Following
 
[https://docs.djangoproject.com/en/4.0/topics/testing/tools/#django.test.Client.post]
 with Django version 4.0.4 to write my first unit tests, I failed to upload
 a file under a given keyword *with the *name* / *attachment* pattern*

 As described there, I tried to set *name* and *file pointer* like this:
 > Submitting files is a special case. To POST a file, you need only
 provide the file field name as a key, and a file handle to the file you
 wish to upload as a value. For example:
 > {{{#!python
 with open('mal.csv', 'rb') as fp:
   self.client.post('/post/endpoint/', {'name': 'fred', 'attachment': fp})
 }}}
 > The name *attachment* here is not relevant; use whatever name your file-
 processing code expects.

 This made me assume that the file given via the filepointer will be
 accessible via the keyword `fred`.

 This
 
[test](https://github.com/django/django/blob/d5bc36203057627f6f7d0c6dc97b31adde6f4313/tests/file_uploads/tests.py#L86-L93)
 works because the [endpoint being
 
called](https://github.com/django/django/blob/d5bc36203057627f6f7d0c6dc97b31adde6f4313/tests/file_uploads/views.py#L18)
 (contrary to what I would expect) checks the keyword of the file pointer
 (`fiel_field` in this case) and the `name` separately.

 What I wanted was
 {{{#!python
 with open('mal.csv', 'rb') as fp:
   self.client.post('/post/endpoint/', {'fred': fp})
 }}}
 as (contraty to what is written in the docs) **name** is not required


 Sorry for the confusion and thanks for the quick responses.

--

Comment:

 Sorry for the confusion and thanks for the quick responses. I'll try to
 clarify:

 Following
 
[https://docs.djangoproject.com/en/4.0/topics/testing/tools/#django.test.Client.post
 the docs]
 with Django version 4.0.4 to write my first unit tests, I failed to upload
 a file under a given keyword ''with the ''name'' / ''attachment''
 pattern''

 The docs state:
 {{{#!python
 >>> c = Client()
 >>> with open('wishlist.doc', 'rb') as fp:
 ... c.post('/customers/wishes/', {'name': 'fred', 'attachment': fp})


 }}}
 > The name *attachment* here is not relevant; use whatever name your file-
 processing code expects.

 This made me assume that the file given via the file pointer will be
 accessible via the keyword `fred`.

 This
 
[https://github.com/django/django/blob/d5bc36203057627f6f7d0c6dc97b31adde6f4313/tests/file_uploads/tests.py#L86-L93
 test] works because the
 
[https://github.com/django/django/blob/d5bc36203057627f6f7d0c6dc97b31adde6f4313/tests/file_uploads/views.py#L18
 endpoint being called] (contrary to what I would expect) checks the
 keyword of the file pointer (`fiel_field` in this case) and the `name`
 separately.

 Reading the docs for a third time now I get the meaning.

 What I don't understand is why the keyword 'name' is there, and why
 doesn't it simply say something like:
 
 To submit a file, provide a file handle to the file you wish to upload as
 a value. For example:
 {{{#!python
 >>> c = Client()
 >>> with open('wishlist.doc', 'rb') as fp:
 ... c.post('/customers/wishes/', {'wishes_file': fp})
 }}}
 will be accessible via `request.FILES['wishes_file']`

 
 Again thanks for your time. I get now that this is something that probably
 only confuses new comers like my self.

--

Re: [Django] #31788: Models migration with change field foreign to many and deleting unique together.

2022-06-02 Thread Django

#31788: Models migration with change field foreign to many and deleting unique
together.
+-
 Reporter:  budzichd|Owner:  David Wobrock
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  3.0
 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):

 * 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/0107018123c0737c-e1454ad3-9650-4e89-a08d-9c8f8f0dd97c-00%40eu-central-1.amazonses.com.

Re: [Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  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:  1|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (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/0107018123ace865-51a58e4e-c3d1-4726-8f59-f55f6d7afcd8-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS

2022-06-02 Thread Django

#33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS
-+-
 Reporter:  Javier Torres|Owner:  Sosshi
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  4.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
-+-
Changes (by David Wobrock):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => contrib.auth


Comment:

 Oopsie

-- 
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/0107018123ac4829-ade42547-e787-464e-9497-06e5c288e455-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS

2022-06-02 Thread Django

#33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS
---+--
 Reporter:  Javier Torres  |Owner:  Sosshi
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  4.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
---+--
Changes (by David Wobrock):

 * type:  Cleanup/optimization => Uncategorized
 * component:  contrib.auth => Uncategorized


Comment:

 One could imagine use cases for this function. For example a website that
 automatically creates accounts and sends out the plain passwords (through
 email, or something more secure) for a first log in - but then forces
 password change on first use.

 But I agree with Carlton (and Russell) that Django shouldn't "encourage"
 this, since the implementation then requires some special attention.
 +1 for deprecating this function

-- 
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/0107018123abaa94-d597ce1c-aa4a-4dc0-b72f-efd46ef4febc-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS

2022-06-02 Thread Django

#33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS
-+-
 Reporter:  Javier Torres|Owner:  Sosshi
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  4.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
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => wontfix
 * component:  Uncategorized => contrib.auth
 * type:  Uncategorized => Cleanup/optimization


Comment:

 > I think we should probably deprecate and remove this method, rather than
 try and make it more complex 樂

 Totally agreed, it's unused since
 fcd837cd0f9b2c706bc49af509628778d442bb3f. See #33764.

-- 
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/0107018123aa0a91-4348e3e8-6461-4e0c-88f9-5b423a90c14f-00%40eu-central-1.amazonses.com.

[Django] #33764: Deprecate make_random_password().

2022-06-02 Thread Django

#33764: Deprecate make_random_password().
+
   Reporter:  Mariusz Felisiak  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.auth  |Version:  4.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 It's unused since fcd837cd0f9b2c706bc49af509628778d442bb3f, see also
 [https://code.djangoproject.com/ticket/33758?replyto=2#comment:2 Carlton's
 comment].

-- 
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/0107018123a8c557-598039c7-4e68-455d-9627-c6503c816827-00%40eu-central-1.amazonses.com.

Re: [Django] #33763: Django admin TabularInline in a Multiple databases context

2022-06-02 Thread Django

#33763: Django admin TabularInline in a Multiple databases context
-+-
 Reporter:  moccand  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  admin.TabularInline  | Triage Stage:
  admin multiple database|  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 the report, however manipulating a primary key dynamically is
 complicated. You should set it in advance it you want to display it in a
 creation form.

 Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels] if you're having further question or trouble
 understanding how Django works.

-- 
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/010701812397ae79-96f4edae-9ab0-49d0-817d-dfdfdd32923b-00%40eu-central-1.amazonses.com.

Re: [Django] #27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes

2022-06-02 Thread Django

#27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes
-+-
 Reporter:  Akshesh Doshi|Owner:  David
 Type:   |  Wobrock
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  index_together   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_docs:  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/010701812391ffc8-849b8917-abf4-47d2-8100-30986368210a-00%40eu-central-1.amazonses.com.

[Django] #33763: Django admin TabularInline in a Multiple databases context

2022-06-02 Thread Django

#33763: Django admin TabularInline in a Multiple databases context
-+-
   Reporter:  moccand|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  3.2
  contrib.admin  |   Keywords:  admin.TabularInline
   Severity:  Normal |  admin multiple database
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 All my models are stored in a dedicated database. Django admin is used as
 "backoffice".

 The id fields are set in all my models, and Class meta define for each
 model the targeted table.


 {{{
 class MyModel(models.Model):
 id = models.IntegerField(primary_key=True)
 ...
 class Meta:
 managed = False
 db_table = '__mymodel_table'
 app_label = 'catalog'

 }}}


 So for my models i override the save methode in order to use the sequences
 and autoincrement already in the external database :


 {{{
 def save(self, *args, **kwargs):
 if not self.id :
 self.id = getNextId("__mymodel_id_seq")
 super(MyModel, self).save(*args, **kwargs)
 }}}


 the getNetId function is :


 {{{
 def getNextId(sequence):
 cursor = connections['catalogu'].cursor()
 try :
 with cursor as cursor:
 cursor.execute("select
 nextval('{}'::regclass)".format(sequence))
 result = cursor.fetchall()
 return result[0][0]
 except :
 return None
 }}}



 In addition all my modelAdmin (except the TabularInline) inherite from :


 {{{
 class MultiDBModelAdmin(admin.ModelAdmin):
 # A handy constant for the name of the alternate database.
 using = 'catalog'
 }}}



 My TabularInLine :


 {{{
 class MyModelAdminInline(admin.TabularInline):
 model = MyModel
 fields = ['id', 'titre_classe', 'valeur_texte', 'valeur_min',
 'valeur_max', 'id_style', 'ordre', 'rayon', 'style_css',]
 }}}


 and it is used in an other Admin :


 {{{
 MySecondModelAdmin.inlines = [MyModelAdminInline,]
 }}}


 With the TabularInline models it seems i must set the id fields manually.

 If let it blank : i get a validation error and the field id is shown in
 red
 If set it readonly : i get the same error
 If not shown in the inline : error too ...
 But setting manualy a good value for the id it works fine.

 I think all those 4 cases should work the same : the model save() method
 should 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/01070181238a8017-412d4529-8b44-4c84-8b18-1a73693da657-00%40eu-central-1.amazonses.com.

Re: [Django] #33760: Allow setting session cookie name dynamically

2022-06-02 Thread Django

#33760: Allow setting session cookie name dynamically
--+--
 Reporter:  Dan Strokirk  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sessions  |  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
--+--

Comment (by Dan Strokirk):

 Absolutely, 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/0107018123667221-1a295192-050d-4330-97aa-42003741d3b2-00%40eu-central-1.amazonses.com.

Re: [Django] #33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS

2022-06-02 Thread Django

#33758: make_random_password does not comply with AUTH_PASSWORD_VALIDATORS
---+--
 Reporter:  Javier Torres  |Owner:  Sosshi
 Type:  Uncategorized  |   Status:  assigned
Component:  Uncategorized  |  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 Carlton Gibson):

 Hi. Erm... I'm not sure what to say here.

 > The usage of ... is limited ...

 Yes, it is. `make_random_password()` is essentially not used as tall in
 the Django codebase.

 An 11 year old comment from Russell says why:

 > The only reason I can think of to generate a random password would be to
 send it in cleartext. To which, the answer is a definitive No. Not ever.

 https://code.djangoproject.com/ticket/15639#comment:2

 I think we should probably deprecate and remove this method, rather than
 try and make it more complex 樂

-- 
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/01070181233456fc-fd79c9bc-29c3-4a44-a44f-15bfa1adb885-00%40eu-central-1.amazonses.com.

Re: [Django] #33322: Saving parent object after setting on child leads to unexpected data loss in bulk_update().

2022-06-02 Thread Django

#33322: Saving parent object after setting on child leads to unexpected data 
loss
in bulk_update().
-+-
 Reporter:  GwynBleidD   |Owner:  Hannes
 |  Ljungberg
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:7 Manuel Baclet]:
 > The PR was merged 6 months ago but it has not landed in any release. Can
 someone add this to the current bugfix branch, please?

 This will be released in Django 4.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/01070181232b9b4f-61d38291-c590-4b31-80c6-7a5ab79ee34b-00%40eu-central-1.amazonses.com.

Re: [Django] #33728: Tab order should match visual order for admin model forms’ submit buttons

2022-06-02 Thread Django

#33728: Tab order should match visual order for admin model forms’ submit 
buttons
-+-
 Reporter:  Thibaud Colas|Owner:  Alexander
 Type:   |  Freyr Lúðvíksson
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  keyboard, ux   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
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/010701812329c612-239dc036-a742-4ab4-93bf-0c6d92366ef3-00%40eu-central-1.amazonses.com.

Re: [Django] #33322: Saving parent object after setting on child leads to unexpected data loss in bulk_update().

2022-06-02 Thread Django

#33322: Saving parent object after setting on child leads to unexpected data 
loss
in bulk_update().
-+-
 Reporter:  GwynBleidD   |Owner:  Hannes
 |  Ljungberg
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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
-+-

Comment (by Manuel Baclet):

 The PR was merged 6 months ago but it has not landed in any release. Can
 someone add this to the current bugfix branch, please?

-- 
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/0107018123238807-adb78cd7-4179-4f6a-901b-65c4dfd67afe-00%40eu-central-1.amazonses.com.

Re: [Django] #33760: Allow setting session cookie name dynamically

2022-06-02 Thread Django

#33760: Allow setting session cookie name dynamically
--+--
 Reporter:  Dan Strokirk  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sessions  |  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
--+--
Changes (by Carlton Gibson):

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


Comment:

 Hi.

 I'd likely think this too niche to justify the additional hooks.

 Can I ask you to post to the DevelopersMailingList, which is a better
 venue for these kind of feature requests than the ticket tracker here,
 which gets far fewer eyes? If there's a general approval then we can
 reopen. 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/010701812313ec36-f7c146ab-8aac-4b41-85c3-79879f1684ee-00%40eu-central-1.amazonses.com.

47 matches

Mail list logo