Re: [Django] #20935: ePub documentation not valid

[Django]

#20935: ePub documentation not valid
---+
 Reporter:  mabdullah  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Katie McLaughlin):

 readthedocs.org urls have moved since this ticket was filed, new URL:
 https://readthedocs.org/projects/django/downloads/

 Tested the downloads for latest, stable, 2.2.x and 3.0x

 They appear to load in ebook reviews (calibre, apple books)

 The validator http://validator.idpf.org/ does still return errors, but
 they aren't breaking errors (from what I can tell):

 6 x `toc.ncx` -  `Error while parsing file: different playOrder values for
 navPoint/navTarget/pageTarget that refer to same target`
 72 x `*.svg` - `External entities are not allowed in EPUB v3 documents.`
 2639 x `*.xhtml` - `Fragment identifier is not defined.`

 Two minor svg errors that might be important:


 _images/django_unittest_classes_hierarchy.svg - Error while parsing file:
 element "dc:date" not allowed anywhere; expected the element end-tag or
 text
 _images/triage_process.svg` `Error while parsing file: element "dc:date"
 not allowed anywhere; expected the element end-tag or text


 Vote to close

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

Re: [Django] #30775: Tutorial part 5 testing often encounters import errors

[Django]

#30775: Tutorial part 5 testing often encounters import errors
-+-
 Reporter:  Katie McLaughlin |Owner:  Katie
 Type:   |  McLaughlin
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Katie McLaughlin):

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

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

[Django] #30775: Tutorial part 5 testing often encounters import errors

[Django]

#30775: Tutorial part 5 testing often encounters import errors
-+-
   Reporter:  Katie  |  Owner:  Katie McLaughlin
  McLaughlin |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  2.2
  Documentation  |
   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  |
-+-
 As reported via the contact form (thanks Tom R.!), people completing the
 tutorial often get stuck in Part 5 when running their first tests

 https://stackoverflow.com/questions/14719883/django-can-not-get-a-time-
 function-timezone-datetime-to-work-properly-gett

 The issue is that there is an import line hiding in Part 2 "Playing with
 the API" where imports are added to the polls/models.py that are often
 missed, generating a different error when running the tests than what is
 expected by that part of the tutorial.

 I already have a patch for 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.2afae99708699eafef45b95cd0596691%40djangoproject.com.

Re: [Django] #30773: Support Algorithm parameter on MySQL migrations.

[Django]

#30773: Support Algorithm parameter on MySQL migrations.
-+--
 Reporter:  mklauber |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mysql| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Simon Charette):

 MySQL will use the best algorithm available by default if possible
 (`INPLACE` or `INSTANT`) so this option will only make the operation crash
 if the specified algorithm is not available. Given MySQL doesn't support
 transactional DDL this has the potential to cause more harm than good IMO.

 I guess we could add support for `algorithm` to MySQL schema editor but as
 I mentioned above MySQL already picks the ''best'' algorithm it can and I
 can't see a reason for using `COPY` or `INPLACE` when `INSTANT` is
 supported.

 Finally given we added `AddIndexConcurrently` to `contrib.postgres` this
 would probably belong in `django-mysql`.

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

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

Re: [Django] #30774: Migrations uses value of enum object instead of its name. (was: Migrations uses value of enum object instead of its name)

[Django]

#30774: Migrations uses value of enum object instead of its name.
--+--
 Reporter:  oasl  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:  Enum, Migrations  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => needsinfo


Comment:

 Thanks for this report, however I'm not sure how translated values can
 brake migrations. Can you provide a sample project to reproduce this
 issue? Migrations with translatable strings works fine for me:
 {{{
 >>> class TextEnum(enum.Enum):
 ... C = _('translatable value')
 ...
 >>> TextEnum(_('translatable value'))
 
 >>> TextEnum('translatable value')
 
 }}}

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

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

Re: [Django] #30774: Migrations uses value of enum object instead of its name

[Django]

#30774: Migrations uses value of enum object instead of its name
--+--
 Reporter:  oasl  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.2
 Severity:  Normal|   Resolution:
 Keywords:  Enum, Migrations  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by oasl:

Old description:

> When using Enum object as a default value for a CharField, the generated
> migration file uses the value of the Enum object instead of the its name.
> This causes a problem when using Django translation on the value of the
> Enum object.
>
> The problem is that, when the Enum object value get translated to the
> users language, the migrations raise an error stating that the Enum does
> not have the corresponding value. (because the Enum value is translated
> to another language)
>
> Example:
>
> Let say we have this code in models.py:
> {{{
> from enum import Enum
> from django.utils.translation import gettext_lazy as _
> from django.db import models
>

> class Status(Enum):
> GOOD = _('Good') # 'Good' will be translated
> BAD = _('Bad') # 'Bad' will be translated
>
> def __str__(self):
> return self.name
>
> class Item(models.Model):
> status = models.CharField(default=Status.GOOD, max_length=128)
> }}}
>
> In the generated migration file, the code will be:
> {{{
> ...
> ('status', models.CharField(default=Status('Good'), max_length=128))
> ...
> }}}
> After the translation, 'Good' will be translated to another word and it
> will not be part of the Status Enum class any more, so the migration file
> will raise the error on the previous line:
>
> {{{ValueError: 'Good' is not a valid Status}}}
>
> Shouldn't the code generated by the migration uses the name of the Status
> Enum 'GOOD', not the value of it, since it is changeable?
>
> It should be:
> {{{
> ('status', models.CharField(default=Status['GOOD'], max_length=128))
> }}}
> This will be correct regardless of the translated word

New description:

 When using Enum object as a default value for a CharField, the generated
 migration file uses the value of the Enum object instead of the its name.
 This causes a problem when using Django translation on the value of the
 Enum object.

 The problem is that, when the Enum object value get translated to the
 users language, the old migration files raise an error stating that the
 Enum does not have the corresponding value. (because the Enum value is
 translated to another language)

 Example:

 Let say we have this code in models.py:
 {{{
 from enum import Enum
 from django.utils.translation import gettext_lazy as _
 from django.db import models


 class Status(Enum):
 GOOD = _('Good') # 'Good' will be translated
 BAD = _('Bad') # 'Bad' will be translated

 def __str__(self):
 return self.name

 class Item(models.Model):
 status = models.CharField(default=Status.GOOD, max_length=128)
 }}}

 In the generated migration file, the code will be:
 {{{
 ...
 ('status', models.CharField(default=Status('Good'), max_length=128))
 ...
 }}}
 After the translation, 'Good' will be translated to another word and it
 will not be part of the Status Enum class any more, so the migration file
 will raise the error on the previous line:

 {{{ValueError: 'Good' is not a valid Status}}}

 Shouldn't the code generated by the migration uses the name of the Status
 Enum 'GOOD', not the value of it, since it is changeable?

 It should be:
 {{{
 ('status', models.CharField(default=Status['GOOD'], max_length=128))
 }}}
 This will be correct regardless of the translated word

--

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

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

[Django] #30774: Migrations uses value of enum object instead of its name

[Django]

#30774: Migrations uses value of enum object instead of its name
--+--
   Reporter:  oasl|  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  2.2
   Severity:  Normal  |   Keywords:  Enum, Migrations
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
 When using Enum object as a default value for a CharField, the generated
 migration file uses the value of the Enum object instead of the its name.
 This causes a problem when using Django translation on the value of the
 Enum object.

 The problem is that, when the Enum object value get translated to the
 users language, the migrations raise an error stating that the Enum does
 not have the corresponding value. (because the Enum value is translated to
 another language)

 Example:

 Let say we have this code in models.py:
 {{{
 from enum import Enum
 from django.utils.translation import gettext_lazy as _
 from django.db import models


 class Status(Enum):
 GOOD = _('Good') # 'Good' will be translated
 BAD = _('Bad') # 'Bad' will be translated

 def __str__(self):
 return self.name

 class Item(models.Model):
 status = models.CharField(default=Status.GOOD, max_length=128)
 }}}

 In the generated migration file, the code will be:
 {{{
 ...
 ('status', models.CharField(default=Status('Good'), max_length=128))
 ...
 }}}
 After the translation, 'Good' will be translated to another word and it
 will not be part of the Status Enum class any more, so the migration file
 will raise the error on the previous line:

 {{{ValueError: 'Good' is not a valid Status}}}

 Shouldn't the code generated by the migration uses the name of the Status
 Enum 'GOOD', not the value of it, since it is changeable?

 It should be:
 {{{
 ('status', models.CharField(default=Status['GOOD'], max_length=128))
 }}}
 This will be correct regardless of the translated word

-- 
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/047.60970071993aff87d7b3a760784d88ef%40djangoproject.com.

Re: [Django] #26630: Defered constraint checks flush after `post_delete` signal

[Django]

#26630: Defered constraint checks flush after `post_delete` signal
-+-
 Reporter:  Alex Madjar  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.649ce92fa40df10a73e5e10a3ae3c152%40djangoproject.com.

[Django] #30773: Support Algorithm parameter on MySQL migrations.

[Django]

#30773: Support Algorithm parameter on MySQL migrations.
---+
   Reporter:  mklauber |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Migrations   |Version:  master
   Severity:  Normal   |   Keywords:  mysql
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 See: https://mysqlserverteam.com/mysql-8-0-innodb-now-supports-instant-
 add-column/

 Mysql now supports (as of 8.0) a new ALGORITHM = INSTANT, that prevents
 long running DDL statements.  It would be useful to be able to define this
 on migrations, to prevent table locking, without having to manually write
 every migration.  Perhaps as an option on the database in the DATABASES
 setting dict?

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

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

