Re: [Django] #31841: DecimalField doesnt't respect max_digits when converting

[Django]

#31841: DecimalField doesnt't respect max_digits when converting
-+-
 Reporter:  Thiago Bellini   |Owner:  nobody
  Ribeiro|
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 felixxm):

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


Comment:

 Thanks for this ticket, however using `round()` is not an approach that
 will work in all cases, see [https://groups.google.com/g/django-
 developers/c/bnoVTOx2GFs/m/i0lNDpV8EgAJ discussion] and #28164. That's why
 we decided that providing a custom context to `DecimalField` is a proper
 way to fix this and similar issues, see #26459.

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

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

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+
 Reporter:  Markus Holtermann  |Owner:  felixxm
 Type:  Bug|   Status:  assigned
Component:  Core (Other)   |  Version:  3.1
 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 felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13260 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/065.9cd2e3e5f542797a2d543f7ee538c575%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+
 Reporter:  Markus Holtermann  |Owner:  felixxm
 Type:  Bug|   Status:  assigned
Component:  Core (Other)   |  Version:  3.1
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by felixxm):

 * owner:  nobody => felixxm
 * 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/065.90bc30843d99b8aba3338d1413adeffb%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+
 Reporter:  Markus Holtermann  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  3.1
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by felixxm):

 * stage:  Unreviewed => Accepted


Comment:

 Adding the `algorithm='sha256'` parameter to `loads()` and `dumps()`
 sounds reasonable, it's not much of a burden. However, I'm not sure if
 that's all you will need.

-- 
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.0ead392a2dd4f5e6beb50cc1190b1e0d%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+--
 Reporter:  Markus Holtermann  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  3.1
 Severity:  Release blocker|   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 Simon Charette):

 > I'm skeptical that Django should facilitate running multiple Django
 versions concurrently.

 I think we should allow find a way to multi-node upgrades to happen just
 like we do with `pickle_version` for anything that uses `pickle.dumps`.
 Large project Django upgrades are often
 [https://landing.google.com/sre/workbook/chapters/canarying-releases/
 tentatively deployed through canarying] and eventually rolled out to
 multiple nodes gradually (pods, dynos, etc.).

 Not having a way to a graceful roll out of a version should be considered
 a release blocker IMO.

-- 
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.9f5270eebb1a9f7a52b82567708833c2%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+--
 Reporter:  Markus Holtermann  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  3.1
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 I'm skeptical that Django should facilitate running multiple Django
 versions concurrently. I can't imagine there won't be other issues. Schema
 migrations are the first that come to mind.

-- 
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.29f101e1244193d056f330f407b553fb%40djangoproject.com.

[Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
-+
   Reporter:  Markus Holtermann  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core (Other)   |Version:  3.1
   Severity:  Release blocker|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 In Django 3.1, the default algorithm for `django.core.signing.Signer` was
 changed from sha1 to sha256. That's good!

 However, the `django.core.signing.dumps()` and
 `django.core.signing.loads()` functions don't expose the algorithm. I
 think, that that makes an upgrade from 3.0 to 3.1 impossible when one uses
 the `dumps()` function in a multi-node Django setup.

 Let's say there are two servers. Both run an application with Django 3.0.
 and make use of `dumps()` and `loads()`. Then server 1 is upgraded to use
 Django 3.1. At this point, because of to the backwards compatibility parts
 in the decoding/signature validation, a token signed by server 2 can be
 loaded on server 1 and 2. However, a token signed by server 1 cannot be
 loaded on server 2.

 This problem could be mitigated by exposing the algorithm in the `dumps()`
 method and setting it to `sha1`. Once all servers run Django 3.1, the
 algorithm could be changed to `sha256`.

-- 
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.eff2c837ad58fc11e2ab7724d836db65%40djangoproject.com.

Re: [Django] #31840: Adding Support for Cross-Origin Opener Policy

[Django]

#31840: Adding Support for Cross-Origin Opener Policy
-+-
 Reporter:  meggles711   |Owner:
 |  meggles711
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  COOP, security,  | Triage Stage:  Accepted
  headers|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by meggles711):

 Okay, sounds good, I'll cc some other developers and have them review my
 code before I make a pull request. I'll also check out the thread you
 started on the mailing list.

 I was considering pitching adding support for COOP and another header
 called Cross-Origin Embedder Policy (COEP) in the same issue. However,
 COEP relies on having a specific CORS or CORP header setting which Django
 doesn't currently have support for right now either. Maybe I consider
 tackling COEP and CORS/CORP now as well so that they don't have to be
 raised as 2 additional issues that are just adding security headers?

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

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

Re: [Django] #31841: DecimalField doesnt't respect max_digits when converting

[Django]

#31841: DecimalField doesnt't respect max_digits when converting
-+-
 Reporter:  Thiago Bellini   |Owner:  nobody
  Ribeiro|
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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
-+-

