Re: [Django] #26464: Addition to the "Security in Django": Incremental URLs/Identifiers

[Django]

#26464: Addition to the "Security in Django": Incremental URLs/Identifiers
---+--
 Reporter:  CrazyPython|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 As the introduction says, "This document is an overview of Django’s
 security features". How would you frame this issue as one of Django's
 features?

--
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.9c1ae169e5c8b85e320e6bd961b2eff3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26429: Name clash of merge migrations after squashing

[Django]

#26429: Name clash of merge migrations after squashing
-+-
 Reporter:  xgenadam |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  makemigrations   | Triage Stage:
  merge clash|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


--
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.f90262a463a9ec3328716078b00c5a44%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26459: DecimalField float rounding

[Django]

#26459: DecimalField float rounding
-+-
 Reporter:  yasondinalt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Could you give a snippet of the application code where you run into this
 issue?

--
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.bd4296b86e182fd290dcc2424468b45f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26464: Addition to the "Security in Django": Incremental URLs/Identifiers

[Django]

#26464: Addition to the "Security in Django": Incremental URLs/Identifiers
---+
 Reporter:  CrazyPython|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Documentation  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 Using incremental URLs (i.e. /comment/1 is the first comment and
 /comment/2 is the second comment, respectively for base 64 or other
 counting systems) is highly dangerous for private information. You could
 simply get all of the, say, private comments by accessing all comments
 sequentially and picking out the ones that are private. This can apply to
 confidential files (link sharing), personal information and more.

 There should be a section in the "Security in Django" about this.

--
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.473ebc98b80b5c87584ef5cb45381991%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26449: Document that SplitDateTimeWidget requires SplitDateTimeField

[Django]

#26449: Document that SplitDateTimeWidget requires SplitDateTimeField
--+
 Reporter:  MarysiaLowas  |Owner:  yakky
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.9
 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 timgraham):

 I didn't look at the code much, but your description of the issue reminds
 me of #12915. Could be related.

--
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.979f95d70ad14d06782d855af65a7ea1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26002: Improve ModelAdmin.get_search_results() example

[Django]

#26002: Improve ModelAdmin.get_search_results() example
--+
 Reporter:  timgraham |Owner:  bbenko
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.9
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/6392 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 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.70908253655de15d45d8efa8da5a86ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration

[Django]

#26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration
-+-
 Reporter:  oneTimePad   |Owner:
 |  oneTimePad
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  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
-+-
Changes (by timgraham):

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


Comment:

 I think the feature is too specialized for inclusion in Django. You could
 ask on the DevelopersMailingList to see if anyone else feels it's an
 appropriate use of a cache, but I'm skeptical. There are probably better
 ways to solve the problem in the linked ticket than this idea. Also
 requiring file-based or local memory caching in production is a bit
 impractical.

--
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/068.463914fea5ea54a6f70ed7f24747200a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26458: The Avg aggregate should only automatically resolves its output field to FloatField on numeric sources

[Django]

#26458: The Avg aggregate should only automatically resolves its output field to
FloatField on numeric sources
-+-
 Reporter:  charettes|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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 timgraham):

 * 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 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.7e5295bdcb53565f077ff410d8f7ba4f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration

[Django]

#26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration
-+-
 Reporter:  oneTimePad   |Owner:
 |  oneTimePad
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  Version:  master
 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 oneTimePad):

 Replying to [comment:2 timgraham]:
 > I'm not sure about this feature. It won't work for memcached where cache
 entries may be evicted without Django's knowledge, correct?

 I'm not sure about memcached, but I believe for the db cache it won't
 either. It seems to work nicely for filebased though, and possibly for
 locmem

--
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/068.0ce6388943259b12d15b8bfb5b37c8bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration

[Django]

#26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration
-+-
 Reporter:  oneTimePad   |Owner:
 |  oneTimePad
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  Version:  master
 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 timgraham):

 I'm not sure about this feature. It won't work for memcached where cache
 entries may be evicted without Django's knowledge, correct?

--
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/068.088f66f62da13f10614131b4c9ecd32c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14370: Adding support for Autocomplete in contrib.admin

[Django]

#14370: Adding support for Autocomplete in contrib.admin
-+-
 Reporter:  tyrion   |Owner:  codingjoe
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  autocomplete,| Triage Stage:  Accepted
  jquery, javascript, widgets,   |
  admin  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by airstrike):

 * cc: andreterra@… (removed)


--
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.7f806085df9d149e1d46ec8533eb06f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration

[Django]

#26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration
-+-
 Reporter:  oneTimePad   |Owner:
 |  oneTimePad
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by oneTimePad):

 * needs_better_patch:   => 0
 * component:  Core (Other) => Core (Cache system)
 * needs_tests:   => 0
 * needs_docs:   => 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/068.752b584dd14de4aa3f872d47be7c9f4a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration

[Django]

#26463: Allowing Callbacks/Handlers to be called on Cache entry Expiration
--+
 Reporter:  oneTimePad|  Owner:  oneTimePad
 Type:  New feature   | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 I read a suggestion about this here:
 [http://stackoverflow.com/questions/20866460/django-cache-backend-how-to-
 implement-callback-when-cache-timeout] .


 I have written up an implementation of it with some tests for
 FileBasedCache (filebased.py) and want to add it to locmem.py too (not
 done  yet).

 Here are code snippets from filebased.py that have been tested:
The edits  are in set and _is_expired
 {{{
  def set(self, key, value, timeout=DEFAULT_TIMEOUT,
 version=None,handler=None):
 self._createdir()  # Cache dir can be deleted at any time.
 fname = self._key_to_file(key, version)
 self._cull()  # make some room if necessary
 fd, tmp_path = tempfile.mkstemp(dir=self._dir)
 renamed = False
 try:
 with io.open(fd, 'wb') as f:
 expiry = self.get_backend_timeout(timeout)
 f.write(pickle.dumps(expiry, pickle.HIGHEST_PROTOCOL))
 #check if handler exists
 if handler:
   #write handler to pickle
   f.write(pickle.dumps(handler,pickle.HIGHEST_PROTOCOL))
 f.write(zlib.compress(pickle.dumps(value,
 pickle.HIGHEST_PROTOCOL)))
 file_move_safe(tmp_path, fname, allow_overwrite=True)
 renamed = True
 finally:
 if not renamed:
 os.remove(tmp_path)


  def _is_expired(self, f):
 """
 Takes an open cache file and determines if it has expired,
 deletes the file if it is has passed its expiry time.
 """
 exp = pickle.load(f)
 if exp is not None and exp < time.time():
 #if there is a handler, call it
 try:
   handler = pickle.load(f)
   handler(exp)
 except pickle.UnpicklingError:
  #handler not added(no handler specified), so pickling error
 occurs
   pass
 f.close()  # On Windows a file has to be closed before
 deleting
 self._delete(f.name)
 return True
 return False
 }}}

 The handler has the following format

 {{{
 class Handler(object):
   def __call__(self,exp):
 ...
 }}}

--
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/053.f4e20def94b5d7d2660b0c87a67ac88a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26449: Document that SplitDateTimeWidget requires SplitDateTimeField

[Django]

#26449: Document that SplitDateTimeWidget requires SplitDateTimeField
--+
 Reporter:  MarysiaLowas  |Owner:  yakky
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.9
 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 MarysiaLowas):

 I would like to clarify one thing as I'm not sure I understand the
 solution.

 Django Admin, by default uses the `AdminSplitDateTime` widget for model
 `DateTimeField` with `forms.SplitDateTimeField`. However, when I try to
 change the default widget with `formfield_overrides` to another widget
 derived from `SplitDateTimeWidget`, it doesn't work -> validation error.

 This is especially striking, when I try to override the default
 `AdminSplitDateTime` widget with the very same `AdminSplitDateTime`
 widget. (That was just for tests, in fact I wanted to use Django Suit
 `suit.widgets.SuitSplitDateTimeWidget`)

 From my investigation, it turned out that Django Admin treats model
 `DateTimeField` a bit specially. It defines not only the default widget
 but also the `form_class`.

 {{{#!python
 FORMFIELD_FOR_DBFIELD_DEFAULTS = {
 models.DateTimeField: {
 'form_class': forms.SplitDateTimeField,
 'widget': widgets.AdminSplitDateTime
 },
 models.DateField: {'widget': widgets.AdminDateWidget},
 models.TimeField: {'widget': widgets.AdminTimeWidget},
 #...
 }
 }}}

 It works fine, but when I want to override it with:
 {{{#!python
formfield_overrides = {
 models.DateTimeField: {'widget':
 suit.widgets.SuitSplitDateTimeWidget},
 }
 }}}

 The resulting dictionary looks something like that:

 {{{#!python
 overrides = {
 models.DateTimeField: { 'widget':
 suit.widgets.SuitSplitDateTimeWidget},
 models.DateField: {'widget': widgets.AdminDateWidget},
 models.TimeField: {'widget': widgets.AdminTimeWidget},
 #...
 }
 }}}

 The `form_class` is gone as so the `forms.DateTimeField` is used instead
 of `forms.SplitDateTimeField` and that causes the validation error.

 Is it a desired behaviour?
 If yes, maybe it's good to update also the `formfield_overrides`
 documentation, not just the docstring for `AdminSplitDateTime` widget?
 Or maybe it's better to keep the `form_class` value and override just
 `widget`?

 BTW, I planned to look into this but I run out of time during Sprints. I'm
 still quite happy to carry on if needed.

--
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.8fb7111a55bb4f840ef0be1c0f32709b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26462: UnicodeEncodeError when warning about too long caching keys on Python 2

[Django]

#26462: UnicodeEncodeError when warning about too long caching keys on Python 2
-+
 Reporter:  suligap  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  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 charettes):

 * version:  1.9 => master
 * type:  Uncategorized => Bug
 * 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 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.5c145a2cd143822aec9d2c452d09b05a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25530: Deferred SQL operations fail when a referenced table or column is renamed during the same migration (was: Deferred foreign keys operations fail when the column is changed during t

[Django]

#25530: Deferred SQL operations fail when a referenced table or column is 
renamed
during the same migration
--+
 Reporter:  simonphilips  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  1.8
 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 charettes):

 #26461 was a duplicate caused by an implicit table rename through a
 `RenameModel` operation.

 I think a possible solution would be to add state dependency tracking to
 `deferred_sql`. This way `RenameModel`, `AlterField`, `RenameField` and
 `AlterModelTable` operations could alter it to rename the references and
 `RemoveModel`, `RemoveField` operations could make sure to remove the
 unnecessary statements.

 For example, the `AddField` operation above would add a tuple of the form
 `('CREATE INDEX ...', [(ModelState('bug', 'child', [...]), 'child'),
 (ModelState('bug_parent', 'parent', [...]), 'id)]` (as it depends on both
 state and fields) and the `AlterField` operation would loop over all
 `editor.deferred_sql` and make sure to replace both the  SQL and the state
 of items depending on the model state it's about to alter. Model level
 operations (`RenameModel`, `AlterModelTable`) could simply use `None` as
 field to denote they depend on the model state itself.

 As for the SQL replacing part I think it would make more sense to
 introduce a class encapsulating the statement format string and its
 dependency than naively performing `str.replace('old_table_name',
 'new_table_name')` on the constructed SQL. This wrapper could also
 subclass `str` in order to maintain backward compatibility with the actual
 `deferred_sql`  API.

 Thoughts?

