[Django] #28372: Admin inline JS should fire signal on add/remove to other JS can react.

[Django]

#28372: Admin inline JS should fire signal on add/remove to other JS can react.
--+
   Reporter:  Curtis Maloney  |  Owner:  nobody
   Type:  New feature | Status:  new
  Component:  contrib.admin   |Version:  1.11
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  1   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+
 Whilst chasing a bug reported to django-array-tags, I realised I needed to
 init my tag widget every time a new row was added on an admin inline.

 On perusal of the code, there is a callback each for added and removed,
 but they're pre-set.

 It would be simpler and more extensible to have these functions emit an
 Event, and have widgets listen for these to do their own fixups.

 This would also allow 3rd party widgets to partake.

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

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham):

 Maybe the bugfix is to change the search behavior to use the
 `filter_q_behavior` approach. Does it break any existing tests? Can you
 add a new test to show that it corrects the query for spanning relations?

 You can try bumping [https://groups.google.com/d/topic/django-
 developers/dpL5z1yOe58/discussion the thread on the mailing list] if you
 need more guidance. I'm employed to review patches, but besides that,
 Django is a volunteer-driven project, so there's no escalation process.
 Some of the people who worked on the ORM are no longer active
 contributors.

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

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by steve yeago):

 Yeah, with more robust approaches you get both bugs solved and new
 features. Perhaps you could elaborate more about what kind of patch you
 are hoping to see? One where filterspec objects filter upon objects and
 return them, but that somehow doesn't chain ORs? That is fundamentally not
 how chained querying works in django. If you're arguing that some kind of
 hackery on the filtered queryset to merge the joins is more preferable,
 then please say so. I don't really think you understand the parameters of
 this problem. If you could help escalate this issue to someone with some
 knowledge of the plumbing at play here I would very much appreciate it.
 Maybe they could chime in with something useful and we could push this
 very crucial and old problem (which I have been contending with for 9
 years through maintained forks) forward.

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

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

Re: [Django] #28361: test_was_published_recently_with_old_question test in the tutorial is time dependent

[Django]

#28361: test_was_published_recently_with_old_question test in the tutorial is 
time
dependent
-+-
 Reporter:  marton bognar|Owner:  marton
 |  bognar
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  datetime test| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"5b450b84e14f42302f58ec1f15a67a368e64d85c" 5b450b8]:
 {{{
 #!CommitTicketReference repository=""
 revision="5b450b84e14f42302f58ec1f15a67a368e64d85c"
 [1.11.x] Fixed #28361 -- Fixed possible time-related failure in
 was_published_recently() tutorial test.

 Regression in 268a646353c6fa9e5fc3730e13b386ddabb018ef.

 Backport of 82741605206382d0afd879c4bce174ef3d6e8aea 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/070.7e839a021aa619f784e81c4178c132d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28361: test_was_published_recently_with_old_question test in the tutorial is time dependent

[Django]

#28361: test_was_published_recently_with_old_question test in the tutorial is 
time
dependent
-+-
 Reporter:  marton bognar|Owner:  marton
 |  bognar
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  datetime test| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"82741605206382d0afd879c4bce174ef3d6e8aea" 82741605]:
 {{{
 #!CommitTicketReference repository=""
 revision="82741605206382d0afd879c4bce174ef3d6e8aea"
 Fixed #28361 -- Fixed possible time-related failure in
 was_published_recently() tutorial test.

 Regression in 268a646353c6fa9e5fc3730e13b386ddabb018ef.
 }}}

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

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham):

 I see [https://github.com/django/django/pull/7345 PR 7345], did I miss
 something else? My understanding is that patch adds a new feature rather
 than corrects the existing 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 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.5b706cd034ade6ffac2188bad0fd4670%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by steve yeago):

 The ticket was opened with a patch that evaluated that 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 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.343b754b4f1e6092c59a0108e042bf99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28369: Provide ModelAdmin hooks for reversing URLs

[Django]

#28369: Provide ModelAdmin hooks for reversing URLs
---+--
 Reporter:  steve yeago|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by steve yeago):

 Well in some ways I think the patch creates some consistency given that
 there is already a hook for the "view on site" url in the admin. Grepping
 around, there could be some savings of lines get_*_url in the tests where
 basically the same hooks already exists.

 Example: http://dpaste.com/1JFCGQG

 The current implementation presumes that a modeladmin is registered under
 a namespace with no other args or kwargs, but that may not be the case if
 someone has included additional url args in get_urls(). Almost everything
 about the admin works fine out of the box in this situation aside from the
 somewhat superficial problem of where the user is redirect post-save
 because, the urls that are being reversed deep in response_change (and
 subsequently response_post_save_change) are hard-coded.

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

