Re: [Django] #29085: Possible data loss on .save() with unsaved related model

2018-06-18 Thread Django 
#29085: Possible data loss on .save() with unsaved related model
-+-
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-

Comment (by Matthew Schinckel):

 I believe I hit the same issue today.

 I have a set of related objects that I want to construct all of the forms
 for, validate all of them, and then save.

 However, the reference to the primary object (which is still "connected"
 to the child instances) is removed when saving.

 I _think_ it's got to do with `Field.pre_save(self, model_instance, add)`
 being called before saving: which uses `field.attname`, which is
 necessarily empty initially (because we don't have a primary key on the
 reference object, yet).

 I'm going to play around, but I think it could be that a ForeignKey can
 have slightly different behaviour, where it falls back to the related (in-
 memory) object, if one exists, and `field.attname` is None.

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

[Django] #29506: Misleading migrate "App 'apps.somethings' does not have migrations." error message with nested apps

2018-06-18 Thread Django 
#29506: Misleading migrate "App 'apps.somethings' does not have migrations." 
error
message with nested apps
-+-
   Reporter:  oliver |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core   |Version:  master
  (Management commands)  |
   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  |
-+-
 If you have a couple of nested apps, or apps that are not available
 directly in the top-level namespace and you use migrate command, and pass
 the full dotted path to this command, the error message is somewhat
 misleading:

 {{{
 CommandError: App 'apps.somethings' does not have migrations.
 }}}

 In this case,  the somethings app have migrations, but migrate command
 expecting just app_label.

 And there is the other misleading error message.
 If you use migrate command and pass nonexistent app in your INSTALLED_APP,
 the error message is somewhat misleading:

 {{{
 CommandError: App 'nonexistent_app' does not have migrations.
 }}}
 In this case, the nonexistent_app does not exist, but the error message
 make user think that nonexistent app just don't have migrations.

 Currently, makemigrations command check for existence and validity of app.
 As follows

 {{{
 # Make sure the app they asked for exists
 app_labels = set(app_labels)
 bad_app_labels = set()
 for app_label in app_labels:
 try:
 apps.get_app_config(app_label)
 except LookupError:
 bad_app_labels.add(app_label)
 if bad_app_labels:
 for app_label in bad_app_labels:
 if '.' in app_label:
 self.stderr.write(
 "'%s' is not a valid app label. Did you mean
 '%s'?" % (
 app_label,
 app_label.split('.')[-1],
 )
 )
 else:
 self.stderr.write("App '%s' could not be found. Is it
 in INSTALLED_APPS?" % app_label)
 sys.exit(2)
 }}}

 How about checking that in migrate command?

 == This ticket is very similar to
 https://code.djangoproject.com/ticket/29469.
 But it is about migrate not makemigrations.
 Please read this ticket.

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

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

Re: [Django] #29503: Order of parameters pass to __in lookup affected by de-duplication.

2018-06-18 Thread Django 
#29503: Order of parameters pass to __in lookup affected by de-duplication.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ian Foote):

 * cc: Ian Foote (added)


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

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

Re: [Django] #29456: Django 1.11 same filter_list get redisplayed in different model admin page

2018-06-18 Thread Django 
#29456: Django 1.11 same filter_list get redisplayed in different model admin 
page
---+--
 Reporter:  grpoundblue|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  invalid
 Keywords:  list_filter| 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):

 * resolution:  needsinfo => invalid


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

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

Re: [Django] #29456: Django 1.11 same filter_list get redisplayed in different model admin page

2018-06-18 Thread Django 
#29456: Django 1.11 same filter_list get redisplayed in different model admin 
page
---+--
 Reporter:  grpoundblue|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  list_filter| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by grpoundblue):

 Finally I was able to get rid of this weird behavior, honestly without
 investigating further. However I put this here hopefully someone can
 figure it out the exact cause.
 I had a custom template for change_list.html like below, the motivation
 was to increase  performance in page loading :

 {{{
 PROJECT_HOME/myapp/templates/admin/myapp/change_list.html
 }}}

 The file's content was :

 {{{
 {% extends "admin/change_list.html" %}
 {% load admin_list i18n cache %}

 {% block filters %}
 
 {% cache 300 admin_filters request.GET.items request.path
 request.user.username %}
 {% if cl.has_filters %}
   
 {% trans 'Filter' %}
 {% for spec in cl.filter_specs %}{% admin_list_filter cl spec
 %}{% endfor %}
   
 {% endif %}
 {% endcache %}
 {% endblock %}
 }}}


 So I just removed this custom template.

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

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

