Re: [Django] #32735: DateFormat.Y() is not zero-padded.

[Django]

#32735: DateFormat.Y() is not zero-padded.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  date, year, 1000,| Triage Stage:  Accepted
  padding|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"34363a391bad5a007f2ab35a6d8c4ece4c3234f6" 34363a39]:
 {{{
 #!CommitTicketReference repository=""
 revision="34363a391bad5a007f2ab35a6d8c4ece4c3234f6"
 Fixed #32735 -- Made DateFormat.Y() return a zero-padded year.
 }}}

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

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

Re: [Django] #32740: Running colorama.init() at import time causes deployment error

[Django]

#32740: Running colorama.init() at import time causes deployment error
-+--
 Reporter:  Leon Matthews|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Other) |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  apache mod_wsgi  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Carlton Gibson):

 I've opened [https://github.com/GrahamDumpleton/mod_wsgi/issues/675 an
 issue on `mod_wsgi`] to see what Graham's thoughts are there.

 Even if we were to nest the call to `colorama.init()`, the same path would
 be hit, just later, and there'd still be a compatibility issue with
 `mod_wsgi`.

 (I don't think that requiring the logging config to avoid the call is
 particularly robust...)

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

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

Re: [Django] #32741: Tutorial Part 2 throws models.W042 warnings when making migrations

[Django]

#32741: Tutorial Part 2 throws models.W042 warnings when making migrations
-+-
 Reporter:  Katie McLaughlin |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Katie McLaughlin):

 Ah, I see what I did wrong. I had a global Django installed so `django-
 admin` was referencing the global 3.1.7 version instead of the 3.2.2 local
 version. Fixing that generated the right template project for me, showing
 the setting you see.

 Sorry for the noise!

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

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

Re: [Django] #32740: Running colorama.init() at import time causes deployment error

[Django]

#32740: Running colorama.init() at import time causes deployment error
-+--
 Reporter:  Leon Matthews|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Other) |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  apache mod_wsgi  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

 * cc: MinchinWeb (added)


Comment:

 Hello again. I'm supposing we should fix this, but I'm a little intrigued
 by the last line of that traceback:


 {{{
   File "/srv/websites/digitaladvisor.nz/env/lib/python3.8/site-
 packages/colorama/ansitowin32.py", line 59, in closed
 26  return stream.closed
 }}}

 The docs you link have this for justification:

 > A well behaved Python WSGI application should never attempt to write any
 data directly to sys.stdout or use the print statement without directing
 it to an alternate file object.

 But [https://docs.python.org/3.9/library/io.html#io.IOBase.closed `closed`
 is just checking the status of the stream]. It's not writing data, so
 shouldn't trigger an error. To that extent it kind of looks like a bug in
 `mod_wsgi`. 🤔

 > could it please be moved into a function instead?

 An earlier iteration of the PR did have this call nested inside a
 function.

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

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

Re: [Django] #32741: Tutorial Part 2 throws models.W042 warnings when making migrations

[Django]

#32741: Tutorial Part 2 throws models.W042 warnings when making migrations
-+-
 Reporter:  Katie McLaughlin |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:
 |  worksforme
 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 Mariusz Felisiak):

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


Comment:

 I cannot reproduce this issue, generated `settings.py` contains
 `DEFAULT_AUTO_FIELD`:
 {{{
 # Default primary key field type
 # https://docs.djangoproject.com/en/3.2/ref/settings/#default-auto-field

 DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'
 }}}
 it's also defined in `polls/apps.py`:
 {{{
 class PollsConfig(AppConfig):
 default_auto_field = 'django.db.models.BigAutoField'
 name = 'polls'
 }}}

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

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

Re: [Django] #31973: TypeError loading data in JSONField if DB has native JSON support

[Django]

#31973: TypeError loading data in JSONField if DB has native JSON support
-+-
 Reporter:  Adam Alton   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (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 Mariusz Felisiak):

 Garry, using `json` data type was never supported, see #32135.

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

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