Re: [Django] #26634: Add the ability to do subselects for querying versioned data

[Django]

#26634: Add the ability to do subselects for querying versioned data
-+-
 Reporter:  Darren Hobbs |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Per Simon's comment, perhaps this is addressed by #27149 -- Added Subquery
 and Exists database expressions.  If not, feel free to reopen and explain
 what further enhancements are 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/064.81f8b91b3f4bf941ce28d71606516524%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham):

 Actually it looks like Connor seconded treating the current behavior as a
 bug, so I think the next step would be to provide a patch for evaluating
 that 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 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.87ee678dca362729a6f1e4249eeafa04%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28371: Cast generating invalid SQL for SQLite and PostgreSQL

[Django]

#28371: Cast generating invalid SQL for SQLite and PostgreSQL
-+-
   Reporter: |  Owner:  nobody
  jamesdoherty   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  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  |
-+-
 I have a nullable IntegerField. When trying to cast it to a char, SQLite
 and PostgreSQL error due to invalid SQL:

 {{{
 class Numbers(models.Model):
 number = models.IntegerField(null=True)
 }}}

 The following code causes the error.
 {{{
 Numbers.objects.annotate(as_string=Cast('number', CharField()))
 }}}

 PostgreSQL

 {{{
 ProgrammingError: syntax error at or near "None"
 LINE 1: ...mbers"."number", "demo_numbers"."number"::varchar(None) AS "...

 SELECT "demo_numbers"."id", "demo_numbers"."number",
 "demo_numbers"."number"::varchar(None) AS "as_string" FROM "demo_numbers"
 }}}

 Removing the '(None)' from the SQL makes this work.

 SQLite

 {{{
 OperationalError: near "None": syntax error

 SELECT "demo_numbers"."id", "demo_numbers"."number",
 CAST("demo_numbers"."number" AS varchar(None)) AS "as_string" FROM
 "demo_numbers"
 }}}

 According to the SQLite documentation, varchar is not a valid type for
 SQLite: http://www.sqlite.org/lang_expr.html#castexpr

 Changing the SQL to 'CAST("demo_numbers"."number" AS TEXT)' succeeds. It's
 worth noting that it is possible to give SQLite an invalid cast type that
 doesn't cause an error (eg, try 'CAST("demo_numbers"."number" AS BOGUS)' )

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

Re: [Django] #28369: Provide ModelAdmin hooks for reversing URLs (was: Django Admin "Save and add another" NoReverseMatch with custom urls)

[Django]

#28369: Provide ModelAdmin hooks for reversing URLs
---+--
 Reporter:  steve yeago|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * needs_docs:  0 => 1
 * easy:  1 => 0
 * needs_tests:  0 => 1


Comment:

 I [https://groups.google.com/d/topic/django-
 developers/479TIjEk1_g/discussion lamented on django-developers] about the
 never ending number of `ModelAdmin` hooks. I fear we'll end up with an
 unmaintainable mess if we make every little thing customizable. Those
 methods would also need to be documented and tested. Perhaps you could
 describe your use case in more detail to help justify the additional
 complexity.

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

Re: [Django] #28370: Deprecate the unused context argument of Field.from_db_value() and Expression.convert_value()

[Django]

#28370: Deprecate the unused context argument of Field.from_db_value() and
Expression.convert_value()
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

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

[Django] #28370: Deprecate the unused context argument of Field.from_db_value() and Expression.convert_value()

[Django]

#28370: Deprecate the unused context argument of Field.from_db_value() and
Expression.convert_value()
-+-
   Reporter:  Tim|  Owner:  nobody
  Graham |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 It's unused as of a0d166306fbdc41f49e6fadf4ec84b17eb147daa.

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

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by steve yeago):

 Who are you waiting for a response from? I called it a bug long ago.

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

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham):

 I'm not sure what you're hoping to accomplish with that comment. Its
 meaning is vague and doesn't seem constructive. I haven't seen any
 responses to my suggestion in comment:21 to call the current behavior a
 bug and fix it. Perhaps it's a way to move forward.

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

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

Re: [Django] #28361: test_was_published_recently_with_old_question test in the tutorial is time dependent

[Django]