Re: [Django] #29419: Allow permissioning of admin actions

2018-06-18 Thread Django 
#29419: Allow permissioning of admin actions
-+-
 Reporter:  Paulo|Owner:  Carlton
 |  Gibson
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"306f1f8ea3e2b54e194a59ac0ecb686460f180e8" 306f1f8]:
 {{{
 #!CommitTicketReference repository=""
 revision="306f1f8ea3e2b54e194a59ac0ecb686460f180e8"
 [2.1.x] Fixed #29419 -- Allowed permissioning of admin actions.

 Backport of 958c7b301ead79974db8edd5b9c6588a10a28ae7 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/066.19e53b4d642eb1adab95dcde0bad229d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29502: AutocompleteJsonView doesn't work if user has "view" but not "change"

2018-06-18 Thread Django 
#29502: AutocompleteJsonView doesn't work if user has "view" but not "change"
-+-
 Reporter:  Matthew Frazier  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | 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:"67fc680c43b4f4fddb7bf4988088b1ef7f36bbdd" 67fc680c]:
 {{{
 #!CommitTicketReference repository=""
 revision="67fc680c43b4f4fddb7bf4988088b1ef7f36bbdd"
 [2.1.x] Fixed #29502 -- Allowed users with the view permission to use
 autocomplete_fields.

 Backport of 5b733171813f8ddc7af84abe79f2646204b9c6ca from master
 }}}

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

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

Re: [Django] #29502: AutocompleteJsonView doesn't work if user has "view" but not "change"

2018-06-18 Thread Django 
#29502: AutocompleteJsonView doesn't work if user has "view" but not "change"
-+-
 Reporter:  Matthew Frazier  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | 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:"5b733171813f8ddc7af84abe79f2646204b9c6ca" 5b73317]:
 {{{
 #!CommitTicketReference repository=""
 revision="5b733171813f8ddc7af84abe79f2646204b9c6ca"
 Fixed #29502 -- Allowed users with the view permission to use
 autocomplete_fields.
 }}}

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

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

Re: [Django] #29419: Allow permissioning of admin actions

2018-06-18 Thread Django 
#29419: Allow permissioning of admin actions
-+-
 Reporter:  Paulo|Owner:  Carlton
 |  Gibson
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"958c7b301ead79974db8edd5b9c6588a10a28ae7" 958c7b30]:
 {{{
 #!CommitTicketReference repository=""
 revision="958c7b301ead79974db8edd5b9c6588a10a28ae7"
 Fixed #29419 -- Allowed permissioning of admin actions.
 }}}

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

Re: [Django] #29501: Add support for ./manage.py dbshell -c SQL

2018-06-18 Thread Django 
#29501: Add support for ./manage.py dbshell -c SQL
-+-
 Reporter:  Artem Skoretskiy |Owner:  Zijian He
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 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 Zijian He):

 * owner:  nobody => Zijian He
 * cc: Zijian He (added)
 * status:  new => assigned


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

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

[Django] #29505: Impossible to set a Field's default value to a callable

2018-06-18 Thread Django 
#29505: Impossible to set a Field's default value to a callable
-+-
   Reporter:  Eugene |  Owner:  nobody
  Pakhomov   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  default
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 I'm trying to use https://github.com/cognitect/transit-python and I
 created a custom `KeywordField` for this.
 The problem is that `transit.transit_types.Keyword` is a callable. Now,
 even if I override `_get_default` in `KeywordField`, it still won't work
 because
 `django.db.backends.base.schema.BaseDatabaseSchemaEditor#effective_default`
 checks the value again.

 I think a simple fix would be to remove this check from
 `effective_default` and immediately make a call where it's necessary
 (`datetime.date` etc).

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

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

