date:20211104

Re: [Django] #33235: Remove "for = ..." from MultiWidget's .

2021-11-04 Thread Django

#33235: Remove "for = ..." from MultiWidget's .
-+-
 Reporter:  Maxim Danilov|Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  forms, wcag|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15061 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/067.82b01aed65d7eed6f4a19dc7fd1d0320%40djangoproject.com.

Re: [Django] #33237: ManifestStaticFilesStorage doesn't update JavaScript source map references in multiline files

2021-11-04 Thread Django

#33237: ManifestStaticFilesStorage doesn't update JavaScript source map 
references
in multiline files
-+-
 Reporter:  Joseph Abrahams  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  4.0
 Severity:  Release blocker  |   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:"499384b6d1a0082d538470d57ade37591e9251d6" 499384b]:
 {{{
 #!CommitTicketReference repository=""
 revision="499384b6d1a0082d538470d57ade37591e9251d6"
 [4.0.x] Fixed #33237 -- Fixed detecting source maps in
 ManifestStaticFilesStorage for multiline files.

 Switched regex to multiline mode in order to match per-line, rather
 than against the whole file.

 Thanks to Joseph Abrahams for the report.

 Regression in 781b44240a06f0c868254f40f36ce46c927f56d1.

 Backport of 4816dc942860caf076c7c85ea9dbfa8bfab212ff 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/072.bbb4f2a212e190aa3a06aeef5b6d459c%40djangoproject.com.

Re: [Django] #33237: ManifestStaticFilesStorage doesn't update JavaScript source map references in multiline files

2021-11-04 Thread Django

#33237: ManifestStaticFilesStorage doesn't update JavaScript source map 
references
in multiline files
-+-
 Reporter:  Joseph Abrahams  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"4816dc942860caf076c7c85ea9dbfa8bfab212ff" 4816dc9]:
 {{{
 #!CommitTicketReference repository=""
 revision="4816dc942860caf076c7c85ea9dbfa8bfab212ff"
 Fixed #33237 -- Fixed detecting source maps in ManifestStaticFilesStorage
 for multiline files.

 Switched regex to multiline mode in order to match per-line, rather
 than against the whole file.

 Thanks to Joseph Abrahams for the report.

 Regression in 781b44240a06f0c868254f40f36ce46c927f56d1.
 }}}

-- 
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/072.f5c0b3ae447cd1aefdfcbfb5104377d0%40djangoproject.com.

Re: [Django] #29738: Django can't serialize DateTimeTZRange(lower=None, upper=None, bounds='[)')

2021-11-04 Thread Django

#29738: Django can't serialize DateTimeTZRange(lower=None, upper=None, 
bounds='[)')
-+-
 Reporter:  Graham Mayer |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  rangefield   | Triage Stage:  Accepted
  postgresql psycopg2 migrations |
  removed|
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:"52f6927d7fb7a4dca40afce0391d018b4c34dd6d" 52f6927]:
 {{{
 #!CommitTicketReference repository=""
 revision="52f6927d7fb7a4dca40afce0391d018b4c34dd6d"
 Refs #29738 -- Added test for serializing psycopg2's NumericRange with
 DecimalRangeField in migrations.
 }}}

-- 
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/069.acda0a807ac58e170339df8e4373bb27%40djangoproject.com.

Re: [Django] #27147: Add support for defining bounds in postgres range fields

2021-11-04 Thread Django