#28361: test_was_published_recently_with_old_question test in the tutorial is 
time
dependent
-+-
 Reporter:  marton bognar|Owner:  marton
 |  bognar
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  datetime test| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by marton bognar):

 * owner:  nobody => marton bognar
 * status:  new => assigned


Comment:

 Thanks, I submitted a pull request, hope it is alright:
 https://github.com/django/django/pull/8711

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

Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by steve yeago):

 Its pretty disappointing that all discussion on a ticket with a patch
 stops simply because a long-time contributor with some vague alternative
 assertions about how to approach the problem can't handle feedback.

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

Re: [Django] #28369: Django Admin "Save and add another" NoReverseMatch with custom urls

[Django]

#28369: Django Admin "Save and add another" NoReverseMatch with custom urls
---+--
 Reporter:  steve yeago|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by steve yeago):

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

[Django] #28369: Django Admin "Save and add another" NoReverseMatch with custom urls

[Django]

#28369: Django Admin "Save and add another" NoReverseMatch with custom urls
-+
   Reporter:  steve yeago|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Django admin could provide a hook for cases where there are additional
 parameters necessary to build an add or change url. Current hook
 "response_change" makes many hard-coded presumptions about how to reverse
 and add or change url. While its a nice hook to have for some cases, its
 so verbose that overriding it for this purpose is very hard.

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

Re: [Django] #28367: Document how to override management commands

[Django]

#28367: Document how to override management commands
--+
 Reporter:  stephanm  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 You could alias the overridden command by creating a new management
 command in your project and importing the overridden command there so that
 it's accessible under a different 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/066.5caf3e8b9a170690cb88b0cd089e6c65%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28368: Trying to create a model instance with an existing shared primary key in MTI silently updates an existing instance (was: Model Inheritance Primary Key Issue)

[Django]

#28368: Trying to create a model instance with an existing shared primary key in
MTI silently updates an existing instance
-+-
 Reporter:  Lawrence Elitzer |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 I see your point. I'm not sure if that can or should be changed but if you
 offer a patch, we can evaluate it further.

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

Re: [Django] #28367: Document how to override management commands

[Django]

#28367: Document how to override management commands
--+
 Reporter:  stephanm  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 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 stephanm):

 OK, so I did the right thing in my projects.

 But one question remains:

 What should I do if some day I need a django app
 from pypi which has the same management commands?
 (... or more than one django app from pypi where
 all of them have management command names collisions)

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

Re: [Django] #28331: Add an extra_context attribute to class-based generic views that use ContextMixin (e.g. TemplateView)

[Django]

#28331: Add an extra_context attribute to class-based generic views that use
ContextMixin (e.g. TemplateView)
-+-
 Reporter:  Jeremy   |Owner:  Bruno
 Type:   |  Alla
  Cleanup/optimization   |   Status:  closed
Component:  Generic views|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"604341c85fe42c809d17ea2418566a48f60f78db" 604341c]:
 {{{
 #!CommitTicketReference repository=""
 revision="604341c85fe42c809d17ea2418566a48f60f78db"
 Fixed #28331 -- Added ContextMixin.extra_context to allowing passing
 context in as_view().
 }}}

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

Re: [Django] #28368: Model Inheritance Primary Key Issue

[Django]

#28368: Model Inheritance Primary Key Issue
-+-
 Reporter:  Lawrence Elitzer |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Lawrence Elitzer):

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


Comment:

 I have read through the Abstract Class before and since I want to access
 the parent model directly in my app, I need the multi-table inheritance. I
 expect the behavior to be that when creating objects that have the same
 parent primary_key there is a duplicate error reported instead of just
 overwriting the parent record. Does this make sense? I don't see why this
 isn't the case with multi-table inheritance. I can submit an email if that
 is better. I don't have access to any IRC clients at my workplace.

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

Re: [Django] #28368: Model Inheritance Primary Key Issue

[Django]