Re: [Django] #29504: JSONField dictionary/object lookup using an "integer" key

2018-06-18 Thread Django 
#29504: JSONField dictionary/object lookup using an "integer" key
---+--
 Reporter:  Shaheed Haque  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  2.0
 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:  1
---+--
Description changed by Shaheed Haque:

Old description:

> The documentation on performing queries inside JSONField values
> [https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/fields/#key-
> index-and-path-lookups] says:
>
> {{{
> If the key is an integer, it will be interpreted as an index lookup in an
> array:
>
> >>> Dog.objects.filter(data__owner__other_pets__0__name='Fishy')
> }}}
>
> Note the specific mention of **array**. While this might be true, it is
> not the whole truth as applied to **dict/object**. For example, given a
> **dict/object** whose keys are strings (as always in JSON) but which look
> like integers:
>
> {{{
>   "employee": {
> "415": {
>   "email": "sherlock.hol...@acme.co.uk",
>   "mobile": "0700 1234567",
> }}}
>
> how is one supposed to select the **"415"** bit? It turns out that the
> same syntax as for the array case applies:
>
> {{{
> Foo.objects.filter(snapshot__employee__415__mobile='0700 1234567')
> }}}
>
> This was not at all obvious to me at least, especially as if the
> **"415"** is looked up as the terminal level in the query, the syntax
> becomes very different:
>
> {{{
> Foo.objects.filter(snapshot__employee__has_key='415')
> }}}
>
> Since I wasted quite a bit of time on this, I thought it might be useful
> to strengthen the documentation in this area to clarify how to lookup:
>
> * In arrays and dict/objects
> * if the key is the final term in the query
> * if the key is not the final term in the query

New description:

 The documentation on performing queries inside JSONField values
 [https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/fields/#key-
 index-and-path-lookups] says:

 {{{
 If the key is an integer, it will be interpreted as an index lookup in an
 array:

 >>> Dog.objects.filter(data__owner__other_pets__0__name='Fishy')
 }}}

 Note the specific mention of **array**. While this might be true, it is
 not the whole truth as applied to **dict/object**. For example, given a
 **dict/object** whose keys are strings (as always in JSON) but which look
 like integers:

 {{{
   "employee": {
 "415": {
   "email": "sherlock.hol...@acme.co.uk",
   "mobile": "0700 1234567",
 }}}

 how is one supposed to select the **"415"** bit? It turns out that the
 same syntax as for the array case applies:

 {{{
 Foo.objects.filter(snapshot__employee__415__mobile='0700 1234567')
 }}}

 This was not at all obvious to me at least, especially as if the **"415"**
 is looked up as the final key in the query, the syntax becomes very
 different:

 {{{
 Foo.objects.filter(snapshot__employee__has_key='415')
 }}}

 Since I wasted quite a bit of time on this, I thought it might be useful
 to strengthen the documentation in this area to clarify how to lookup:

 * In arrays and dict/objects
 * if the key is the final term in the query
 * if the key is not the final term in the query

--

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

[Django] #29504: JSONField dictionary/object lookup using an "integer" key

2018-06-18 Thread Django 
#29504: JSONField dictionary/object lookup using an "integer" key
-+
   Reporter:  Shaheed Haque  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  2.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+
 The documentation on performing queries inside JSONField values
 [https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/fields/#key-
 index-and-path-lookups] says:

 {{{
 If the key is an integer, it will be interpreted as an index lookup in an
 array:

 >>> Dog.objects.filter(data__owner__other_pets__0__name='Fishy')
 }}}

 Note the specific mention of **array**. While this might be true, it is
 not the whole truth as applied to **dict/object**. For example, given a
 **dict/object** whose keys are strings (as always in JSON) but which look
 like integers:

 {{{
   "employee": {
 "415": {
   "email": "sherlock.hol...@acme.co.uk",
   "mobile": "0700 1234567",
 }}}

 how is one supposed to select the **"415"** bit? It turns out that the
 same syntax as for the array case applies:

 {{{
 Foo.objects.filter(snapshot__employee__415__mobile='0700 1234567')
 }}}

 This was not at all obvious to me at least, especially as if the **"415"**
 is looked up as the terminal level in the query, the syntax becomes very
 different:

 {{{
 Foo.objects.filter(snapshot__employee__has_key='415')
 }}}

 Since I wasted quite a bit of time on this, I thought it might be useful
 to strengthen the documentation in this area to clarify how to lookup:

 * In arrays and dict/objects
 * if the key is the final term in the query
 * if the key is not the final term in the query

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

Re: [Django] #29503: Order of parameters pass to __in lookup affected by de-duplication.

2018-06-18 Thread Django 
#29503: Order of parameters pass to __in lookup affected by de-duplication.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Pope):

 Replying to [comment:2 Tim Graham]:
 > What practical problem did you encounter? I'm surprised that the order
 of items in an `IN` clause would matter much.

 Heh. I get the feeling that I'm going to get shot down here (and I know
 and understand the reasons why).

 I've inherited some code that currently and for the foreseeable future
 depends on the output of the query generated by `Query.sql_with_params()`.
 It executes it via `pandas.DataFrame.read_sql_query()` and also uses this
 to generate a cache key. Because the parameter ordering is unstable, this
 affects the key generation.

 Regardless of the horrors of this, the issue looks like a regression to me
 - the previous behaviour changed unexpectedly. I can understand if you'd
 like to only apply this to master, however.

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

Re: [Django] #29490: Subresource integrity for form assets

2018-06-18 Thread Django 
#29490: Subresource integrity for form assets
-+
 Reporter:  Meiyer   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham):

 I'd say maybe. There's also some thought in #22298 to deprecate the
 `Media` class.

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

Re: [Django] #29503: Order of parameters pass to __in lookup affected by de-duplication.

2018-06-18 Thread Django 
#29503: Order of parameters pass to __in lookup affected by de-duplication.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 What practical problem did you encounter? I'm surprised that the order of
 items in an `IN` clause would matter much.

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

Re: [Django] #29503: Order of parameters pass to __in lookup affected by de-duplication.

2018-06-18 Thread Django 
#29503: Order of parameters pass to __in lookup affected by de-duplication.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #25544: prefetch_related sends duplicate ids to database

2018-06-18 Thread Django 
#25544: prefetch_related sends duplicate ids to database
-+-
 Reporter:  Julien Hartmann  |Owner:  Ian Foote
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prefetch duplicate   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Pope):

 The fix to this resulted in a regression where parameters passed to `__in`
 were reordered due to the use of `set()`. See #29503.

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

Re: [Django] #29502: AutocompleteJsonView doesn't work if user has "view" but not "change"

2018-06-18 Thread Django 
#29502: AutocompleteJsonView doesn't work if user has "view" but not "change"
-+-
 Reporter:  Matthew Frazier  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | 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):

 * stage:  Accepted => Ready for checkin


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

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

[Django] #29503: Order of parameters pass to __in lookup affected by de-duplication.

2018-06-18 Thread Django 
#29503: Order of parameters pass to __in lookup affected by de-duplication.
-+-
   Reporter:  Nick Pope  |  Owner:  Nick Pope
   Type:  Bug| Status:  assigned
  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  |
-+-
 After the fix for ticket #25544, the order of parameters passed to the
 `__in` lookup is affected by the de-duplication using `set()`.

 This results in the generated query being unstable between different runs
 of the python interpreter due to hash seed randomisation.

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

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

Re: [Django] #29502: AutocompleteJsonView doesn't work if user has "view" but not "change"

2018-06-18 Thread Django 
#29502: AutocompleteJsonView doesn't work if user has "view" but not "change"
-+-
 Reporter:  Matthew Frazier  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Matthew Frazier):

 To deal with the inconsistency you mentioned, the autocomplete view for a
 model could accept query arguments:
 `for_app=[APP]_model=[MODEL]=[FOREIGN_KEY]`. If those arguments are
 present it would look up the `ModelAdmin` for the indicated app and model,
 verify that the user `has_add_permission` or `has_change_permission` on
 the indicated model, and verify that `fk` refers to the model being
 autocompleted.

 This would allow a `ForeignKey` to work the same way whether it was in
 `autocomplete_fields` or not, but it would make the patch more involved.
 It also introduces a slight security risk: if a model `A` has a
 `ForeignKey` to another model `B`, then the user can still look up the
 values of `B` even if the `ModelAdmin` to `A` doesn't permit them to edit
 the `ForeignKey` to `B`.

 Another option that eliminates that security risk, but increases
 complexity even more, is to store the models a user needs access to
 autocomplete in their session. That is probably too much work with too
 much potential security exposure to include in 2.1.0 since the beta is
 supposed to go out today.

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

Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

2018-06-18 Thread Django 
#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
-+-
 Reporter:  David Szotten|Owner:  Romain
 |  Garrigues
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  1.8
 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 jedie):

 * cc: jedie (added)


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

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

Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

