Re: [Django] #29098: Add SimpleTestCase.assertRedirectsRegex()

2018-11-05 Thread Django 
#29098: Add SimpleTestCase.assertRedirectsRegex()
---+-
 Reporter:  Dan J Strohl   |Owner:  Dan Davis
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords:  unittest redirect  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Dan Davis):

 * owner:  nobody => Dan Davis
 * status:  new => assigned
 * version:  1.11 => 2.1


Comment:

 I'll take this one.   Seems straight-forward enough.Not sure why it
 should be done on 1.11, because it doesn't seem severe enough.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.037bc767b75e865119f584b67bf97ade%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29884: QuerySet.filter() with TruncBase functions not working as expected when USE_TZ= True

2018-11-05 Thread Django 
#29884: QuerySet.filter() with TruncBase functions not working as expected when
USE_TZ= True
-+-
 Reporter:  slide33  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Dan Davis):

 * owner:  Dan Davis => (none)
 * status:  assigned => new
 * needs_tests:  1 => 0


Comment:

 Replying to [comment:9 Tim Graham]:
 > I don't expect this would require backend-specific tests. The queries
 results should be the same across all databases, shouldn't they? I haven't
 looking into this issue to say whether or not there's a bug here.

 This would be fixed in each backend separately, because the method to
 truncate a datetime is delegated to each backend separately.
 Nevertheless, since the unit tests are run against a specific backend, by
 default sqlite3, the test can be in
 `tests/db_functions/datetime/test_extract_trunc.py`.

 Pull request https://github.com/django/django/pull/10611 provides a
 failing test for the filtering case.   It isn't ready, but anyone else can
 see the diff.

 I've run this against sqlite3 and also against postgresql like this:
 {{{
 ./runtests.py --settings postgresql_settings
 db_functions.datetime.test_extract_trunc
 }}}

 I'm out of this one - I would want someone with more experience in the
 project to decide whether the single ticket should be fixed for all
 backends or just for PostgreSQL.

 One thing I notice is that make_aware is surprisingly not the same thing
 as adding the tzinfo to the datetime in the first place.   The following
 raises:

 {{{
 from datetime import datetime
 import pytz
 from django.utils.timezone import make_aware

 euberlin = pytz.timezone('Europe/Berlin')s a
 dt1 = datetime(2018, 10, 24, tzinfo=euberlin)
 dt2 = make_aware(datetime(2018, 10, 24))
 assert dt1 == dt2
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.bc6f2d7f8414ced94e4ebb1e1c7b4121%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27685: Allow autoreloader to use watchman

2018-11-05 Thread Django 
#27685: Allow autoreloader to use watchman
-+-
 Reporter:  Aymeric Augustin |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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 Tom Forbes):

 * needs_better_patch:  1 => 0


Comment:

 I've updated the PR considerably since last time. I've removed the entire
 pyinotify mess and replaced it with a concrete, working (at least on my
 machine!) watchman implementation.

 I've also worked out a pretty decent way of testing the reloaders. If we
 structure the inner loop as a generator we can run individual 'ticks' in
 tests using `next()`. The first tick will set up the files to be watched.
 Then we modify them in some way and then trigger another tick. This should
 then pick up the modifications we have made and do the right thing.

 I've used a metaclass to share 8 integration tests across the watchman and
 stat reloaders. Individually each class passes but when run as a whole
 module the watchman ones fail (perhaps due to the metaclass?), so I need
 to look into that.

 The watchman service is pretty good at cleaning itself up, if we can get
 it installed on a CI worker I think it would be safe to just run in the
 background indefinitely?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.524195d156cad4972eb3c68394c4e87a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29922: Windows/Linux, macOS button has opposite syntax

2018-11-05 Thread Django 
#29922: Windows/Linux,macOS button has opposite syntax
-+-
 Reporter:  Stevenerr|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  Linux, macOS,| Triage Stage:
  Windows, tutorial  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by Tim Graham):

 `py` is the Python launcher which is Windows only. Does it not work on
 your system? I think it's installed by default.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.dda42960d0fe0cec67ab976a48b144ee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29923: Quickstart code bit missing python command

2018-11-05 Thread Django 
#29923: Quickstart code bit missing python command
---+--
 Reporter:  Stevenerr  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 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:  1
---+--

Comment (by Tim Graham):

 It should work fine without `python`. Does it not work for you? Are you on
 Windows?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.000e7090061f65adcb0dcd0e9a65c2a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28401: Allow hashlib.md5() calls to work with FIPS kernels

2018-11-05 Thread Django 
#28401: Allow hashlib.md5() calls to work with FIPS kernels
-+-
 Reporter:  Andrew DiPrinzio |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  FIPS, md5| Triage Stage:
 |  Someday/Maybe
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 not aware of any discussion of the issue outside of the ticket. You
 can write to the DevelopersMailingList if you want to get a second opinion
 on your proposal. As a general solution (replacing all `hashlib.md5()`
 calls in Django with a fallback to sha256), I don't like the idea because
 of inconsistency possibilities in mixed (fips and non-fips) system
 environments the performance differences (perhaps insignificant). Of
 course, there's also the issue that md5 and sha256 sums are different
 lengths. Perhaps truncating the latter to be the length of md5 would help
 eliminate possible bugs due to differences.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.18957084d0a8b5a3d1835070a38d641f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29921: Default BooleanField.required different from Django 2.0 when using choices

2018-11-05 Thread Django 
#29921: Default BooleanField.required different from Django 2.0 when using 
choices
-+-
 Reporter:  bogdanbatog  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  BooleanField,| Triage Stage:
  widget, required   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Tim Graham):

 * type:  Uncategorized => Bug