#28368: Model Inheritance Primary Key Issue
-+-
 Reporter:  Lawrence Elitzer |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (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
-+-
Changes (by Tim Graham):

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


Comment:

 Have you read the
 [https://docs.djangoproject.com/en/stable/topics/db/models/#model-
 inheritance model inheritance documentation]? You're using multi-table
 inheritance so FT1 and FT4 share a common parent table. Maybe you want to
 make `CommonImportedFile` an abstract model instead. If you understand
 those points and still think this is a bug, then please explain what the
 expected behavior would be. In the future, please
 [TicketClosingReasons/UseSupportChannels use our support channels] to ask
 "is it a bug?" questions. Thanks.

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

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

Re: [Django] #28368: Model Inheritance Primary Key Issue

[Django]

#28368: Model Inheritance Primary Key Issue
-+-
 Reporter:  Lawrence Elitzer |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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
-+-
Description changed by Lawrence Elitzer:

Old description:

> I am using model inheritance and when I set my own primary_key in the
> parent class as one of the fields I define, when I try to create child
> objects with the same primary key I am NOT getting a duplicate error.
> Instead, it is overwriting the parent class fields. In the two child
> tables in the example code below, both parent pointers in the two child
> object tables point to the same parent record.
>
> {{{
> # models.py
> from django.db import models
>
> class CommonImportedFile(models.Model):
> sha  = models.CharField(max_length=40, primary_key=True)
> name = models.CharField(max_length=200)
>
> class FT1(CommonImportedFile):
> pass
>
> class FT4(CommonImportedFile):
> pass
> }}}
>
> And here are the commands I am using:
>
> {{{
> from myapp.models import *
> FT1.objects.create(name='ft1', sha='1234')
> FT4.objects.create(name='ft4', sha='1234')
> cf = CommonImportedFile.objects.get(sha='1234')
> cf.name
> }}}
>
> cf.name is 'ft4' here indicating to me that the second object creation is
> overwriting the parent record entry since the primary_key 'sha' field is
> the same for both object creations. If you get rid of the primary_key
> attribute in the 'sha' field and instead put 'unique=True' then this
> works as I think it should. Seems like a bug to me, or am I using
> inheritance incorrectly here?

New description:

 I am using model inheritance and when I set my own primary_key in the
 parent class as one of the fields I define, when I try to create child
 objects with the same primary key I am NOT getting a duplicate error.
 Instead, it is overwriting the parent class fields. In the two child
 tables in the example code below, both parent pointers in the two child
 object tables point to the same parent record.

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

 class CommonImportedFile(models.Model):
 sha  = models.CharField(max_length=40, primary_key=True)
 name = models.CharField(max_length=200)

 class FT1(CommonImportedFile):
 pass

 class FT4(CommonImportedFile):
 pass
 }}}

 And here are the commands I am using:

 {{{
 from myapp.models import *
 FT1.objects.create(name='ft1', sha='1234')
 FT4.objects.create(name='ft4', sha='1234')
 cf = CommonImportedFile.objects.get(sha='1234')
 cf.name
 }}}

 cf.name is 'ft4' here indicating to me that the second object creation is
 overwriting the parent record entry since the primary_key 'sha' field is
 the same for both object creations. If you get rid of the primary_key
 attribute in the 'sha' field and instead put 'unique=True' then this works
 as I think it should. Seems like a bug to me, or am I using inheritance
 incorrectly here?

 I am using Django v. 1.11.3 and Python 3.6.1 with MariaDB 5.5.52 on CentOS
 7.

--

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

Re: [Django] #28368: Model Inheritance Primary Key Issue

[Django]

#28368: Model Inheritance Primary Key Issue
-+-
 Reporter:  Lawrence Elitzer |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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
-+-
Description changed by Lawrence Elitzer:

Old description:

> I am using model inheritance and when I set my own primary_key in the
> parent class as one of the fields I define, when I try to create child
> objects with the same primary key I am NOT getting a duplicate error.
> Instead, it is overwriting the parent class fields. In the two child
> tables in the example code below, both parent pointers in the two child
> object tables point to the same parent record.
>
> {{{
> # models.py
> from django.db import models
>
> class CommonImportedFile(models.Model):
> sha  = models.CharField(max_length=40, primary_key=True)
> name = models.CharField(max_length=200)
>
> class FT1(CommonImportedFile):
> pass
>
> class FT4(CommonImportedFile):
> pass
> }}}
>
> And here are the commands I am using:
>
> {{{
> from myapp.models import *
> FT1.objects.create(name='ft1', sha='1234')
> FT4.objects.create(name='ft4', sha='1234')
> cf = CommonImportedFile.objects.get(sha='1234')
> cf.name
> }}}
>
> cf.name is 'ft4' here indicating to me that the second object creation is
> overwriting the parent record entry since the primary_key 'sha' field is
> the same for both object creations. If you get rid of the primary_key
> attribute in the 'sha' field and instead put 'unique=True' then this
> works as I think it should. Seems like a bug to me, or am I using
> inheritance incorrectly here?
>
> I am using Django v. 1.11.3 and Python 3.6.1 with MariaDB 5.5.52 on
> CentOS 7.