#27147: Add support for defining bounds in postgres range fields
-+-
 Reporter:  Kirill Stepanov  |Owner:  Guilherme
 |  Martins Crocetti
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgres range   | Triage Stage:  Ready for
  bounds |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"fc565cb539e4c1e5fba70d9ebb19bac0ca251d37" fc565cb]:
 {{{
 #!CommitTicketReference repository=""
 revision="fc565cb539e4c1e5fba70d9ebb19bac0ca251d37"
 Fixed #27147 -- Allowed specifying bounds of tuple inputs for non-discrete
 range fields.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.381f8ee90e5116d2e8729ec2186fd92c%40djangoproject.com.

Re: [Django] #33257: Case() and ExpressionWrapper() doesn't work with DecimalField on SQLite.

2021-11-04 Thread Django

Comment (by Matthijs Kooijman):

> I agree with you analysis: When, WindowFrame, and OrderBy don't need
it.

Ok, I left those out.

> I'm not sure about Subquery, you can try to break it, but as far as I'm
aware it returns a single column/expression so casting to a numeric value
should be already handled there.

I tried, and could indeed not break Subquery.

Pullrequest is here: https://github.com/django/django/pull/15062

Regarding Case and ExpressionWrapper, I noticed a small difference between
them: ExpressionWrapper with output_field=DecimalField fails to convert a
non-decimal value to decimal (but works if the value is already a Decimal
literal or DecimalField), while Case actually breaks when applied to
existing decimal values (I suspect that sqlite does some type conversion
when executing the query). I now put both fixes in the same commit, if you
prefer separate commits, let me 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/074.7936f715681bcaf7fbfa7a92c515b136%40djangoproject.com.

Re: [Django] #33265: Form.get_context() backward-incompatibility

2021-11-04 Thread Django

#33265: Form.get_context() backward-incompatibility
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  dev
 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 Collin Anderson):

 Right, yeah, maybe there's not too much Django can do about it, but maybe
 it could also get a quick mention under "Backwards incompatible changes in
 4.0" or something.

-- 
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/072.5310bea567cdefd951595929ad3a79c1%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 Fetching from the database is a bit of a side-effect I’d argue. 😃

 But **also** as proposed the default implementation would raise a warning,
 so I’d have to override `form_valid` to silence that, only to delete that
 at the end of the deprecation period.

 We can back and forth all day, let’s see what others say.

 In any case, thanks for the report!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ba28797cd89bab72bdda280cf809f27f%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Eugene Prikazchikov):

 Yes, I see that `get_object()` and `get_success_url()` get called twice.
 Not ideal, yet that should be harmless - "get_" methods usually do not
 have side effects,

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ab9ea62fad5c771f95a1739d71f14f60%40djangoproject.com.

Re: [Django] #33264: DiscoverRunner doesn't counts unexpectedSuccess as an error

2021-11-04 Thread Django

#33264: DiscoverRunner doesn't counts unexpectedSuccess as an error
-+-
 Reporter:  Baptiste Mispelon|Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I'll accept this change as correct, but I'll also mention that I've used
 `expectedFailure` to prevent tests that sometimes fail (e.g.
 https://github.com/cockroachdb/django-
 cockroachdb/commit/97aaf0bd3abff19b1405215d377b5c91e00cfc84) from causing
 a test suite to fail. I guess I'll have to instead skip these 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/067.11adbac5fe9b82de6e7c0764d02eaffa%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 Let's see what others say.

 I think calling `delete()` isn't error free, since it re-calls the view-
 dispatch methods, `get_object()` and `get_success_url()`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ae32d4470fab2c4991194e7223406e7f%40djangoproject.com.

Re: [Django] #33265: Form.get_context() backward-incompatibility

2021-11-04 Thread Django

#33265: Form.get_context() backward-incompatibility
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Mariusz Felisiak):

 New features introduce new methods, some of then may collide with existing
 3rd-party packages. `Form.get_context()` is
 [https://docs.djangoproject.com/en/4.0/ref/forms/api/#get-context
 documented] and mentioned in release notes. I'm not sure what else we
 could do 🤔 Do you have any suggestion?

-- 
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/072.242914b56865b2b0553b51086b78bdc9%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Eugene Prikazchikov):

 OK, that sounds good.

 As for:

 > a deprecation here stops us adopting the new behaviour.

 It is not quite true. In the patch that I linked in the ticket new
 behavior is preserved - DeleteView still inherits from `FormMixin` and
 `form_valid` is still executed. All checks passed - so behavior has not
 changed. To prevent existing Delete views overriding `delete` method from
 breaking, in this patch `form_valid()` calls `delete()`. If we want to add
 deprecation warning we could extend the patch. In `DeletionMixin.delete`
 we could emit a warning if HTTP method is  "POST".  Here:
 https://github.com/django/django/pull/15055/files#diff-
 bf5815bb9e60d6b9f1a261957863a70cc9ad03efdbd7941c0e1659b7ceb2895fR211

 {{{
 if request.method == "POST":
 # we arrived here from .form_valid(), let's emit warning
 }}}

 Anyway, if you believe that updating release notes is enough - I am fine
 with that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.64cc873baa1b362d13d3c6a58ba07571%40djangoproject.com.