Comment (by Thiago Bellini Ribeiro):

 Just created a PR that fix this issue:
 https://github.com/django/django/pull/13258

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

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

[Django] #31841: DecimalField doesnt't respect max_digits when converting

[Django]

#31841: DecimalField doesnt't respect max_digits when converting
-+-
   Reporter: |  Owner:  nobody
  bellini666 |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 A field defined like this:

 {{{
 foo = models.DecimalField(max_digits=20, decimal_places=6)
 }}}

 When trying to set a float 0.2 it would give an error regarding the
 maximum decimal places. That because the context that converts the float
 to decimal only respect max_digits:

 {{{
 In [1]: import decimal

 In [2]: c = decimal.Context(prec=20)

 In [3]: c.create_decimal_from_float(0.2)
 Out[3]: Decimal('0.20001110')
 }}}

 For floats django should probably round the value to the decimal_places
 defined in the field.

-- 
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/053.661f50d6b5ee581aa535c8edff284504%40djangoproject.com.

Re: [Django] #27719: Add queryset.alias() to mimic .annotate() for aggregations without loading data

[Django]

#27719: Add queryset.alias() to mimic .annotate() for aggregations without 
loading
data
-+-
 Reporter:  Marc Tamlyn  |Owner:  Alexandr
 |  Tatarinov
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 Alexandr Tatarinov):

 * 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/066.5041cf3503716589312b86927d2add8d%40djangoproject.com.

Re: [Django] #26761: Add 'help_text' property to methods in ModelAdmin.list_display

[Django]

#26761: Add 'help_text' property to methods in ModelAdmin.list_display
---+--
 Reporter:  Derek Hohls|Owner:  Hasan Ramezani
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by felixxm):

 Replying to [comment:18 Hugo Osvaldo Barrera]:
 > On the other hand, `help_text` for method-fields seem to make perfect
 sense. They would be rendered on the `changeform` just like the
 `help_text` for any other readonly field.
 >
 > They also don't seem niche at all, and align very well with the existing
 admin UX.
 >
 > Do you think just the first item would be acceptable? Looks like the
 implementation can be extracted from  #12309, excluding the `changelist`
 changes.

 You can use `short_description` that already works for methods, that's
 more appropriate because you want to describe a value. `help_text` is
 rather an instruction for filling forms.

-- 
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.eefad889393eb34349d6e7af2ba730a5%40djangoproject.com.

Re: [Django] #31831: AlterOrderWithRespectTo() with ForeignKey crash when _order is included in Index(). (was: AlterOrderWithRespectTo has to proceed before AddIndex of '_order' field)

[Django]

#31831: AlterOrderWithRespectTo() with ForeignKey crash when _order is included 
in
Index().
+
 Reporter:  KyuJoo Han  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  3.0
 Severity:  Normal  |   Resolution:
 Keywords:  migrations  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by felixxm):

 * component:  Core (Management commands) => Migrations
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this report. IMO `order_with_respect_to` should be included in
 `CreateModel()`'s `options`, I'm not sure why it is in a separate
 operation when it refers to a `ForeignKey`.

-- 
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.7c25b751d5ef7da794e5dc96bb0b4881%40djangoproject.com.

Re: [Django] #26761: Add 'help_text' property to methods in ModelAdmin.list_display

[Django]

#26761: Add 'help_text' property to methods in ModelAdmin.list_display
---+--
 Reporter:  Derek Hohls|Owner:  Hasan Ramezani
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Hugo Osvaldo Barrera):

 I think this ticket somehow manages to mix up two very different requests
 into one:

 1. Add a `help_text` to methods:

 {{{
 from django.contrib import admin

 class AuthorAdmin(admin.ModelAdmin):
 fields = ('name', 'date_of_birth', 'is_underage')

 def is_underage(self, obj):
 return obj.age < 18

 is_underage.help_text = 'Indicates if the author is under 18.'
 }}}

 2. Show `help_text` as a `title` in `changelist`headers.

 As far as I understand the reason to reject this feature request are that
 this second feature seems to niche (note: I agree on that).

 On the other hand, `help_text` for method-fields seem to make perfect
 sense. They would be rendered on the `changeform` just like the
 `help_text` for any other readonly field.

 They also don't seem niche at all, and align very well with the existing
 admin UX.

 Do you think just the first item would be acceptable? Looks like the
 implementation can be extracted from  #12309, excluding the `changelist`
 changes.

-- 
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.0b261a69b32593226ced0f9df4256c79%40djangoproject.com.

Re: [Django] #27719: Add queryset.alias() to mimic .annotate() for aggregations without loading data

[Django]