--
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.8830e5f134f2ae2127b4ac3e947733b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26462: UnicodeEncodeError when warning about too long caching keys on Python 2

[Django]

#26462: UnicodeEncodeError when warning about too long caching keys on Python 2
-+-
 Reporter:  suligap  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by suligap):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Cache system)
 * needs_tests:   => 0
 * needs_docs:   => 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/065.34edbcc52221b13c84c3007fed208faa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26461: django.db.utils.ProgrammingError: relation "..." does not exist

[Django]

#26461: django.db.utils.ProgrammingError: relation "..." does not exist
-+-
 Reporter:  prokaktus|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgresql,  | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This is a duplicate of #25530, the crash happens at index creation of the
 slug field as the `CREATE INDEX` statement still refers to the original
 table name.

--
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.ecc9554ce5357eeba1278624a889904b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26462: UnicodeEncodeError when warning about too long caching keys on Python 2

[Django]

#26462: UnicodeEncodeError when warning about too long caching keys on Python 2
---+
 Reporter:  suligap|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 On Python 2 `warnings.warn()` expects a `message` that can be coerced to a
 `str`.

 {{{
 Python 2.7.10 (default, Oct 14 2015, 16:09:02)
 [GCC 5.2.1 20151010] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import warnings
 >>> warnings.warn(u'清')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python2.7/warnings.py", line 33, in _show_warning
 file.write(formatwarning(message, category, filename, lineno, line))
   File "/usr/lib/python2.7/warnings.py", line 42, in formatwarning
 s =  "%s:%s: %s: %s\n" % (filename, lineno, category.__name__,
 message)
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u6e05' in
 position 0: ordinal not in range(128)
 }}}

 `BaseCache.validate_key()`
 
[https://github.com/django/django/blob/d356bb653f4d90ae9809e5a051791ded39010c38/django/core/cache/backends/base.py#L237-L238
 fails to create a proper `message`] by using `"%s"` to interpolate the key
 into the `message` instead of using `"%r"`.

--
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/050.0ab05c6ab2ae3ce800c2a4b984e9e463%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26460: Don't call ``warnings.warn`` for each invalid character in a caching key

[Django]

#26460: Don't call ``warnings.warn`` for each invalid character in a caching key
-+-
 Reporter:  suligap  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"d356bb653f4d90ae9809e5a051791ded39010c38" d356bb6]:
 {{{
 #!CommitTicketReference repository=""
 revision="d356bb653f4d90ae9809e5a051791ded39010c38"
 Fixed #26460 -- Issued a single warning for invalid cache key
 }}}

--
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.458cfb3c12661e11c517e36c12bf2502%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26461: django.db.utils.ProgrammingError: relation "..." does not exist

[Django]