Comment:

 This looks like expected behavior to me. With the model you gave, a true
 or false value is required since the field can't be null, therefore the
 user must provide a value. I imagine your use case might be an API request
 where if the user didn't provide a value, a value of false was saved?
 Django doesn't normally fallback to a model field default if a value isn't
 provided to a form, but maybe this merits a mention in the release notes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.549ee5b54a30af74b26e36652f52c845%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29923: Quickstart code bit missing python command

2018-11-05 Thread Django 
#29923: Quickstart code bit missing python command
-+
   Reporter:  Stevenerr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+
 Code bit for running all unit tests under the Quickstart header is missing
 the python command on line 5

 What it is
 1 $ git clone g...@github.com:YourGitHubName/django.git django-repo
 2 $ cd django-repo/tests
 3 $ pip install -e ..
 4 $ pip install -r requirements/py3.txt
 5 $ ./runtests.py

 What it should be
 1 $ git clone g...@github.com:YourGitHubName/django.git django-repo
 2 $ cd django-repo/tests
 3 $ pip install -e ..
 4 $ pip install -r requirements/py3.txt
 5 $ python ./runtests.py

 Here is the link -->
 https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /unit-tests/#running-the-unit-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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.9558907c7ded3a33f9cbb2e07d3b9b51%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29922: Windows/Linux,macOS button has opposite syntax

2018-11-05 Thread Django 
#29922: Windows/Linux,macOS button has opposite syntax
-+-
   Reporter:  Stevenerr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  master
  Documentation  |   Keywords:  Linux, macOS,
   Severity:  Normal |  Windows, tutorial
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+-
 Ex:
 Click on Windows --> returns Linux/macOS shell syntax
 ...\> py -m django --version

 Click on Linux/macOs --> returns Windows shell syntax
 $ python -m django --version

 Here is the link -->
 https://docs.djangoproject.com/en/2.1/intro/tutorial01/

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.9e8054fe3dd7d36e70258ae8c9428ae3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17: Metasystem optimization: Share select_related in memory