#27719: Add queryset.alias() to mimic .annotate() for aggregations without 
loading
data
-+-
 Reporter:  Marc Tamlyn  |Owner:  Alexandr
 |  Tatarinov
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * 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/066.0c1ea20716b2f50b76491cc37070eccd%40djangoproject.com.

Re: [Django] #31840: Adding Support for Cross-Origin Opener Policy

[Django]

#31840: Adding Support for Cross-Origin Opener Policy
-+-
 Reporter:  meggles711   |Owner:
 |  meggles711
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  COOP, security,  | Triage Stage:  Accepted
  headers|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Florian Apolloner (added)


Comment:

 Noting also #31425 and #30729 are more or less the same as well. ("Add
 support for a header...")

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

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

Re: [Django] #31840: Adding Support for Cross-Origin Opener Policy

[Django]

#31840: Adding Support for Cross-Origin Opener Policy
-+-
 Reporter:  meggles711   |Owner:
 |  meggles711
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  COOP, security,  | Triage Stage:  Accepted
  headers|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Adam (Chainz) Johnson, Nick Pope (added)
 * stage:  Unreviewed => Accepted


Comment:

 OK, thanks. I'll provisionally Accept this, but cc a couple of people
 who've been involved before here, and also
 [https://groups.google.com/d/topic/django-
 developers/WJAbbwJKp30/discussion I've raised a question on the mailing
 list], since I'm not sure about ''just keep adding settings'' as the best
 approach here. (Maybe we adjust the "Accept" to something else...?)

 #30746 is the same ballpark here for Permissions-Policy

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

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

Re: [Django] #22406: Inconsistent way to parse boolean value from posted data

[Django]

#22406: Inconsistent way to parse boolean value from posted data
--+--
 Reporter:  xiaowl@…  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  1.6
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Thomas Hamann):

 Replying to [comment:3 Christian Kreuzberger]:
 > A similar inconsistency still exists in 1.11 with BooleanFields and
 NullBooleanFields in django.forms:
 >
 > NullBooleanField uses the NullBooleanSelect widget, while BooleanField
 uses the CheckboxInput widget:
 >
 > BooleanField uses django.forms.widget.CheckboxInput which evaluates
 'true','True',True,'1' to True, and 'false','False',False,'0' to False -
 which is fine.
 >
 >
 > But NullBooleanField uses NullBooleanSelect, which as stated above, does
 NOT evaluate 'false' to False, and not 'true' to True. Instead, it
 evalutes '2' and 'True' to True, '3' and 'False' to False...
 >
 This same behaviour in combination with a Google Chrome/Chromium 'feature'
 leads to some very unexpected behaviour that may cause people to assume
 their APIs are broken.

 In Chrome and many Chromium-based browsers first submitting a URL of the
 form:

 /my/site/?show_only_assigned_tasks=true

 and then re-submitting it as:

 /my/site/?show_only_assigned_tasks=True

 causes the browser to assume that the same URL was entered twice because
 the page caching mechanism apparently does not check on case-sensitivity!
 Apparently this is by design...

 As mentioned by Christian this works out fine for BooleanFields, but due
 to the inconsistency in the NullBooleanField string handling the API will
 seem to keep failing even when using the correctly capitalized URL after
 first using the wrongly capitalized one in Chrome/Chromium.

 There are two user-side solutions that do not involve using Christian's
 solution, and both are user-unfriendly:
 - empty browser cache
 - disable certain security settings

 It would be better if Django 1.11 could be patched to fix the issue.

 I don't know whether this same behaviour happens in Django 2.0 or above
 when using Chrome or Chromium, but it may be worth checking because just
 making a user click on intentionally wrong URLs in Chrome can result in a
 seemingly broken Django site.

-- 
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/075.b9ecf5ab9ffa72d8b65f7d0e4359a1d4%40djangoproject.com.

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * 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/068.3e43afb40bc13b4dd786d3c08894cd31%40djangoproject.com.

Re: [Django] #31839: Add additional database functions.

[Django]

#31839: Add additional database functions.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  functions, random,   | Triage Stage:
  truncate, log2, log10, bit |  Unreviewed
  length, octet length, hyperbolic   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 `Random()` is already there (as an expression) so we can change it to a
 function and promote in docs, I'm just not sure why we change its
 behavior.

 `Truncate()` can be confused with `Trunc()` for dates/datetimes, and we
 can achieve the same by using `Cast(..., models.IntegerField())` so I
 don't think it's necessary.

-- 
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.6d31b611c841f9d9aa76b09c7d4aad5f%40djangoproject.com.

Re: [Django] #28009: Document and test Field.empty_value for CharField subclasses

[Django]

#28009: Document and test Field.empty_value for CharField subclasses
-+-
 Reporter:  Matt Braymer-Hayes   |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Smith):

 * 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/066.9b3e2f279426f6f209b1464cb13e2434%40djangoproject.com.