New description:

 I am using model inheritance and when I set my own primary_key in the
 parent class as one of the fields I define, when I try to create child
 objects with the same primary key I am NOT getting a duplicate error.
 Instead, it is overwriting the parent class fields. In the two child
 tables in the example code below, both parent pointers in the two child
 object tables point to the same parent record.

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

 class CommonImportedFile(models.Model):
 sha  = models.CharField(max_length=40, primary_key=True)
 name = models.CharField(max_length=200)

 class FT1(CommonImportedFile):
 pass

 class FT4(CommonImportedFile):
 pass
 }}}

 And here are the commands I am using:

 {{{
 from myapp.models import *
 FT1.objects.create(name='ft1', sha='1234')
 FT4.objects.create(name='ft4', sha='1234')
 cf = CommonImportedFile.objects.get(sha='1234')
 cf.name
 }}}

 cf.name is 'ft4' here indicating to me that the second object creation is
 overwriting the parent record entry since the primary_key 'sha' field is
 the same for both object creations. If you get rid of the primary_key
 attribute in the 'sha' field and instead put 'unique=True' then this works
 as I think it should. Seems like a bug to me, or am I using inheritance
 incorrectly here?

 I am using Django 1.11.3 and Python 3.6.1 with MariaDB 5.5.52 on CentOS 7.

--

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

Re: [Django] #28368: Model Inheritance Primary Key Issue

[Django]

#28368: Model Inheritance Primary Key Issue
-+-
 Reporter:  Lawrence Elitzer |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Lawrence Elitzer):

 * component:  Uncategorized => Database layer (models, ORM)


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

[Django] #28368: Model Inheritance Primary Key Issue

[Django]

#28368: Model Inheritance Primary Key Issue
+
   Reporter:  Lawrence Elitzer  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Uncategorized |Version:  1.11
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I am using model inheritance and when I set my own primary_key in the
 parent class as one of the fields I define, when I try to create child
 objects with the same primary key I am NOT getting a duplicate error.
 Instead, it is overwriting the parent class fields. In the two child
 tables in the example code below, both parent pointers in the two child
 object tables point to the same parent record.

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

 class CommonImportedFile(models.Model):
 sha  = models.CharField(max_length=40, primary_key=True)
 name = models.CharField(max_length=200)

 class FT1(CommonImportedFile):
 pass

 class FT4(CommonImportedFile):
 pass
 }}}

 And here are the commands I am using:

 {{{
 from myapp.models import *
 FT1.objects.create(name='ft1', sha='1234')
 FT4.objects.create(name='ft4', sha='1234')
 cf = CommonImportedFile.objects.get(sha='1234')
 cf.name
 }}}

 cf.name is 'ft4' here indicating to me that the second object creation is
 overwriting the parent record entry since the primary_key 'sha' field is
 the same for both object creations. If you get rid of the primary_key
 attribute in the 'sha' field and instead put 'unique=True' then this works
 as I think it should. Seems like a bug to me, or am I using inheritance
 incorrectly here?

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

Re: [Django] #28367: Document how to override management commands (was: howto handle different apps with same custom management command names?)

[Django]

#28367: Document how to override management commands
--+
 Reporter:  stephanm  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 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 Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted
 * component:  Uncategorized => Documentation


Comment:

 You need to use unique command names -- there's no notion of namespacing,
 though this was suggested in #27189, I don't think there was an follow up
 on that idea.

 I'll classify this as a documentation ticket for explaining how to
 override management commands. There's a brief discussion
 [https://stackoverflow.com/questions/29320103/if-multiple-django-apps-
 define-the-same-custom-management-command-which-is-used on StackOverflow]
 which could be a useful starting point in writing some 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/066.69b93f51747fd471fafdc19e13495245%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28355: Widget rendering of non-ASCII date/time formats fails on Python 2

[Django]

#28355: Widget rendering of non-ASCII date/time formats fails on Python 2
-+
 Reporter:  Samir Shah   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  widget   | Triage Stage:  Accepted
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:"42e91cd6f4a5ea79ebacbc58a9ffaf115d8800d5" 42e91cd]:
 {{{
 #!CommitTicketReference repository=""
 revision="42e91cd6f4a5ea79ebacbc58a9ffaf115d8800d5"
 Refs #28355 -- Forwardported 1.11.4 release note.
 }}}

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