2018-06-18 Thread Django 
#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
-+-
 Reporter:  David Szotten|Owner:  Romain
 |  Garrigues
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  1.8
 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
-+-

Comment (by jedie):

 confirm this bug with Django==1.11.13

 Any news, work-a-round 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 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.bc94ec99274c67da2c461a92d3bf1254%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29500: SQLite functions crashes on NULL values

2018-06-18 Thread Django 
#29500: SQLite functions crashes on NULL values
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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 Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK, thanks for the clarification. We could certainly consider a PR adding
 test cases and a bulletproofing to the functions we're shipping.

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

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

Re: [Django] #29500: SQLite functions crashes on NULL values

2018-06-18 Thread Django 
#29500: SQLite functions crashes on NULL values
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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
-+-

Comment (by Sergey Fedoseev):

 Replying to [comment:1 Carlton Gibson]:

 > I'll guess it'll be this:

 It is.

 By `SQLite functions` I meant user-defined function created here:
 
https://github.com/django/django/blob/6dd4edb1b4f5441c5f543e29395039839c50d10b/django/db/backends/sqlite3/base.py#L158-L175

 The list (incomplete?) of functions that crash on NULL values:
 *
 
[https://github.com/django/django/blob/6dd4edb1b4f5441c5f543e29395039839c50d10b/django/db/backends/sqlite3/base.py#L449
 _sqlite_time_diff]
 *
 