#26461: django.db.utils.ProgrammingError: relation "..." does not exist
+
 Reporter:  prokaktus   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.9
 Severity:  Normal  |   Keywords:  postgresql, migrations
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Hi!

 {{{
 psql (PostgreSQL) 9.4.5
 Django==1.9.5
 psycopg2==2.6.1
 python2.7/python3.4
 }}}

 Exception occurs while running one-file migration with `AddField` and
 `RenameModel`. If I split the file into different files, all migrations
 passing ok. With `sqlite3`-engine  issue is not reproduced, because of
 that I think that it can be `postgres`-specific problem.

 Minimal example of my migration file:
 {{{
 from __future__ import unicode_literals

 from django.db import migrations, models


 class Migration(migrations.Migration):

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='Mymodel',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ],
 ),
 migrations.AddField(
 model_name='mymodel',
 name='name',
 field=models.SlugField(max_length=100, null=True),
 ),
 migrations.RenameModel( # <- error here
 old_name='Mymodel',
 new_name='NewModel',
 ),
 ]
 }}}

 As I said above, If I split files into two or remove `AddField` or
 `RenameModel` -- exception is gone. Problem not reproduced with
 `CharField`, but reproduced with `ForeignKey`.

 models.py:
 {{{
 from django.db import models


 class NewModel(models.Model):
 name = models.SlugField(max_length=100, null=True)
 }}}

 And lastly exception stacktrace:
 {{{
 ./manage.py migrate base 0001
 Operations to perform:
   Target specific migration: 0001_initial, from base
 Running migrations:
   Rendering model states... DONE
   Applying base.0001_initial...Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 353, in
 execute_from_command_line
 utility.execute()
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 345, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 348, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 399, in execute
 output = self.handle(*args, **options)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 200, in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 92, in migrate
 self._migrate_all_forwards(plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 121, in
 _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 198, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 90, in __exit__
 self.execute(sql)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 110, in execute
 cursor.execute(sql, params)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/max/.virtualenvs/test_django/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
 

Re: [Django] #26460: Don't call ``warnings.warn`` for each invalid character in a caching key

[Django]

#26460: Don't call ``warnings.warn`` for each invalid character in a caching key
-+-
 Reporter:  suligap  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * type:  Uncategorized => Cleanup/optimization
 * version:  1.9 => master
 * component:  Uncategorized => Core (Cache system)
 * stage:  Unreviewed => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.61dfcf585b08a16de04a90eb07bfa796%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26460: Don't call ``warnings.warn`` for each invalid character in a caching key

[Django]

#26460: Don't call ``warnings.warn`` for each invalid character in a caching key
---+--
 Reporter:  suligap|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by suligap):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> BaseCache.validate_key() will call `warnings.warn()`
> [https://github.com/django/django/blob/15a20dc9aff1bd8a055ee7c322631b3ca4d1c474/django/core/cache/backends/base.py#L240-L244
> for each invalid character in the key]. This is not a big issue since
> only one warning will appear but it is unnecessary.

New description:

 BaseCache.validate_key() will call `warnings.warn()`
 
[https://github.com/django/django/blob/15a20dc9aff1bd8a055ee7c322631b3ca4d1c474/django/core/cache/backends/base.py#L240-L244
 for each invalid character in the key]. This is not a big issue since only
 one warning will appear but it is unnecessary.

 Fixed in https://github.com/django/django/pull/6414

--

--
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.47911bbcd3ce4319be2556421c12fa57%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26460: Don't call ``warnings.warn`` for each invalid character in a caching key

[Django]

#26460: Don't call ``warnings.warn`` for each invalid character in a caching key
---+
 Reporter:  suligap|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 BaseCache.validate_key() will call `warnings.warn()`
 
[https://github.com/django/django/blob/15a20dc9aff1bd8a055ee7c322631b3ca4d1c474/django/core/cache/backends/base.py#L240-L244
 for each invalid character in the key]. This is not a big issue since only
 one warning will appear but it is unnecessary.

--
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/050.17c56cb12323789ec2302baf0537ce29%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26459: DecimalField float rounding

[Django]

#26459: DecimalField float rounding
-+-
 Reporter:  yasondinalt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yasondinalt):

 * Attachment "0001-tests-format-float-to-Decimal-with-proper-
 rounding.patch" added.

 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/069.f09637422215dc25e4b5ed09585bee7c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26459: DecimalField float rounding

[Django]

#26459: DecimalField float rounding
-+-
 Reporter:  yasondinalt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yasondinalt):

 * needs_better_patch:   => 0
 * needs_tests:   => 1
 * needs_docs:   => 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/069.ce2e7c2ad1520d4996bb878dcf9f86c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26459: DecimalField float rounding

[Django]

#26459: DecimalField float rounding
--+
 Reporter:  yasondinalt   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by yasondinalt):

 * Attachment "0001-tests-format-float-to-Decimal-with-proper-
 rounding.patch" added.

 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/069.482498743d066ec01cf0ecc256675d26%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26459: DecimalField float rounding

[Django]

#26459: DecimalField float rounding
--+
 Reporter:  yasondinalt   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by yasondinalt):

 * Attachment "0001-DecimalField-rounding-first-cast-to-str-then-use-
 ROU.patch" added.

 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 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.4d77e71e1ca80f0d6c3b555f141109eb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26459: DecimalField float rounding

[Django]

#26459: DecimalField float rounding
--+
 Reporter:  yasondinalt   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 DecimalField has weird behavior in case of float values passed to field.
 If decimal_places = 1
 float 2.15 will be saved as 2.1 (!)
 float 2.25 will be saved as 2.2 (!)
 But if float value first converted to str:
 float 2.15 will be saved as 0.2 (ok)
 float 2.25 will be saved as 0.2 (!)
 It's because of default decimal rounding ROUND_HALF_EVEN.
 As I understand build-in round() use rounding similar to ROUND_HALF_UP.

 I tried first cast float to str, then use ROUND_HALF_UP, so now:
 float 2.15 will be saved as 0.2 (ok)
 float 2.25 will be saved as 0.3 (ok)

--
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.f981668fae30064528b2caa9bda9a918%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26434: Inconsistent results of QuerySet count() method using PostgreSQL backend prior and post the QuerySet evaluation

[Django]

#26434: Inconsistent results of QuerySet count() method using PostgreSQL backend
prior and post the QuerySet evaluation
-+-
 Reporter:  kamandol |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql queryset  | Triage Stage:  Accepted
  count annotate aggreagate  |
  order_by   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kamandol):

 I will change the branch as requested.

 You're right, the faulty behavior was detected on PostgreSQL, but on MySQL
 worked correctly so the test should pass. Could not test other db engines
 though. I will remove that extra piece of code.

--
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.3c955c1159d4276675bd3ae9450b06a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26458: The Avg aggregate should only automatically resolves its output field to FloatField on numeric sources

[Django]

#26458: The Avg aggregate should only automatically resolves its output field to
FloatField on numeric sources
-+-
 Reporter:  charettes|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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
-+-
Changes (by charettes):

 * has_patch:  0 => 1


Comment:

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

--
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.40e017492cce8be3f656b7a23c6edf27%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26434: Inconsistent results of QuerySet count() method using PostgreSQL backend prior and post the QuerySet evaluation

[Django]

#26434: Inconsistent results of QuerySet count() method using PostgreSQL backend
prior and post the QuerySet evaluation
-+-
 Reporter:  kamandol |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql queryset  | Triage Stage:  Accepted
  count annotate aggreagate  |
  order_by   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


Comment:

 If you could put the tests on a branch of you fork other than "master"
 that seems a bit safer. There is probably no need for `skipUnlessDBEngine`
 - is there a reason the queries shouldn't also work on other databases?
 Anyway, the usual way to skip tests is based on database features.

--
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.d1bbe3658d1982df59d7220e92506859%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26458: The Avg aggregate should only automatically resolves its output field to FloatField on numeric sources

[Django]