Re: [Django] #27670: Loading shell crashes when pythonrc file contains error

[Django]

#27670: Loading shell crashes when pythonrc file contains error
-+-
 Reporter:  Peter Inglesby   |Owner:  Peter
 |  Inglesby
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.10
  commands)  |
 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:"0ba57c395796a5644cd0f880ac9fa7052d318021" 0ba57c3]:
 {{{
 #!CommitTicketReference repository=""
 revision="0ba57c395796a5644cd0f880ac9fa7052d318021"
 Fixed #27670 -- Prevented shell crash on error in .pythonrc.
 }}}

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

Re: [Django] #28355: Widget rendering of non-ASCII date/time formats fails on Python 2

[Django]

#28355: Widget rendering of non-ASCII date/time formats fails on Python 2
-+
 Reporter:  Samir Shah   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  widget   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"81febf4defe6f6da2dea80f24082b282b8bf30ca" 81febf4d]:
 {{{
 #!CommitTicketReference repository=""
 revision="81febf4defe6f6da2dea80f24082b282b8bf30ca"
 [1.11.x] Fixed #28355 -- Fixed widget rendering of non-ASCII date/time
 formats on Python 2.
 }}}

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

[Django] #28367: howto handle different apps with same custom management command names?

[Django]

#28367: howto handle different apps with same custom management command names?
-+
   Reporter:  stephanm   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Hi,

 I have one question where I didn't find the answer in the docs.

 If I  have two django apps:
  - app1
  - app2

 and both apps have lets say a custom management command called:
  - importdata

 Actually I do the following:

 In every app I prepend the custom command name with the app name,
 so in my case the custom commands would be named:

  - app1_importdata (for app1)
  - app2_importdata (for app2)

 But what is the official "correct" way?

 Does there exist some sort of namespace like:
  - app1.importdata
  - app2.importdata

 or it is planned (in Django 2.x)?

 If I have two external apps not programmed by myself
 and both have one same-named management command...
 how do I solve the problem?

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

Re: [Django] #28364: Optimize Oracle relations introspection by removing redundant table joins.

[Django]

#28364: Optimize Oracle relations introspection by removing redundant table 
joins.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle   | Triage Stage:  Ready for
  get_relations  |  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:"cf57ecb2212b3c0af03550f7000d5a9a8adbb7d6" cf57ecb]:
 {{{
 #!CommitTicketReference repository=""
 revision="cf57ecb2212b3c0af03550f7000d5a9a8adbb7d6"
 Fixed #28364 -- Removed redundant table joins in Oracle's
 DatabaseIntrospection.get_relations().
 }}}

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

Re: [Django] #28365: Unify date_interval_sql() method with other backend date/datetime/time operations.

[Django]

#28365: Unify date_interval_sql() method with other backend date/datetime/time
operations.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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:"df1106a40ff0cb8946e36e96edb1da6301e0eacd" df1106a4]:
 {{{
 #!CommitTicketReference repository=""
 revision="df1106a40ff0cb8946e36e96edb1da6301e0eacd"
 Fixed #28365 -- Unified DatabaseOperations.date_interval_sql() return
 value with similar methods.
 }}}

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

Re: [Django] #28366: AlterUniqueTogether and RemoveField on same field lead to migration error

[Django]

#28366: AlterUniqueTogether and RemoveField on same field lead to migration 
error
-+-
 Reporter:  Rhaskaas |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  AlterUniqueTogether  | Triage Stage:
  RemoveField migrate|  Unreviewed
  makemigrations |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Looks like a duplicate of #26180.

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

[Django] #28366: AlterUniqueTogether and RemoveField on same field lead to migration error

[Django]

#28366: AlterUniqueTogether and RemoveField on same field lead to migration 
error
-+-
   Reporter:  Rhaskaas   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  1.11
  Migrations |   Keywords:  AlterUniqueTogether
   Severity:  Normal |  RemoveField migrate makemigrations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Consider a model with a field who's used in unique_together.\\
 You want to remove this field and so change the uniquet_together Meta at
 the same time (in models.py).


 When you do this and apply "makemigrations", the resulting migration file
 is not usable.\\
 Indeed, "migrations.RemoveField" is use "before
 migrations.AlterUniqueTogether" and lead to
 "django.core.exceptions.FieldDoesNotExist" error.\\
 If you change order manualy in migration file (i.e. alter first and remove
 after) there is no more problem.

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