Re: [Django] #33266: Auto-reload not detecting changes in Django 3.2

2021-11-04 Thread Django

#33266: Auto-reload not detecting changes in Django 3.2
---+--
 Reporter:  Brian Salcedo  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  3.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * cc: Tom Forbes (added)
 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 Hi, I don't think you've explained the issue in enough detail to confirm a
 bug in Django. Please reopen the ticket if you can debug your issue and
 provide details about why and where Django is at fault. A sample project
 would be helpful.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2682aedab88d9c17320892f86018e91a%40djangoproject.com.

Re: [Django] #33266: Auto-reload not detecting changes in Django 3.2

2021-11-04 Thread Django

#33266: Auto-reload not detecting changes in Django 3.2
--+--
 Reporter:  salcedo   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  3.2
 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
--+--
Description changed by salcedo:

Old description:

> I have tried using both StatReloader and WatchmanReloader, and runserver
> will detect changes and reload. Other Django projects 3.1.x or below on
> the same machine reload, but not reloading in Django 3.2.
>
> For reproduction:
> Python version: 3.9.7
> Django version: 3.2.9
> Arch: x86_64
> OS: Arch Linux
> Kernel: 5.14.16-hardened1-1-hardened (package: linux-hardened)
> Filesystem: /dev/mapper/vg0-root on / type btrfs
> (rw,relatime,compress=zstd:3,ssd,space_cache,subvolid=5,subvol=/)

New description:

 I have tried using both StatReloader and WatchmanReloader, and runserver
 will not detect changes and reload. Other Django projects 3.1.x or below
 on the same machine reload, but not reloading in Django 3.2.

 For reproduction:
 Python version: 3.9.7
 Django version: 3.2.9
 Arch: x86_64
 OS: Arch Linux
 Kernel: 5.14.16-hardened1-1-hardened (package: linux-hardened)
 Filesystem: /dev/mapper/vg0-root on / type btrfs
 (rw,relatime,compress=zstd:3,ssd,space_cache,subvolid=5,subvol=/)

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.da9e2475eb9abaa200407fe3f54f9043%40djangoproject.com.

[Django] #33266: Auto-reload not detecting changes in Django 3.2

2021-11-04 Thread Django

#33266: Auto-reload not detecting changes in Django 3.2
-+
   Reporter:  Brian Salcedo  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core (Other)   |Version:  3.2
   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 have tried using both StatReloader and WatchmanReloader, and runserver
 will detect changes and reload. Other Django projects 3.1.x or below on
 the same machine reload, but not reloading in Django 3.2.

 For reproduction:
 Python version: 3.9.7
 Django version: 3.2.9
 Arch: x86_64
 OS: Arch Linux
 Kernel: 5.14.16-hardened1-1-hardened (package: linux-hardened)
 Filesystem: /dev/mapper/vg0-root on / type btrfs
 (rw,relatime,compress=zstd:3,ssd,space_cache,subvolid=5,subvol=/)

-- 
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/050.9686e7d54e1f84bde99f1dc5fcec8b53%40djangoproject.com.

[Django] #33265: Form.get_context() backward-incompatibility

2021-11-04 Thread Django

#33265: Form.get_context() backward-incompatibility
---+
   Reporter:  Collin Anderson  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Forms|Version:  dev
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Hi All,

 The new `Form.get_context()` method was added in #31026 on Sept 20th, but
 this breaks any form that already has a different `get_context()` method,
 for example:

 https://github.com/ubernostrum/django-contact-
 
form/blob/a30a3de7e80936e47ec939e5275ef00f03342688/src/contact_form/forms.py#L94

 I'd suggest at least making sure this is documented in the release notes.
 But also, is there an upgrade-path for 3rd party libraries like `django-
 contact-form` that need to support multiple django versions?

 Thanks,
 Collin

-- 
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/057.459202743343bece54b14339e8d243fd%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 Hi Eugene — I've added [https://github.com/django/django/pull/15059/files
 an additional backwards incompatible change note on the 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/066.1d52f0a402893295f60ddffa3543dc1d%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 Yes, thanks — what I meant was that having a deprecation here stops us
 adopting the new behaviour. (What I can't see if a way of having it both
 ways, defaulting to the new behaviour but falling back to the old... — I
 guess it'd be possible.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.3f554c50d08d84881ca1bafe31596fe7%40djangoproject.com.

Re: [Django] #33264: DiscoverRunner doesn't counts unexpectedSuccess as an error

2021-11-04 Thread Django

#33264: DiscoverRunner doesn't counts unexpectedSuccess as an error
-+-
 Reporter:  Baptiste Mispelon|Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon):

 * has_patch:  0 => 1