#26458: The Avg aggregate should only automatically resolves its output field to
FloatField on numeric sources
-+-
   Reporter:  charettes  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Before #24649 was fixed it was simply not possible to use the `Avg`
 function on non-numeric sources.  The *good enough* solution was to allow
 use of the `output_field` kwarg and document it should be used when
 averaging `DurationField`.

 As `DurationField` uses different underlying datatype for its storage
 (bigint, interval, ...) averaging on such fields
 [https://groups.google.com/d/msg/django-users/BwkK7R1WXYU/k4b5nzNwAQAJ
 might require or not] an explicit `output_field` and can be a source of
 confusion.

 As the SQL `AVG` function only defaults to using floating value datatype
 as a return value when numeric input is used I suggest adjusting the `Avg`
 expression's `output_field` resolution to only use `FloatField` for
 default when its source field is an instance of one of Django's numerical
 field classes. This would lift the requirement of explicitly specifying an
 `output_field` when averaging `DurationField` on PostgreSQL.

--
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.fe4d27aa1149e37c03d8b384f3b7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25847: Make User.is_authenticated() and User.is_anonymous() "callable properties"

[Django]

#25847: Make User.is_authenticated() and User.is_anonymous() "callable 
properties"
---+
 Reporter:  skorokithakis  |Owner:  jlaine
 Type:  New feature|   Status:  assigned
Component:  contrib.auth   |  Version:  1.9
 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 timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left comments for improvement.

--
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.69362af18f2806fe90d408048ab16882%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26442: Get rid of geodjango.org

[Django]

#26442: Get rid of geodjango.org
-+-
 Reporter:  sephii   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 [https://groups.google.com/d/topic/django-
 developers/aqFoO3WeDeE/discussion django-developers thread]. The issue is
 that the Django Software Foundation doesn't control the domain.

--
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.1db8dc8f02b1657baa213051cb03d61e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26290: Pagination module should warn about unordered query set

[Django]

#26290: Pagination module should warn about unordered query set
-+-
 Reporter:  kartikanand  |Owner:
 Type:   |  EmadMokhtar
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  pagination   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * needs_tests:  1 => 0


Comment:

 Left some comments for improvement and a few test failures remain.

--
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.dbf6d35f489c531d2ec903d7258cbcad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26052: Consider removing conditional_content_removal

[Django]

#26052: Consider removing conditional_content_removal
--+
 Reporter:  aaugustin |Owner:  susan
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  HTTP handling |  Version:  1.9
 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 timgraham):

 * needs_better_patch:  0 => 1


Comment:

 I think the PR needs improvement as described in the ticket description,
 "mod_wsgi, gunicorn and uwsgi properly strip the body of HEAD requests
 before proceeding. We should also move that behavior into `runserver`."

--
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.2c73de9350124416256724353dc01242%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26419: Description of ALLOWED_HOSTS confusing

[Django]

#26419: Description of ALLOWED_HOSTS confusing
--+
 Reporter:  jtpereyda |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"f8b88f6a6bbfec210c2a87b75d2837cbe57f8e42" f8b88f6]:
 {{{
 #!CommitTicketReference repository=""
 revision="f8b88f6a6bbfec210c2a87b75d2837cbe57f8e42"
 [1.9.x] Fixed #26419 -- Added a link in ALLOWED_HOSTS docs.

 Backport of f8b31dfdfc0cf6a516bcbc10c4e2f696ce3a9bda from master
 }}}

--
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.d6776611705eb54497c87644db6b11e1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26419: Description of ALLOWED_HOSTS confusing

[Django]

#26419: Description of ALLOWED_HOSTS confusing
--+
 Reporter:  jtpereyda |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"f8b31dfdfc0cf6a516bcbc10c4e2f696ce3a9bda" f8b31dfd]:
 {{{
 #!CommitTicketReference repository=""
 revision="f8b31dfdfc0cf6a516bcbc10c4e2f696ce3a9bda"
 Fixed #26419 -- Added a link in ALLOWED_HOSTS docs.
 }}}

--
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.7d20968a50b4483befb5986404e7d939%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25856: JS strftime shim could (sometimes) support %B

[Django]

#25856: JS strftime shim could (sometimes) support %B
--+
 Reporter:  kezabelle |Owner:  akoskaaa
 Type:  New feature   |   Status:  assigned
Component:  Internationalization  |  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 timgraham):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.43ae54fd4a1113a25ecda8a9efb72884%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26447: Remove USE_ETAGS setting

[Django]

#26447: Remove USE_ETAGS setting
--+
 Reporter:  syphar|Owner:  syphar
 Type:  Cleanup/optimization  |   Status:  new