Re: [Django] #32734: django-admin startapp with trailing slash in directory name results in error

[Django]

#32734: django-admin startapp with trailing slash in directory name results in
error
---+--
 Reporter:  jooadam|Owner:  Rohith P R
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * owner:  jooadam => Rohith P 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.7eb047cfd16cbc8aa12b3816f39c3e3c%40djangoproject.com.

Re: [Django] #32741: Tutorial Part 2 throws models.W042 warnings when making migrations

[Django]

#32741: Tutorial Part 2 throws models.W042 warnings when making migrations
-+-
 Reporter:  Katie McLaughlin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Katie McLaughlin):

 There are two ways that this could be solved:

 * Adjusting the template `settings.py` to add `DEFAULT_AUTO_FIELD =
 'django.db.models.AutoField'`
 * Adjusting the tutorial models to include `id =
 models.AutoField(primary_key=True)` for each model.

 I want to say the tutorial model update is better because it means not
 touching the template project, but I'm also not sure how important this
 default is with respect to having the default at start for new projects.

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

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

[Django] #32741: Tutorial Part 2 throws models.W042 warnings when making migrations

[Django]

#32741: Tutorial Part 2 throws models.W042 warnings when making migrations
+
   Reporter:  Katie McLaughlin  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  3.2
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 Changes in Django 2.2 mean that the auto-created primary key changes
 (https://docs.djangoproject.com/en/3.2/releases/3.2/#customizing-type-of-
 auto-created-primary-keys) throw the associated warnings, as the Tutorial
 Part 2 doesn't adjust for these.

 Reproduction:

  * in a new virtualenv, `pip install django==3.2.2`
  * generate a new template project `django-admin startproject mysite .`
* confirm the generated `settings.py` doesn't mention
 DEFAULT_AUTO_FIELD
  * run though the tutorial, up to and including
 https://docs.djangoproject.com/en/3.2/intro/tutorial02/#creating-models
  * attempt to `python manage.py makemigrations polls`
  * get errors

 {{{
 System check identified some issues:

 WARNINGS:
 polls.Choice: (models.W042) Auto-created primary key used when not
 defining a primary key type, by default 'django.db.models.AutoField'.
 HINT: Configure the DEFAULT_AUTO_FIELD setting or the
 PollsConfig.default_auto_field attribute to point to a subclass of
 AutoField, e.g. 'django.db.models.BigAutoField'.
 polls.Question: (models.W042) Auto-created primary key used when not
 defining a primary key type, by default 'django.db.models.AutoField'.
 HINT: Configure the DEFAULT_AUTO_FIELD setting or the
 PollsConfig.default_auto_field attribute to point to a subclass of
 AutoField, e.g. 'django.db.models.BigAutoField'.
 Migrations for 'polls':
   polls/migrations/0001_initial.py
 - Create model Question
 - Create model Choice
 }}}

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

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

Re: [Django] #32740: Running colorama.init() at import time causes deployment error

[Django]

#32740: Running colorama.init() at import time causes deployment error
-+--
 Reporter:  Leon Matthews|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Other) |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  apache mod_wsgi  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Leon Matthews):

 * Attachment "django-ticket-32740.txt" added.

 Traceback from server

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

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

[Django] #32740: Running colorama.init() at import time causes deployment error

[Django]