[https://github.com/django/django/blob/6dd4edb1b4f5441c5f543e29395039839c50d10b/django/db/backends/sqlite3/base.py#L464
 _sqlite_timestamp_diff]
 *
 
[https://github.com/django/django/blob/6dd4edb1b4f5441c5f543e29395039839c50d10b/django/db/backends/sqlite3/base.py#L474
 _sqlite_lpad]
 *
 
[https://github.com/django/django/blob/6dd4edb1b4f5441c5f543e29395039839c50d10b/django/db/backends/sqlite3/base.py#L480
 _sqlite_rpad]
 *
 
[https://github.com/django/django/blob/6dd4edb1b4f5441c5f543e29395039839c50d10b/django/db/backends/sqlite3/base.py#L484
 _sqlite_power]

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

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

Re: [Django] #29500: SQLite functions crashes on NULL values

2018-06-18 Thread Django 
#29500: SQLite functions crashes on NULL values
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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 Carlton Gibson):

 * cc: Carlton Gibson (added)


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

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

Re: [Django] #29500: SQLite functions crashes on NULL values

2018-06-18 Thread Django 
#29500: SQLite functions crashes on NULL values
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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
-+-

Comment (by Carlton Gibson):

 Hmmm. Not sure we'll be able to do anything about this. (Postgres
 certainly behaves better.)

 Could you
 