Component:  Uncategorized |  Version:  1.9
 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 timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left comments for improvement on the
 [https://github.com/django/django/pull/6393 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 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.3aade101e4d14d7634a28e3b985b2ea0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26455: Add lookups and database functions to check for valid geometries and repairing them.

[Django]

#26455: Add lookups and database functions to check for valid geometries and
repairing them.
-+-
 Reporter:  yellowcap|Owner:  yellowcap
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  isvalid, makevalid,  | Triage Stage:  Accepted
  valid, geometry|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * 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 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.aa55d4436bdfa761fe6b71d5b061798f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26452: Load middleware on server start rather than on first request

[Django]

#26452: Load middleware on server start rather than on first request
--+
 Reporter:  evansd|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  HTTP handling |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"99bb7fcc1859615a7b8c2468e7b97d54853bfb10" 99bb7fcc]:
 {{{
 #!CommitTicketReference repository=""
 revision="99bb7fcc1859615a7b8c2468e7b97d54853bfb10"
 Fixed #26452 -- Loaded middleware on server start rather than on first
 request.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.5c36e4f6d2ca2458657992dbc39f8f4f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26457: Recolor admin boolean field icons from green and red (was: Boolean fields assume True is good and False is bad)

[Django]

#26457: Recolor admin boolean field icons from green and red
-+-
 Reporter:  newz2000 |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => contrib.admin
 * needs_tests:   => 0
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization


Comment:

 A design decision like this needs to be made on the DevelopersMailingList.
 Please start a thread there. If there's consensus to change the icons, we
 can reopen the ticket.

--
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.587880c3268fd4df6f35ab055adb3f4b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26449: Document that SplitDateTimeWidget requires SplitDateTimeField

[Django]

#26449: Document that SplitDateTimeWidget requires SplitDateTimeField
--+
 Reporter:  MarysiaLowas  |Owner:  yakky
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.9
 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 timgraham):

 I don't think it's needed.

--
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.5aa044e2816c1f03335856a1ce506d99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9249: Google Analytics' Cookies break CacheMiddleware when SessionMiddleware turns on Vary: Cookie

[Django]

#9249: Google Analytics' Cookies break CacheMiddleware when SessionMiddleware
turns on Vary: Cookie
---+
 Reporter:  pixelcort  |Owner:  ambv
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  1.0
 Severity:  Normal |   Resolution:
 Keywords:  cache cookies  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by collinanderson):

 A work around is to create a middleware that deletes all the cookies in
 request.COOKIE that django should ignore. (Just don't delete the important
 cookies. :) Example from DjangoCon.eu  2016: https://youtu.be/AZ4ISa1u-
 HE?t=12548

--
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.6245628a9ef51c675ff66c9b92d8f5ad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26449: Document that SplitDateTimeWidget requires SplitDateTimeField

[Django]

#26449: Document that SplitDateTimeWidget requires SplitDateTimeField
--+
 Reporter:  MarysiaLowas  |Owner:  yakky
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.9
 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 yakky):

 timgraham should I also leave the note in AdminSplitDateTime, or should I
 remove it?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.13594ea4e66d8f9b507bd215363dbb83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26457: Boolean fields assume True is good and False is bad

[Django]

#26457: Boolean fields assume True is good and False is bad
---+
 Reporter:  newz2000   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  1
---+
 '''Background'''
 Some colors convey information. Red means stop, danger, needs attention.
 Green, when accompanying red, means go, good, everything is OK.

 '''Problem'''
 When using the list display in the Django admin, boolean fields by default
 are shown as a red circle with an "x" in it for False values, and a green
 "checkmark" for True. Because of the color and the icon choices, this
 makes the assumption that True is good and False is bad.

 '''How to reproduce'''
 1. Create a model that has a field for "note" and one for "Needs urgent
 attention"
 1. Add a record such as: note: "London Bridge is falling down," Needs
 urgent attention: True.
 1. Add a record such as: note: "I think we should have casual dress on
 Fridays", Needs urgent attention: False.

 When you look at these, the casual dress note will have a red x, which
 conveys alarm, while the falling bridge will have a green checkmark, which
 conveys an acceptable state.

 '''Expected behavior'''
 True and false would be neutral. Having a visual indicator is fine, but it
 probably shouldn't be red for false. A checkmark for true is pretty
 common, so that should be OK, as should an x for false, which is common as
 well.

--
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/051.ab7c9360dead383f56c97d1ebbee546c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26449: Document that SplitDateTimeWidget requires SplitDateTimeField (was: formfield_overrides doesn't work for models.DateTimeField with SplitDateTimeWidget)

[Django]

#26449: Document that SplitDateTimeWidget requires SplitDateTimeField
--+
 Reporter:  MarysiaLowas  |Owner:  yakky
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.9
 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 timgraham):

 * has_patch:  1 => 0
 * component:  contrib.admin => Documentation


Comment:

 On further reflection, I don't think there's any mention in the
 documentation (I'm looking in `docs/ref/forms/widgets.txt`) that
 `SplitDateTimeWidget` must be used with `SplitDateTimeField`. A note there
 seems like a better course of action rather than repeating requirements of
 the superclass in a subclass's docstring.

--
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.0469522957d8e573300aec2e0f896d20%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #12915: formfield_callback is lost in an inherited ModelForm

[Django]

#12915: formfield_callback is lost in an inherited ModelForm
-+
 Reporter:  semenov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by vzima):

 * cc: vlastimil.zima@… (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/065.ab2b87dd4bac7d7121254a371175615d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26424: Allow URLValidator to skip schemes validation

[Django]

#26424: Allow URLValidator to skip schemes validation
--+
 Reporter:  timgraham |Owner:  burhan
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  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 timgraham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/6388 PR] with some comments for
 improvement.

--
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.712ba863b692c1c75a42a5b7cda9e76b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26456: Document formfield_callback attribute in ModelForm

[Django]

#26456: Document formfield_callback attribute in ModelForm
---+--
 Reporter:  vzima  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * status:  new => closed
 * type:  Uncategorized => New feature
 * resolution:   => wontfix


Comment:

 The attribute is described as an "internal implementation detail" in
 #12915 and the possibility of moving it to `Meta` is discussed. Therefore,
 I don't think it's a good idea to document it as currently implemented.

--
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/063.0188b7c3e8d61f7133b4429a24c632fb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26448: Improve docs for running tests using a different database

[Django]

#26448: Improve docs for running tests using a different database
--+
 Reporter:  aschn |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * easy:  0 => 1
 * 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 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/063.68384663c239423de1c5b3cc8b8f1b96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26456: Document formfield_callback attribute in ModelForm