#32740: Running colorama.init() at import time causes deployment error
-+-
   Reporter:  Leon Matthews  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Core (Other)   |Version:  3.2
   Severity:  Normal |   Keywords:  apache mod_wsgi
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 [https://code.djangoproject.com/ticket/31216 Ticket 31216] added terminal
 colour output on Windows. Unfortunately, there is a small problem with it
 that causes deployments to fail under Linux/Apache/mod_wsgi, leaving me
 stuck on Django 3.1.

 I've tracked it down to line 16 of
 
[https://github.com/django/django/blob/b1a4b1f0bdf05adbd3dc4dde14228e68da54c1a3/django/core/management/color.py#L16
 django/code/management/color.py]. There, the function `colorama.init()` is
 being called, and being called at import time (with caveats, see below).
 My deployment setup uses Apache ''mod_wsgi'' with the setting
 ''WSGIRestrictStdout on'' (its recommended default). During import of the
 logging system `colorama.init()` accesses `sys.stdout` which is
 [https://modwsgi.readthedocs.io/en/master/configuration-
 directives/WSGIRestrictStdout.html prohibited by this setting] causing a
 dreaded 500 error.

 Running code during import is [https://www.benkuhn.net/importtime/ best
 avoided if possible]. I understand that `colorama.init()` must be called
 at some point, but could it please be moved into a function instead?
 Would the function `colour_style()` in the same module be suitable? Doing
 so would make it possible for me use my logging configuration to avoid the
 function call.

 Some notes:

 * My (production) logging configuration doesn't use colour, but the import
 chain forces a run of `colorama.init()` anyway.
 * A work-around would be simply not install colorama, as `init()` is only
 called it's import succeeds. Unfortunately, colorama is being installed
 into my project's virtualenv by a 3rd-party dependency, and I don't want
 to drop that package. Also, I use colorama in the custom management
 commands of a couple of my projects.
 * I apologise for not testing my deployments during the 3.2 beta. I'm
 kicking myself, because I did test upgrades of my main projects for the
 beta and release candidates. I fixed all the deprecation warnings and made
 sure my test suite passed - but I didn't try a test deployment. I fell
 prey to the classic ''it works on my computer'' blunder!

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

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

Re: [Django] #31216: Support terminal color output on Windows via colorama

[Django]

#31216: Support terminal color output on Windows via colorama
-+-
 Reporter:  MinchinWeb   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  windows, color,  | Triage Stage:  Accepted
  colorama   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Leon Matthews):

 > Hey Leon... Pending a follow-up ticket, `colorama` is to provide syntax
 colouring on Windows. The simplest thing here as an immediate workaround
 is to not install it on Ubuntu (or uninstall it since it's already there).

 Thank you for the suggestion. That had occurred to me as well.  As it
 happens, it's being installed into the project virtual environment not
 directly, but as a dependency pulled in from some other package. It's
 morning in my timezone now (warm greetings from New Zealand!), so I'm
 raising a new ticket (sorry for going the wrong way) to help get it fixed
 properly.

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

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

Re: [Django] #32727: Support spaces separaters in ISO-8601 datetimes between times and timezone strings

[Django]

#32727: Support spaces separaters in ISO-8601 datetimes between times and 
timezone
strings
+
 Reporter:  Ben Wilber  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  Version:  dev
 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 Ben Wilber):

 Replying to [comment:12 Claude Paroz]:

 Yes I'll start a thread on django devs.  Thanks!

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

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

Re: [Django] #32734: django-admin startapp with trailing slash in directory name results in error

[Django]

#32734: django-admin startapp with trailing slash in directory name results in
error
---+
 Reporter:  jooadam|Owner:  jooadam
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by jooadam):

 Replying to [comment:5 Rohith P R]:
 > Hey @jooadam! I already had a
 [PR](https://github.com/django/django/pull/14382) open to fix this issue.
 I left a comment on your PR btw. :)

 Yeah, I saw it after the fact :/

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

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

Re: [Django] #32734: django-admin startapp with trailing slash in directory name results in error

[Django]

#32734: django-admin startapp with trailing slash in directory name results in
error
---+
 Reporter:  jooadam|Owner:  jooadam
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Rohith P R):

 Hey @jooadam! I already had a
 [PR](https://github.com/django/django/pull/14382) open to fix this issue.
 I left a comment on your PR btw. :)

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

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

Re: [Django] #32734: django-admin startapp with trailing slash in directory name results in error