2018-11-05 Thread Django 
#17: Metasystem optimization: Share select_related in memory
-+-
 Reporter:  Adrian Holovaty  |Owner:  Philippe
 |  Raoult
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  feature caching  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 See TicketClosingReasons/DontReopenTickets.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.0ae118473b8b7ab24ae0133bfd98830d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17: Metasystem optimization: Share select_related in memory

2018-11-05 Thread Django 
#17: Metasystem optimization: Share select_related in memory
-+-
 Reporter:  Adrian Holovaty  |Owner:  Philippe
 |  Raoult
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  feature caching  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by James Pic):

 * cc: James Pic (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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.dafedc090b2782dca6431b53fc2c28ca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17: Metasystem optimization: Share select_related in memory

2018-11-05 Thread Django 
#17: Metasystem optimization: Share select_related in memory
-+-
 Reporter:  Adrian Holovaty  |Owner:  Philippe
 |  Raoult
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  feature caching  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by James Pic):

 Do you remember the discussion you had with Russ about this ?

 Identity Map is a common programming pattern:
 https://martinfowler.com/eaaCatalog/identityMap.html

 Is this good for re-opening ?

 - The ORM is much cleaner now than 7 years ago,
 - Many great ORMs have a builtin Identity Map, why can't Django's ?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.775c582d92fb8061df260bc4f00de147%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29908: Foreign key isn't set on object after related set access if ForeignKey uses to_field

2018-11-05 Thread Django 
#29908: Foreign key isn't set on object after related set access if ForeignKey 
uses
to_field
-+-
 Reporter:  Carsten Fuchs|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 Simon Charette):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.96ec40327fb1672ca84364a953274a15%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29916: Add isempty, lower_inc, upper_inc, lower_inf, and upper_inf range lookups

2018-11-05 Thread Django 
#29916: Add isempty, lower_inc, upper_inc, lower_inf, and upper_inf range 
lookups
-+-
 Reporter:  Peter J. Farrell |Owner:  Peter J.
 |  Farrell
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  lower_inf,   | Triage Stage:  Accepted
  upper_inf, isempty, lower_inc, |
  upper_inc  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Peter J. Farrell:

Old description:

> Add support for following functions for Postgres range fields that are
> currently not supported in Django:
>
> * isempty
> * lower_inc
> * upper_inc
> * lower_inf
> * upper_inf
>
> [https://www.postgresql.org/docs/9.3/static/functions-range.html]
>
> Example usage:
>
> {{{#!python
> MyObject.objects.filter(date_range__upper_inf=True)  # for infinity
> MyObject.objects.filter(date_range__upper_inf=False)  # for not infinity
> }}}
>
> Example code:
> [https://gist.github.com/peterfarrell/5c7b8d80319563813caba6320b568829]
>
> These can all be implemented as new ORM lookups for the Postgres range
> type fields so the Django ORM can gain parity with functionality
> available in Postgres range fields.

New description:

 Add support for following functions for Postgres range fields that are
 currently not supported in Django:

 * lower_inc
 * upper_inc
 * lower_inf
 * upper_inf

 [https://www.postgresql.org/docs/9.3/static/functions-range.html]

 Example usage:

 {{{#!python
 MyObject.objects.filter(date_range__upper_inf=True)  # for infinity
 MyObject.objects.filter(date_range__upper_inf=False)  # for not infinity
 }}}

 Example code:
 [https://gist.github.com/peterfarrell/5c7b8d80319563813caba6320b568829]

 These can all be implemented as new ORM lookups for the Postgres range
 type fields so the Django ORM can gain parity with functionality available
 in Postgres 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.902036d6331d6eb0532347c8078fbee9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29917: Admin actions are duplicated when using model admins with inheritance

2018-11-05 Thread Django 
#29917: Admin actions are duplicated when using model admins with inheritance
-+
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 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 Tim Graham):

 I [https://groups.google.com/d/topic/django-
 developers/-OWoYL_zryM/discussion made the proposal] to remove action
 collection from superclasses on django-developers.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.af9e1aed1d3eb2add1cf81bf696d2b78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29921: Default BooleanField.required different from Django 2.0 when using choices

2018-11-05 Thread Django 
#29921: Default BooleanField.required different from Django 2.0 when using 
choices
-+-
   Reporter: |  Owner:  nobody
  bogdanbatog|
   Type: | Status:  new
  Uncategorized  |
  Component:  Forms  |Version:  2.1
   Severity:  Normal |   Keywords:  BooleanField,
   Triage Stage: |  widget, required
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 Using a BooleanField with choices inside a ModelForm, without explicit
 blank or null attributes on the model, exhibits different defaults for
 required attribute on the widget in Django2.1 vs Django2.0.

 The code below prints True in Django2.1.2 and False in Django2.0.6

 {{{
 class XModel(models.Model):
   result_bool = models.BooleanField(
 choices=(
   (True, 'Positive'),
   (False, 'Negative'),
 ),
 default=False
   )


 class XForm(forms.ModelForm):
   class Meta:
 model = XModel
 fields = ['result_bool']


 XForm(XModel()).fields['result_bool'].required
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.7c0cd1242c211f6d8c818e3700973496%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29917: Admin actions are duplicated when using model admins with inheritance

2018-11-05 Thread Django 
#29917: Admin actions are duplicated when using model admins with inheritance
-+
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 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):

 > ...makes it impossible to judge the feature on its own merits.

 That’s not what I’m saying. What I’m saying is that we can’t just change a
 design decision in a bug fix. Not when there’s a one line change that just
 fixes it.

 We can change the feature if decided, but that would be done separately:
 the policy is that to change a design there needs to be a discussion and
 agreement on django-developers and so on.

 The impressive list of people is relevant because they obviously discussed
 this at length and spent a lot of time putting the feature together. It’s
 been unchanged for 10 years. They must have got something right.

 I’m not sure that I’m at all confident that we’d make a better decision
 now, having given it not much thought or time or effort at all.
 (I appreciate our time/thought/effort is not zero.)

 > ...my vote certainly counts less...

 No, your vote counts too. You’ll note I didn’t close your PR, or merge
 mine. I just dug up the history. I don’t mean to upset you. I’m just
 trying to get it right.

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

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

Re: [Django] #28401: Allow hashlib.md5() calls to work with FIPS kernels

2018-11-05 Thread Django 
#28401: Allow hashlib.md5() calls to work with FIPS kernels
-+-
 Reporter:  Andrew DiPrinzio |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  FIPS, md5| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by 01000101):

 This ticket was referenced in my PR for a similar fix/feature -
 https://github.com/django/django/pull/10605
 Was there ever any consensus  on the best way to handle these sort of
 FIPS-related fixes going forward?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.be495d639990d8d98fda42b4dbe13dba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29917: Admin actions are duplicated when using model admins with inheritance

2018-11-05 Thread Django 
#29917: Admin actions are duplicated when using model admins with inheritance
-+
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 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 Matthias Kestenholz):

 Well, I'm not of the opinion that the certainly very impressive group of
 people involved in the original work makes it impossible to judge the
 feature on its own merits.

 Tim also wrote in
 https://github.com/django/django/pull/10603#issuecomment-435624170 that
 following Python's usual inheritance is usually better than this type of
 "magic".

 But my vote certainly counts less here since I'm "just" a contributor and
 not a maintainer. So I still don't agree with keeping this behavior
 around, but as I already wrote on your pull request, it's your call.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2dd217c50e4a1d4589c06a196b16cc65%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29797: Allow the makemessages command to accept a directory to operate on like xgettext does

2018-11-05 Thread Django 
#29797: Allow the makemessages command to accept a directory to operate on like
xgettext does
-+-
 Reporter:  Terence Honles   |Owner:  Terence
 |  Honles
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  2.1
  commands)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Thanks for the thoughtful discussion all.

 I'm going to close again. I think Claude's points cover what we'll ship in
 core.

 It'd be a bit more work for your use-case but I expect writing a wrapper
 script to take the options you want would not be infeasible.
 Sorry if that's not perfect for you Terence.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.524a7323c01ad3f2a58b80d797de13f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29894: Read-only fields in ModelAdmin should not be placed at the end

2018-11-05 Thread Django 
#29894: Read-only fields in ModelAdmin should not be placed at the end
---+--
 Reporter:  Jannik Schürg  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  readonly   | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Why isn't using `fieldsets` the right approach here?
 
https://docs.djangoproject.com/en/2.1/ref/contrib/admin/index#django.contrib.admin.ModelAdmin.fieldsets

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.72e96f8fec6af1e574cdbf15f3e7489b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29911: Standardize delete_cached_value API on model Fields

2018-11-05 Thread Django 
#29911: Standardize delete_cached_value API on model Fields
-+-
 Reporter:  Taylor Hakes |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 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 Carlton Gibson):

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


Comment:

 Hi taylor, I'm going to close this as-is. If you can follow-up with
 answers to the questions we may re-open. 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.4e94139b7f31512dc5ee8473993c3b29%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29917: Admin actions are duplicated when using model admins with inheritance

2018-11-05 Thread Django 
#29917: Admin actions are duplicated when using model admins with inheritance
-+
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 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):

 So, following the discussion of the breaking change in the PRs, digging
 into the history, it seems the MRO based collection of actions has been in
 place for the entire history of the feature..

 It was introduced in #10505 as part of the original feature for v1.1. (The
 [https://github.com/django/django/commit/44f3080226#diff-
 3c42de3e53aba87b32c494f995a728dfR423 line in the diff].)

 `get_actions()` was
 [https://code.djangoproject.com/attachment/ticket/10505/admin-
 actions.9.diff introduced explicitly] to allow collection of actions from
 superclasses.

 Given the contributors to #10505, and that it was a conscious decision on
 their part, I'm don't feel we can just change the behaviour as part of a
 bug fix.

 Maybe there's a case for a change, but that should be made separately.
 (Currently the behaviour is not tested, but with
 [https://github.com/django/django/pull/10607 PR10607] it would be, and not
 documented, but a long-overdue paragraph could be 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.903ac12d71e55ab152303bcaf7758b3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28991: Add an admin filter with choices "all", "blank", "not blank"

2018-11-05 Thread Django 
#28991: Add an admin filter with choices "all", "blank", "not blank"
---+
 Reporter:  Jonas Haag |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Basil Dubyk):

 * owner:  Basil Dubyk => (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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1fc4999fa3740e35a999ae119713581e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28991: Add an admin filter with choices "all", "blank", "not blank"

2018-11-05 Thread Django 
#28991: Add an admin filter with choices "all", "blank", "not blank"
---+---
 Reporter:  Jonas Haag |Owner:  Basil Dubyk
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by Basil Dubyk):

 * owner:  nobody => Basil Dubyk
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8ab6ad6be6c3b76a62f67fdc1ddc7f41%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29915: Allow icontains lookup to accept uuids with or without dashes

2018-11-05 Thread Django 
#29915: Allow icontains lookup to accept uuids with or without dashes
-+-
 Reporter:  Václav Řehák |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  uuid admin   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Václav Řehák):

 Thank you for the quick answer. However, the proposed solution does not
 work as changing the uuid lookup to exact causes an error when searching
 for any string other than valid uuid value.

 I get ValidationError raised from UUIDField.to_python()


 {{{
 File "/home/vaclav/.local/share/virtualenvs/aaa-yRfablWV/lib/python3.7
 /site-packages/django/db/models/fields/__init__.py" in to_python
   2325. return uuid.UUID(value)

 File "/usr/lib/python3.7/uuid.py" in __init__
   160. raise ValueError('badly formed hexadecimal UUID
 string')
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.bedaf5b2a2183e847f132ad7f0ae26c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.