[Django]

#26456: Document formfield_callback attribute in ModelForm
---+--
 Reporter:  vzima  |Owner:  nobody
 Type:  Uncategorized  |   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:  0  |UI/UX:  0
---+--
Changes (by vzima):

 * needs_docs:   => 0
 * version:  1.9 => master
 * component:  Uncategorized => Documentation
 * needs_tests:   => 0
 * needs_better_patch:   => 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/063.4168a653efcb4842d13d2808932754bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26453: SITE_ID should start from 1, not 0

[Django]

#26453: SITE_ID should start from 1, not 0
-+-
 Reporter:  ynikitenko   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  SITE_ID, sites   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => wontfix
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization


Comment:

 Thanks for the suggestion. This restriction only applies to MySQL,
 however, and I don't think it's a big enough pitfall to warrant a note in
 the docs.

--
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/068.254209b69dc1664d4814401634563c79%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26456: Document formfield_callback attribute in ModelForm

[Django]

#26456: Document formfield_callback attribute in ModelForm
---+
 Reporter:  vzima  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When creating a form from model, the most effective way for modification
 of several fields at once is `formfield_callback`. While it is documented
 argument of `modelform_factory` which is used for dynamically created
 forms, the attribute `formfield_callback` on statically defined
 `ModelForm` remains undocumented. There is growing evidence, that despite
 it isn't documented it is generally used or required, see #17924,
 http://stackoverflow.com/questions/660929/how-do-you-change-the-default-
 widget-for-all-django-date-fields-in-a-modelform,
 http://stackoverflow.com/questions/7342925/django-problem-inheriting-
 formfield-callback-in-modelforms

 I don't require any change of functionality, I just want the following two
 methods to create a model form to be equal:
 {{{
 #!python
 # This works, but it's hard to read on a module level.
 MyModelForm = modelform_factory(MyModel, formfield_callback=my_callback)

 # This does the same thing, but it's not documented.
 class MyModelForm(forms.ModelForm):
 formfield_callback = my_callback

 class Meta:
 model = MyModel
 }}}

--
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/048.0b18844690067e7fc357d9009468b35a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26452: Load middleware on server start rather than on first request (was: Remove lazy initialization of middleware)

[Django]

#26452: Load middleware on server start rather than on first request
--+
 Reporter:  evansd|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  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 timgraham):

 * needs_better_patch:  0 => 1
 * component:  Core (Other) => HTTP handling
 * version:  1.9 => master
 * stage:  Unreviewed => Accepted


Comment:

 Left a few comments for improvement on the
 [https://github.com/django/django/pull/6400 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 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.dc436c9735125f961bf54a6a8d634db4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26450: Docs says label is "Save as" for the button that actually has the label "Save as new"

[Django]

#26450: Docs says label is "Save as" for the button that actually has the label
"Save as new"
-+-
 Reporter:  giuliettamasina  |Owner:
 |  giuliettamasina
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"dd1ab1499077dcf176b01ae466c262d63fe1d34e" dd1ab149]:
 {{{
 #!CommitTicketReference repository=""
 revision="dd1ab1499077dcf176b01ae466c262d63fe1d34e"
 [1.9.x] Fixed #26450 -- Corrected "Save as new" button label in docs.

 Backport of 23aa700b788e073e6efc4585425c0bd6d3092569 from master
 }}}

--
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/073.3fed98d3dcb01a78c10dd940b5f47141%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26450: Docs says label is "Save as" for the button that actually has the label "Save as new"

[Django]

#26450: Docs says label is "Save as" for the button that actually has the label
"Save as new"
-+-
 Reporter:  giuliettamasina  |Owner:
 |  giuliettamasina
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"23aa700b788e073e6efc4585425c0bd6d3092569" 23aa700]:
 {{{
 #!CommitTicketReference repository=""
 revision="23aa700b788e073e6efc4585425c0bd6d3092569"
 Fixed #26450 -- Corrected "Save as new" button label in docs.
 }}}

--
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/073.7dfda4bf5025e409b6b47d45eb1d1b1a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25699: Allow using test client session handling with custom session apps

[Django]

#25699: Allow using test client session handling with custom session apps
-+-
 Reporter:  sergeykolosov|Owner:
 |  sergeykolosov
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"21dd98a38660747c781802afca7ca02407964383" 21dd98a3]:
 {{{
 #!CommitTicketReference repository=""
 revision="21dd98a38660747c781802afca7ca02407964383"
 Fixed #25699 -- Allowed using the test client if 'django.contrib.sessions'
 isn't in INSTALLED_APPS.
 }}}

--
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.35c7d484592c0c1af6132095a326201b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
-+-
 Reporter:  jonasborgstrom   |Owner:  tltx
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"5faf745999caa3d2588979ae1262cc28652c21a5" 5faf745]:
 {{{
 #!CommitTicketReference repository=""
 revision="5faf745999caa3d2588979ae1262cc28652c21a5"
 Refs #21608 -- Fixed incorrect cache key in cache session backend's
 save().

 The bug was introduced commit 3389c5ea229884a1943873fe7e7ffc2800cefc22.
 }}}

--
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/072.015608decf4a824026f26df0f0c8cc83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26455: Add lookups and database functions to check for valid geometries and repairing them.

[Django]