[Django]

#32734: django-admin startapp with trailing slash in directory name results in
error
---+
 Reporter:  jooadam|Owner:  jooadam
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by jooadam):

 * owner:  Rohith P R => jooadam


Comment:

 Replying to [comment:3 Rohith P R]:

 Rohith, sorry for not assigning it to me first, I just submitted a pull
 request: https://github.com/django/django/pull/14383

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

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

Re: [Django] #32734: django-admin startapp with trailing slash in directory name results in error

[Django]

#32734: django-admin startapp with trailing slash in directory name results in
error
---+--
 Reporter:  jooadam|Owner:  Rohith P R
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Rohith P R):

 * owner:  nobody => Rohith P R
 * status:  new => assigned


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

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

Re: [Django] #32717: Incorrect SQL generation filtering OR-combined queries

[Django]

#32717: Incorrect SQL generation filtering OR-combined queries
-+-
 Reporter:  Shaheed Haque|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 To answer your initial question though your query would likely be more
 easily expressed using `Q`

 {{{#!python
 def jurisdiction_qs(for_jurisdiction):
 filter_ = Q(jurisdiction=for_jurisdiction)
 if for_jurisdiction != 'Universal':
 filter_ |= Q(jurisdiction='Universal') & ~Q(
 name__in=Buss.objects.filter(filter_).values_list('name',
 flat=True)
 )
 if for_jurisdiction != 'Company':
filter_ |= Q(jurisdiction='Company') & ~Q(
 name__in=Buss.objects.filter(filter_).values_list('name',
 flat=True)
 )
 return Buss.objects.filter(filter_)
 }}}

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

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

Re: [Django] #32717: Incorrect SQL generation filtering OR-combined queries

[Django]

#32717: Incorrect SQL generation filtering OR-combined queries
-+-
 Reporter:  Shaheed Haque|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > I'm not qualified to speak to most of this, but I'm wanted to check if
 "we should prevent Query.combine from ever generating queries with root
 Where(connector='OR')" means that the original OR'd query I wrote would
 not be supported?

 You queries would still be supported, it's more of how internal data
 structures are used under the hood. Basically doing a ` |
 ` is the only circumstances in the ORM where the returned
 `QuerySet.query`, which is an instance of `sql.Query`, will have a
 `.where` property, which is an instance of `sql.where.Where`, with a
 `.connector == 'OR'` instead of `AND`. What I'm proposing we do here is
 that instead of having `query.where.connector` be of the `(connector='OR',
 nodes=[jurisdiction = 'GB', ...])` form we ensure that it's always nested
 in a top-level `AND` instead so `(connector='AND', nodes=[(connector='OR',
 nodes=[jurisdiction = 'GB', ...])])`.

 Not totally necessary as the above patch that adjusts the ''optimization''
 should address the issue, it'd be great if you could confirm it does, but
 it does make the behaviour of `Query.combine` more in line with the
 heavily tested paths the ORM usually takes.

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

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

Re: [Django] #32717: Incorrect SQL generation filtering OR-combined queries

[Django]

#32717: Incorrect SQL generation filtering OR-combined queries
-+-
 Reporter:  Shaheed Haque|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Shaheed Haque):

 Hi,

 I'm not qualified to speak to most of this, but I'm wanted to check if "we
 should prevent Query.combine from ever generating queries with root
 Where(connector='OR')" means that the original OR'd query I wrote would
 not be supported?

 If so, then how else could one write the query? (As I said, I don't see
 how Q() can be used with .exclude()...but I might have missed something).

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

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

Re: [Django] #32731: makemigrations reports "No changes detected" if a property exists with the same field name

[Django]

#32731: makemigrations reports "No changes detected" if a property exists with 
the
same field name
---+--
 Reporter:  Jej|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords:  annoying   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Jej):

 Ok. Thanks for the explanation of the underlaying.

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

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