Re: [Django] #26630: Defered constraint checks flush after `post_delete` signal

[Django]

#26630: Defered constraint checks flush after `post_delete` signal
-+-
 Reporter:  Alex Madjar  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * owner:  nobody => Can Sarıgöl
 * status:  new => assigned
 * version:  1.9 => master


Comment:

 [https://github.com/django/django/pull/11780 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/068.72a0b6de9307d4e9808ddf76b33d4129%40djangoproject.com.

Re: [Django] #27910: Allow using an Enum class in model Field choices

[Django]

#27910: Allow using an Enum class in model Field choices
-+-
 Reporter:  Marcel Hellwig   |Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  enum model choices   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"4d72c14bafefddd073b715c59834494ab77e9aa1" 4d72c14b]:
 {{{
 #!CommitTicketReference repository=""
 revision="4d72c14bafefddd073b715c59834494ab77e9aa1"
 [3.0.x] Refs #27910 -- Improved documentation for model field choice
 enumeration types.

 Backport of 1c66767d4e472fea27798812817b8a47c6ae22b3 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.3f60fe17817f9f93966fb699cb673087%40djangoproject.com.

Re: [Django] #27910: Allow using an Enum class in model Field choices

[Django]

#27910: Allow using an Enum class in model Field choices
-+-
 Reporter:  Marcel Hellwig   |Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  enum model choices   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1c66767d4e472fea27798812817b8a47c6ae22b3" 1c66767d]:
 {{{
 #!CommitTicketReference repository=""
 revision="1c66767d4e472fea27798812817b8a47c6ae22b3"
 Refs #27910 -- Improved documentation for model field choice enumeration
 types.
 }}}

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

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

Re: [Django] #30413: admin_views.test_multidb fails with persistent test SQLite database.

[Django]

#30413: admin_views.test_multidb fails with persistent test SQLite database.
-+-
 Reporter:  Daniel Hahler|Owner:  Ngalim
 |  Siregar
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


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

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

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

[Django]

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

Comment (by daviddavis):

 FWIW, the `usedforsecurity` flag will be available in Python 3.9+:

 https://github.com/python/cpython/pull/16044/

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

Re: [Django] #30758: DateTimeRangeField with default crashes in django admin (object has no attribute 'strip').

[Django]

#30758: DateTimeRangeField with default crashes in django admin (object has no
attribute 'strip').
-+-
 Reporter:  yeppus   |Owner:  Nasir
 |  Hussain
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  DateTimeRangeField   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1
 * needs_tests:  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/064.02cf9051006f102d5c73fd194d0555d1%40djangoproject.com.

Re: [Django] #30420: Do not reload runserver during debugging / request processing

[Django]

#30420: Do not reload runserver during debugging / request processing
-+-
 Reporter:  Daniel Hahler|Owner:  Kim
 |  Namjun
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => assigned
 * needs_better_patch:  0 => 1
 * version:  2.2 => master
 * owner:  nobody => Kim Namjun


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

Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
---+
 Reporter:  pixelcort  |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  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:  1
---+
Changes (by Tim Slot):

 * cc: Tim Slot (added)


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

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

Re: [Django] #30420: Do not reload runserver during debugging / request processing

[Django]

#30420: Do not reload runserver during debugging / request processing
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  2.2
  commands)  |
 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 bunseokbot):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11777 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.3d62334e7bd5c8ea94cceeadc10f423b%40djangoproject.com.

Re: [Django] #30770: Incorrect escaping TruncBase on ExpressionWrapper for date arithmetic.

[Django]

#30770: Incorrect escaping TruncBase on ExpressionWrapper for date arithmetic.
-+-
 Reporter:  Jurgis Pralgauskis   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  TruncBase, DateTime  | Triage Stage:
  arithmetics,   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


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

Re: [Django] #30770: Incorrect escaping TruncBase on ExpressionWrapper for date arithmetic. (was: annotating TruncBase on ExpressionWrapper for date arithmetic, causes unnecessary placeholder "%s" esc

[Django]

#30770: Incorrect escaping TruncBase on ExpressionWrapper for date arithmetic.
-+-
 Reporter:  Jurgis Pralgauskis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  TruncBase, DateTime  | Triage Stage:
  arithmetics,   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Thanks for this report, this issue was fixed in
 155b31d4ec138664d62665eb2d8a442469045b78 (Django 2.2+).

 Duplicate of #29648.

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

Re: [Django] #30771: Filtering on query result overrides GROUP BY of internal query

[Django]

#30771: Filtering on query result overrides GROUP BY of internal query
-+-
 Reporter:  Aur Saraf|Owner:  James
 |  Timmins
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  annotate,| Triage Stage:  Accepted
  annotation, filter, groupby,   |
  aggregate, aggregation |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


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

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