#26455: Add lookups and database functions to check for valid geometries and
repairing them.
-+-
 Reporter:  yellowcap|Owner:  yellowcap
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  isvalid, makevalid,  | Triage Stage:
  valid, geometry|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yellowcap):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Here is the pr: https://github.com/django/django/pull/6412

 I tried to find equivalent functions in the other spatial backends, the
 only function I found was `SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT`. The
 result of this function is an error code for invalid geometries.
 Unfortunately I am not familiar with oracle so I dont know how to use this
 properly.

 https://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_objgeom.htm#BGHFDDBF

--
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.f5afc0982a8fbb819d65cda49e51062a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26454: Direct Link to supported Version Table

[Django]

#26454: Direct Link to supported Version Table
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 You can use https://www.djangoproject.com/download/#supported-versions.

 By the way, the ticket tracker for the website is
 https://github.com/django/djangoproject.com/issues.

--
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.0b0e2a55ffa08755162a61f1b6c738bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26455: Add lookups and database functions to check for valid geometries and repairing them.

[Django]

#26455: Add lookups and database functions to check for valid geometries and
repairing them.
-+-
 Reporter:   |  Owner:  yellowcap
  yellowcap  |
 Type:  New  | Status:  new
  feature|
Component:  GIS  |Version:  1.9
 Severity:  Normal   |   Keywords:  isvalid, makevalid, valid, geometry
 Triage Stage:   |  Has patch:  1
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 There are many data sources that come with geometries that are not valid,
 and clipping or intersecting functions may lead to invalid geometries
 sometimes. At the same time, geographic operations often require valid
 input.

 The python geometries in GeoDjango have a ``valid`` property, but the same
 property is not available during database queries.

 To avoid errors during geoprocessing on large datasets the database side,
 it can be essential to be able to filter valid geometries and possibly
 repair them as well.

--
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.411843b90f49a0599f49f907ecc2ca87%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26201: Document the consequences of rotating the CSRF token on login

[Django]

#26201: Document the consequences of rotating the CSRF token on login
--+
 Reporter:  wimfeijen |Owner:  vehrlich
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.8
 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 timgraham):

 [https://github.com/django/django/pull/6391 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 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.1e8825676ddf50ad91973efa30a624ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26403: "Invalid block tag" message is English except for one word

[Django]

#26403: "Invalid block tag" message is English except for one word
--+
 Reporter:  interDist |Owner:  amureki
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Template system   |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  1
--+
Changes (by timgraham):

 * stage:  Ready for checkin => 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 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.c5dda34fc9b795d159c209df2739c7ad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26434: Inconsistent results of QuerySet count() method using PostgreSQL backend prior and post the QuerySet evaluation

[Django]

#26434: Inconsistent results of QuerySet count() method using PostgreSQL backend
prior and post the QuerySet evaluation
-+-
 Reporter:  kamandol |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql queryset  | Triage Stage:
  count annotate aggreagate  |  Unreviewed
  order_by   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kamandol):

 Updated test comments and clearer test names

--
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.4c9bf6958ddc4deaa5c1d1bb962acd56%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26434: Inconsistent results of QuerySet count() method using PostgreSQL backend prior and post the QuerySet evaluation

[Django]

#26434: Inconsistent results of QuerySet count() method using PostgreSQL backend
prior and post the QuerySet evaluation
-+-
 Reporter:  kamandol |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql queryset  | Triage Stage:
  count annotate aggreagate  |  Unreviewed
  order_by   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kamandol):

 Replying to [comment:3 yakky]:
 > Tests looks legitimate, but I don't get this one https://github.com/sp-
 ricard-valverde/django/commit/c50afafdb02880e4c941c2a72a215bee80de3aed
 #diff-ce9b52a66d03e851a9828377263dc04bR3864 ; or rather I don't get why is
 labeled  as 'OK' as it the concatenation of the previous ones

 Sorry, my bad, it's a bad choice for a test title. What it demonstrates is
 that the second assert in that test is '''successful''' even though a new
 QuerySet is built and, according to the other failed tests it should fail
 too.

--
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.9e1d82a5a4857af42883075d215784f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17741: QuerySet.query.__str__() does not generate valid MySQL query with dates

[Django]

#17741: QuerySet.query.__str__() does not generate valid MySQL query with dates
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by zachborboa):

 If you need the correct parameter substitution, use `EXPLAIN`. Then remove
 the first 8 chars.

 {{{#!python
 In [1]: import datetime

 In [2]: from django.db import connection

 In [3]: from myapp.models import Entry

 In [4]: today_entry_list =
 Entry.objects.filter(post_date=datetime.date.today())

 In [5]: sql, params = today_entry_list.query.sql_with_params()

 In [6]: cursor = connection.cursor()

 In [7]: cursor.execute('EXPLAIN ' + sql, params)
 Out[7]: 1L

 In [8]: print(cursor.db.ops.last_executed_query(cursor, sql, params))
 EXPLAIN SELECT `myapp_entry`.`id`, `myapp_entry`.`title`,
 `myapp_entry`.`slug`, `myapp_entry`.`body`, `myapp_entry`.`post_date` FROM
 `myapp_entry` WHERE `myapp_entry`.`post_date` = '2016-04-04'
 }}}

--
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.3e222b71ec2b7dad0d2f50a34a232e4a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26403: "Invalid block tag" message is English except for one word

[Django]

#26403: "Invalid block tag" message is English except for one word
-+-
 Reporter:  interDist|Owner:  amureki
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by amureki):

 Replying to [comment:6 susan]:
 > What is the github pull request link?

 It is displayed in top menu on "Pull requests" part.

 Here is fast link: https://github.com/django/django/pull/6386

 P.S. I'll update it with tests as needed.

--
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.e608e546fcb138dadd475dcdac4bef93%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.