Re: [Django] #32733: DEFAULT_AUTO_FIELD feature leads `AbstractModel.check()` to fail with AttributeError

[Django]

#32733: DEFAULT_AUTO_FIELD feature leads `AbstractModel.check()` to fail with
AttributeError
-+-
 Reporter:  amureki  |Owner:  amureki
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Johannes Maron):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #32366: Update usage of now() & co

[Django]

#32366: Update usage of now() & co
-+-
 Reporter:  Carlton Gibson   |Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Utilities|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #32737: get_language_info replaces requested language code with the one found in django.conf.locale.LANG_INFO

[Django]

#32737: get_language_info replaces requested language code with the one found in
django.conf.locale.LANG_INFO
-+-
 Reporter:  ruffni   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:   |  Version:  dev
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n,| Triage Stage:  Accepted
  get_language_info, language code,  |
  LANG_INFO, documentation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * status:  closed => new
 * type:  Bug => Cleanup/optimization
 * version:  3.1 => dev
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 Thanks a lot for the sample project. I'm reopening at least for the
 missing documentation which should tell that `get_language_info` and
 `get_language_info_list` only return information for languages included in
 Django.

 In your specific use case, I would simply rewrite your language selector
 as:
 {{{
 
 {% get_current_language as LANGUAGE_CODE %}
 {% get_available_languages as LANGUAGES %}
 {% for code,lang_name in LANGUAGES %}
 
 {{ lang_name }} ({{code}})
 {% endfor %}
 
 }}}

 If we wanted custom languages data entering Django's `LANG_INFO`, it would
 require some deeper refactoring with language data embedded somewhere
 inside the locale folders (maybe in `__init__.py`?). Don't know if it's
 really worth the effort…

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

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

Re: [Django] #32734: django-admin startapp with trailing slash in directory name results in error

[Django]

#32734: django-admin startapp with trailing slash in directory name results in
error
---+
 Reporter:  jooadam|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Rohith P R):

 > I didn't look into exactly why but it works for startproject



 This is the relevant piece of code- should this same check be performed
 for start project as well?

 {{{
 if app_or_project == 'app':
 self.validate_name(os.path.basename(target), 'directory')
 }}}

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

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

Re: [Django] #32737: get_language_info replaces requested language code with the one found in django.conf.locale.LANG_INFO

[Django]

#32737: get_language_info replaces requested language code with the one found in
django.conf.locale.LANG_INFO
-+-
 Reporter:  ruffni   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  i18n,| Triage Stage:
  get_language_info, language code,  |  Unreviewed
  LANG_INFO, documentation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ruffni):

 Replying to [comment:3 Claude Paroz]:
 > Would be great to have a sample project to reproduce the issue.

 added the sample project. it's the same issue with django 3.2 (not sure
 whether to change the version description of this ticket or not)

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

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

Re: [Django] #32737: get_language_info replaces requested language code with the one found in django.conf.locale.LANG_INFO

[Django]

#32737: get_language_info replaces requested language code with the one found in
django.conf.locale.LANG_INFO
-+-
 Reporter:  ruffni   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  i18n,| Triage Stage:
  get_language_info, language code,  |  Unreviewed
  LANG_INFO, documentation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ruffni):

 * Attachment "translations.zip" added.

 example project

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

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

Re: [Django] #32737: get_language_info replaces requested language code with the one found in django.conf.locale.LANG_INFO

[Django]

#32737: get_language_info replaces requested language code with the one found in
django.conf.locale.LANG_INFO
-+-
 Reporter:  ruffni   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  i18n,| Triage Stage:
  get_language_info, language code,  |  Unreviewed
  LANG_INFO, documentation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Would be great to have a sample project to reproduce the 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.9b6ffd3cf64eb7550aafbafbb72c3eea%40djangoproject.com.

Re: [Django] #32737: get_language_info replaces requested language code with the one found in django.conf.locale.LANG_INFO

[Django]