[https://docs.python.org/3/library/sqlite3.html#sqlite3.enable_callback_tracebacks
 enable callback trackbacks] on the client? We can then see the error.

 I'll guess it'll be this:

 ```
 >>> None ** None
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: unsupported operand type(s) for ** or pow(): 'NoneType' and
 'NoneType'
 ```

 If so we may just have to workaround it by using a function for `pow`
 which checks for `None`.

 This works:

 ```
 >>>
 
TestModel.objects.annotate(null=Value(None,output_field=models.IntegerField())).values(pow=models.F('null')).first()
 {'pow': None}
 ```

 So it's just the `**` operation.

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

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

Re: [Django] #29485: Testing with Oracle in AWS RDS (oracle managed files)

2018-06-18 Thread Django 
#29485: Testing with Oracle in AWS RDS (oracle managed files)
-+-
 Reporter:  Vackar Afzal |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  oracle, testing, | Triage Stage:
  OMF, AWS, RDS  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Vackar Afzal):

 My current approach is to Monkey patch the default statements to read as
 follows:
 {{{

 statements = [
  """CREATE TABLESPACE %(tblspace)s""",
  """CREATE TEMPORARY TABLESPACE %(tblspace_temp)s""",
 ]

 }}}

 Works for the time being, but would be nice to have it integrated back
 into django

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

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

Re: [Django] #29449: UserCreationForm and UserChangeForm don't work if username isn't a CharField

2018-06-18 Thread Django 
#29449: UserCreationForm and UserChangeForm don't work if username isn't a
CharField
-+-
 Reporter:  Sławek Ehlert|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  auth forms   | Triage Stage:  Accepted
  UserCreationForm UserChangeForm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sławek Ehlert):

 I'd like to submit a patch for that, but currently I was focusing more on
 solving #29467 first.

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

Re: [Django] #29501: Add support for ./manage.py dbshell -c SQL

2018-06-18 Thread Django 
#29501: Add support for ./manage.py dbshell -c SQL
-+-
 Reporter:  Artem Skoretskiy |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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 Carlton Gibson):

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


Comment:

 This seems reasonable, at first glance at least. The trick will be to pass
 the command to each of the backend clients correctly, but there's no
 reason that's not possible right? Accepting on that basis. A PR is very
 welcome.

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

Re: [Django] #28808: Allow customizing the fallback language

2018-06-18 Thread Django 
#28808: Allow customizing the fallback language
-+-
 Reporter:  Denis Anuschewski|Owner:  Claude
 |  Paroz
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  translation, | Triage Stage:
  internationalization, request  |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 I'm going to close this as a duplicate of #28636. Better to keep all the
 discussion in the one place there.

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

Re: [Django] #29502: AutocompleteJsonView doesn't work if user has "view" but not "change"

2018-06-18 Thread Django 
#29502: AutocompleteJsonView doesn't work if user has "view" but not "change"
-+-
 Reporter:  Matthew Frazier  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  nobody => Carlton Gibson
 * status:  new => assigned
 * has_patch:  0 => 1


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

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

Re: [Django] #29502: AutocompleteJsonView doesn't work if user has "view" but not "change"

2018-06-18 Thread Django 
#29502: AutocompleteJsonView doesn't work if user has "view" but not "change"
-+
 Reporter:  Matthew Frazier  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Carlton Gibson):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 OK, yes. Thanks for the report.

 This should probably be weakened to `view` or `change`. (Although,
 `change` currently implies `view`.)

 It might be worth an addition to the `autocomplete_fields` docs, noting
 that the permission to the related object is required.
 (There's a slight inconsistency in that no permission to the related model
 is needed if you don't use autocomplete.)

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

Re: [Django] #29485: Testing with Oracle in AWS RDS (oracle managed files)

2018-06-18 Thread Django 
#29485: Testing with Oracle in AWS RDS (oracle managed files)
-+-
 Reporter:  Vackar Afzal |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  oracle, testing, | Triage Stage:
  OMF, AWS, RDS  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 As it stands this is a usage question, which needs to be referred to an
 appropriate channel (Django Users, StackOverflow, etc).

 It's not clear how this is an **issue** for Django. What's the Django code
 that causes the offending SQL to be generated? If you can give us that
 then we can assess whether there's something that needs to be addressed
 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/069.ef0554ba3f8bf6cd51b013403597a8e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.