Comment:

 Here is the PR: https://github.com/django/django/pull/15060 ✨

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.459781613c356cbd980d4356665983e4%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

Comment (by Eugene Prikazchikov):

By deprecation process I meant that initially behavior is kept the same,
but the warning is emitted in runtime. In our case, when `.delete` method
is reached during `POST` request, we could emit a warning like "the logic
from .delete() method must be moved to .form_delete()". Thus, people
should have enough time to update their code.
And then in one of following releases we change the behavior. Like
described here - https://docs.djangoproject.com/en/3.2/howto/upgrade-
version/#resolving-deprecation-warnings

Though perhaps a note in **backwards incompatible changes** would be
enough (like https://docs.djangoproject.com/en/3.2/releases/1.11
/#backwards-incompatible-1-11)

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.f65c5abf368f20fe2d9156378294697d%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 > Normally such breaking changes should be taken through deprecation
 process, no?

 Yes. I'm wondering what one would look like? Hmmm 🤔

 We could add an **additional** note to breaking changes.

 (I think the new features justify the breakage, so I'd not want to revert
 to maintain BC here.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ef956d4cc7229219a2718e0adda927e8%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

Comment (by Eugene Prikazchikov):

I understand that with new approach you need to move that kind of logic to
`form_valid()`, not to 'delete()` and I like that idea.

I was lucky enough to detect the broken behavior early on - the project is
covered by unit tests quite well and tests started to fail.
When migrating project without much tests, you can easily miss it, your
delete method will just be silently ignored. In the worst case you will
know about the problem only when your users start to complain.
I am wondering if we could make it more obvious to developers that
behavior has changed and their existing code **must** be updated.
Normally such breaking changes should be taken through deprecation
process, no?

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.354076d4748787f380a6ee73fe20da81%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 > I'd suggest a small addition to the release notes here...

 Pull request to that effect in https://github.com/django/django/pull/15059

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.22fcd5a0d000fb114a71b4a757622c6d%40djangoproject.com.

Re: [Django] #30577: feature request: custom rendering for readonly fields in admin

2021-11-04 Thread Django

#30577: feature request: custom rendering for readonly fields in admin
---+--
 Reporter:  David  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlos Palol):

 * cc: Carlos Palol (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/064.1f77d68ebe29a6792ba159ba5b7bac0b%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 OK, so the change here was intended, and doc'd but likely needs calling
 out better in the release notes.

 This was a deliberate change in #21936, finally resolved in
 [https://github.com/django/django/pull/14634 PR 14634] after 8 years and
 (I think) 4 previous PRs.

 The mainline there was:

 [https://github.com/django/django/pull/2585 PR 2585] to
 [https://github.com/django/django/pull/13362 PR 13362] to
 [https://github.com/django/django/pull/14634 PR 14634].

 The PR adjusted the inheritance structure to use `FormMixin` for `post`,
 allowing the confirmation step and success message. This is mentioned in
 the generic view docs and the
 [https://docs.djangoproject.com/en/4.0/releases/4.0/#generic-views Django
 4.0 release notes].

 The interplay with `DeletionMixin` complicated the issue significantly.
 This was first picked up by
 [https://code.djangoproject.com/ticket/21936#comment:9 Caroline Simpson
 working on the original PR].

 Happy to take input but after staring at it multiple times, for a long
 time, the only stable conclusion was to separate the `post()` HTTP handler
 from the `delete()` HTTP handler — proxying one to the other doesn't leave
 space for the form and messaging behaviour. (See the historical PRs for
 attempts in this direction.) Someone sending an API-like HTTP DELETE
 method request gets the old behaviour here. It's only browser based POST
 requests that are affected.

 Continuing to proxy `post()` to `delete()`, as the PR here suggests, ends
 up duplicating the `get_object()` and `get_success_url()` calls
 (essentially from the two mixing, but inlined in this case because of the
 tangled inheritance structure,
 [https://github.com/django/django/pull/14634/files#diff-
 bf5815bb9e60d6b9f1a261957863a70cc9ad03efdbd7941c0e1659b7ceb2895fR237-R240
 see comment].) Doing that is less than ideal: with the added `FormMixin`
 behaviour, `post()` is a much more complex handler than `delete()` —
 they're no longer equivalent.

 On the final PR
 [https://github.com/django/django/pull/14634#discussion_r669325533 Mariusz
 and I discussed adding an extra `_delete` hook, to be called by both
 `delete()` and `form_valid()` but agreed is was too much API].

 The correct approach is to implement your custom logic in `form_valid`,
 and per any `FormMixin` subclass. Or **if** the view is genuinely handling
 DELETE HTTP requests as well as POSTs, move the shared logic into a method
 called by **both** `form_valid` and `delete` (which would be the hook we
 decided not to add to the built-in CBV API).

 I'd suggest a small addition to the release notes here, along the lines of
 `"To accommodate this change custom logic in `delete()` methods should be
 moved to `form_valid()` or a shared helper method as needed."`

 I hope that makes sense. As I say, open to further input, but this seemed
 the minimum change that satisfied the desiderata.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1f8f01e91bf6639d236753226f30477b%40djangoproject.com.

Re: [Django] #32980: Improve performance of related manager attribute access

2021-11-04 Thread Django

#32980: Improve performance of related manager attribute access
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * needs_better_patch:  1 => 0


Comment:

 Marking as ready to have eyes on it once again, naturally can revert back
 to needs improvement.

 A question I've raised on the ticket, which I reproduce for historical
 purposes here, is:

 > There's one thing that isn't handled, because I'm not sure if/how it can
 actually happen, and that's the case of a ManyToManyField which is
 symmetrical and the branch entered is self.reverse is True. As far as I
 know, it's impossible to get a reverse manager for symmetrical m2ms, but
 if it's possible, it would currently pose a problem because get_cache_name
 defers to get_accessor_name and that returns None for symmetries, so there
 would be the possibility of a collision.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.aaa0881af6a27b61dd2efc0f842984ab%40djangoproject.com.

Re: [Django] #33264: DiscoverRunner doesn't counts unexpectedSuccess as an error

2021-11-04 Thread Django

#33264: DiscoverRunner doesn't counts unexpectedSuccess as an error
-+-
 Reporter:  Baptiste Mispelon|Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 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 Baptiste Mispelon):

 * owner:  nobody => Baptiste Mispelon
 * status:  new => assigned


Comment:

 Thanks for the quick triage and the git history research.

 I'll get started on a PR today.

 Meanwhile, if anyone finds this ticket looking for a workaround, it's easy
 enough to write a custom runner and point to it in `settings.TEST_RUNNER`:
 {{{#!py
 class CustomTestRunner(DiscoverRunner):
 """
 A custom test runner to get around Django bug
 https://code.djangoproject.com/ticket/33264
 """
 def suite_result(self, suite, result, **kwargs):
 return len(result.failures) + len(result.errors) +
 len(result.unexpectedSuccesses)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.aa360439a15392693af1bf8f27e93b00%40djangoproject.com.

Re: [Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
 Reporter:  Eugene Prikazchikov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Claude Paroz):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ea790ede85371ba0a6ff8b16097b833e%40djangoproject.com.

Re: [Django] #33237: ManifestStaticFilesStorage doesn't update JavaScript source map references in multiline files

2021-11-04 Thread Django

#33237: ManifestStaticFilesStorage doesn't update JavaScript source map 
references
in multiline files
-+-
 Reporter:  Joseph Abrahams  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  4.0
 Severity:  Release blocker  |   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/072.001b7a92e63f39d2d82344c2a8e25190%40djangoproject.com.

Re: [Django] #33264: DiscoverRunner doesn't counts unexpectedSuccess as an error

2021-11-04 Thread Django

#33264: DiscoverRunner doesn't counts unexpectedSuccess as an error
---+
 Reporter:  Baptiste Mispelon  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  3.2
 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):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report! As far as I'm aware this doesn't qualify for a
 backport and yes it's backward incompatible. This behavior is in Django
 from the very beginning (e.g. we take errors into account from 2007, see
 c1a73d80da65694319d803160b5e400e11318213). Python's `TestResult` treats
 unexpected successes as a tests failure since version
 
[https://docs.python.org/3/library/unittest.html?highlight=unexpectedsuccesses#unittest.TestResult.wasSuccessful
 3.4].

 I'd change this in Django 4.1 without a deprecation period.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f3f27a219ea9f447665df82ac13dc4e5%40djangoproject.com.

Re: [Django] #33253: Collectstatic fails when using ManifestStaticFilesStorage and specific Javascript file

2021-11-04 Thread Django

#33253: Collectstatic fails when using ManifestStaticFilesStorage and specific
Javascript file
-+-
 Reporter:  Hervé Le Roy |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  ManifestStaticFilesStorage |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  nobody => Carlton Gibson
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 I've opened a [https://github.com/django/django/pull/15058 draft PR] for
 this that tightens the regex to ≈valid identifiers plus `{},\s ` due to
 appearing in the `import`/`export`.
 I'm sure it can be improved. Comments welcome there.

 > removed the 's' in (?s: (Regex101 was reporting it as incorrect in
 Python regex syntax, and, anyway, Javascript import statement can be
 multi-line

 `(?s)` is [https://docs.python.org/3.10/library/re.html#re.DOTALL
 `re.DOTALL`] allowing `.` to match newlines, which matters for the multi-
 line 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/064.fbfe56879b78b077f7a19327b0cc7c02%40djangoproject.com.

Re: [Django] #27147: Add support for defining bounds in postgres range fields

2021-11-04 Thread Django

#27147: Add support for defining bounds in postgres range fields
-+-
 Reporter:  Kirill Stepanov  |Owner:  Guilherme
 |  Martins Crocetti
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgres range   | Triage Stage:  Ready for
  bounds |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8d36f72988eeab4038f1c22064b0f0b3%40djangoproject.com.

[Django] #33264: DiscoverRunner doesn't counts unexpectedSuccess as an error

2021-11-04 Thread Django

#33264: DiscoverRunner doesn't counts unexpectedSuccess as an error
-+
   Reporter:  Baptiste Mispelon  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  3.2
   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 noticed today that my CI test suite was green even though its console
 output printed:
 {{{
 FAILED (expected failures=13, unexpected successes=1)
 }}}

 It turns out that Django's default `DiscoverRunner` does not count
 "unexpected successes" as errors when deciding the return code of its
 `test` management command. [1]

 So even though it prints "FAILED", the command returns with an exit code
 of 0 which my CI (correctly) interprets as a success.

 The fix seems quite simple:
 {{{#!diff
 diff --git a/django/test/runner.py b/django/test/runner.py
 index 09ac4e142a..2e36514922 100644
 --- a/django/test/runner.py
 +++ b/django/test/runner.py
 @@ -875,7 +875,7 @@ class DiscoverRunner:
  teardown_test_environment()

  def suite_result(self, suite, result, **kwargs):
 -return len(result.failures) + len(result.errors)
 +return len(result.failures) + len(result.errors) +
 len(result.unexpectedSuccesses)

  def _get_databases(self, suite):
  databases = {}
 }}}

 But I wonder if that would be considered backwards incompatible.
 I also think this is a pretty serious issue and I wonder if backports
 would be considered for this.

 [1]
 
https://github.com/django/django/blob/60503cc747eeda7c61bab02b71f8f55a733a6eea/django/test/runner.py#L877-L878

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.dcfb6b0cb8e2b25700bb5403e593e084%40djangoproject.com.

Re: [Django] #33237: ManifestStaticFilesStorage doesn't update JavaScript source map references in multiline files

2021-11-04 Thread Django

#33237: ManifestStaticFilesStorage doesn't update JavaScript source map 
references
in multiline files
-+-
 Reporter:  Joseph Abrahams  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: gilmrjc (added)


Comment:

 Looks like the regression was introduced in
 781b44240a06f0c868254f40f36ce46c927f56d1 as part of #32319.
 (The multiline flag was removed switching to named groups.)

-- 
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/072.282ac68c6853c2db5a0037758df2a9f2%40djangoproject.com.

Re: [Django] #31685: Support updating conflicts with QuerySet.bulk_create().

2021-11-04 Thread Django

#31685: Support updating conflicts with QuerySet.bulk_create().
-+-
 Reporter:  Vitor Pereira|Owner:  Chih Sean
 |  Hsu
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk insert update   | Triage Stage:  Accepted
  upsert |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chih Sean Hsu):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.44d421f19be642b9bf92711c76127d6c%40djangoproject.com.

Re: [Django] #33237: ManifestStaticFilesStorage doesn't update JavaScript source map references in multiline files

2021-11-04 Thread Django

#33237: ManifestStaticFilesStorage doesn't update JavaScript source map 
references
in multiline files
-+-
 Reporter:  Joseph Abrahams  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  nobody => Carlton Gibson
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15056 PR] switching the regex to
 multiline mode.

 Joseph, if you're able to have a look, that would be great.

-- 
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/072.9df78b8a65dc19f393c764241c515956%40djangoproject.com.

[Django] #33263: DeleteView in Django4.0 does not call .delete() method

2021-11-04 Thread Django

#33263: DeleteView in Django4.0 does not call .delete() method
-+
Reporter: eprikazc | Owner: nobody
Type: Bug| Status: new
Component: Generic views |Version: 4.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+
I am giving a try to Django 4.0 on one of my projects and I see that
DeleteView.post does not call .delete() method anymore.

I understand that it was introduced when implementing the ticket
https://code.djangoproject.com/ticket/21936
particularly this line

https://github.com/django/django/commit/3a45fea0832c5910acee6e0d29f230f347a50462
#diff-bf5815bb9e60d6b9f1a261957863a70cc9ad03efdbd7941c0e1659b7ceb2895fR250

Some codebases in the wild might assume that .delete() method get always
called when DeleteView performs a deletion. I.e. .delete() method can be
seen not just as a handler for DELETE http method, but as part of public
interface of DeleteView - a place to specify what happens on object
deletion. For example, in my project I often override .delete() method to
do extra work - to make external API call or add a flash message, etc.
With Django4.0 it isn't working anymore.

If it is a bug - here is my attempt with test and fix for it -
https://github.com/django/django/pull/15055
If it is not a bug but intended behavior - perhaps it should be more
clearly documented, since it might break backwards compatibility for some
codebases.

--
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/051.96c704ccbae04bd37a6874696e7d6048%40djangoproject.com.

Re: [Django] #33247: PDF documentation build broken

2021-11-04 Thread Django

#33247: PDF documentation build broken
---+
 Reporter:  AndrewN|Owner:  AndrewN
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  3.2
 Severity:  Normal |   Resolution:  fixed
 Keywords: | 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:"95a4db3fbd946dd56f46f4c8c22be3b28083d845" 95a4db3]:
 {{{
 #!CommitTicketReference repository=""
 revision="95a4db3fbd946dd56f46f4c8c22be3b28083d845"
 Refs #33247 -- Fixed rendering of Unicode chars and emojis in PDF docs
 build.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.44273e9dc045f8de8367568dd9fdf13b%40djangoproject.com.

Re: [Django] #33256: Some schema tests don't clean up their tables

2021-11-04 Thread Django

#33256: Some schema tests don't clean up their tables
-+-
 Reporter:  Tim Graham   |Owner:  banani720
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > If I have not done all of the cases yet, but just want to check in to
 see if I am going about this the correct way, should I still submit a pr?

 I don't think there is a need to submit PR at this stage. You should be
 able to [https://docs.djangoproject.com/en/3.2/internals/contributing
 /writing-code/unit-tests/ run tests locally] and check that all `schema`
 tests work:
 {{{
 ./runtests.py --settings=test_postgres --parallel=1 --keepdb schema
 }}}
 I'd submit PR when all test pass.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.73a4d1370eafc92656956658d7054690%40djangoproject.com.

Re: [Django] #33256: Some schema tests don't clean up their tables

2021-11-04 Thread Django

#33256: Some schema tests don't clean up their tables
-+-
 Reporter:  Tim Graham   |Owner:  banani720
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by banani720):

 If I have not done all of the cases yet, but just want to check in to see
 if I am going about this the correct way, should I still submit a pr? I've
 added a `try-finally` clauses to a couple of the test cases that are
 mentioned in the error log. This is my first time contributing to an open-
 source and the tutorial isn't quite clear how I should handle a situation
 like this. Any guidance would be appreciated.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6638fa24401680ea996c7ff8083fc987%40djangoproject.com.

41 matches

Mail list logo