#32737: get_language_info replaces requested language code with the one found in
django.conf.locale.LANG_INFO
-+-
 Reporter:  ruffni   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  i18n,| Triage Stage:
  get_language_info, language code,  |  Unreviewed
  LANG_INFO, documentation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ruffni):

 aha! i see what i missed to say before:

 Replying to [comment:1 Claude Paroz]:
 > If you really want it, you could add any "new" language by following
 https://docs.djangoproject.com/en/stable/topics/i18n/translation
 /#localization-how-to-create-language-files
 this is exactly what i did!

 i added the locale directory, made the messages (for language codes 'de-
 ch' and 'fr-ch' respectively), compiled them (it all works great). but
 still: comparing LANGUAGE_CODE to get_language_info('de-ch') **always
 fails**, see above.
 nota bene: i'm not talking about some generic translations or anything
 alike, i'm talking about translations for languages we provide explicitly


 > I'm closing the ticket, but this does not mean we cannot continue the
 discussion, if needed.
 i have some doubt about this being intended behavior.

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

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

Re: [Django] #32739: Enable timezone handling by default (USE_TZ=True in global settings)

[Django]

#32739: Enable timezone handling by default (USE_TZ=True in global settings)
--+
 Reporter:  Claude Paroz  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Claude Paroz):

 We might even think of *always* activating timezones (middle-term goal?),
 but I don't have in mind all possible consequences of such a move.

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

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

Re: [Django] #32739: Enable timezone handling by default (USE_TZ=True in global settings)

[Django]

#32739: Enable timezone handling by default (USE_TZ=True in global settings)
--+
 Reporter:  Claude Paroz  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK, yes — 10 years should be long enough 😀 +1.

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

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

Re: [Django] #32738: Deprecate django.utils.datetime_safe, use alternate method to ensure four-digit year with strftime.

[Django]

#32738: Deprecate django.utils.datetime_safe, use alternate method to ensure 
four-
digit year with strftime.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  datetime_safe,   | Triage Stage:  Accepted
  datetime   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK, I like this: the single documented function is clearer for me that the
 subclass approach.

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

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

[Django] #32739: Enable timezone handling by default (USE_TZ=True in global settings)

[Django]

#32739: Enable timezone handling by default (USE_TZ=True in global settings)
+
   Reporter:  Claude Paroz  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 As using timezones is a recommended good practice by
 [https://docs.djangoproject.com/en/2.2/topics/i18n/timezones/#overview the
 docs], I think we should set `USE_TZ=True` in `global_settings.py`.

 This will also allow to remove a setting from the default project settings
 template.

 To achieve that, we'll have to add a warning during the deprecation period
 when we detect USE_TZ is not overridden in project settings.

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

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

Re: [Django] #32734: django-admin startapp with trailing slash in directory name results in error

[Django]

#32734: django-admin startapp with trailing slash in directory name results in
error
---+
 Reporter:  jooadam|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK, yes, this seems a case we could handle.

 I didn't look into exactly why but it works for `startproject`:

 {{{
 $ django-admin startproject ticket32734 testing/
 }}}

 Thanks for the report. Do you fancy making a PR?

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

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

Re: [Django] #32722: Comparing to TruncTime() doesn't work on Oracle.

[Django]

#32722: Comparing to TruncTime() doesn't work on Oracle.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle ttrunctime| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"b1a4b1f0bdf05adbd3dc4dde14228e68da54c1a3" b1a4b1f]:
 {{{
 #!CommitTicketReference repository=""
 revision="b1a4b1f0bdf05adbd3dc4dde14228e68da54c1a3"
 Fixed #32722 -- Fixed comparing to TruncTime() on Oracle.
 }}}

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

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

Re: [Django] #32722: Comparing to TruncTime() doesn't work on Oracle.

[Django]

#32722: Comparing to TruncTime() doesn't work on Oracle.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle ttrunctime| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Ready for checkin


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

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