Re: [Django] #30071: Obscure error message when no default db provided

2019-01-01 Thread Django 
#30071: Obscure error message when no default db provided
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (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):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #30071: Obscure error message when no default db provided

2019-01-01 Thread Django 
#30071: Obscure error message when no default db provided
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  Uncategorized|   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (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
-+-
Description changed by Benjy Weinberger:

Old description:

> In `ConnectionHandler`, the explicit check for the `DEFAULT_DB_ALIAS`
> key in the databases dict comes only after an attempt to lookup that key.
>
> If you have at least one non-default db, but no default db, no dummy
> default will be created for you, and the `DEFAULT_DB_ALIAS` key will
> not be present. Under these circumstances, referencing the `databases`
> property directly will give a `KeyError` instead of the intended
> `ImproperlyConfigured` error.
>
> Worse, if you try to access a non-default db, `ensure_defaults` will
> catch that `KeyError` but misinterpret it as being for the non-default
> db name (which does in fact exist in the dict).
>
> This change moves the explicit check before the attempt to use the key,
> so that no `KeyError` is ever raised for `DEFAULT_DB_ALIAS`. It adds
> a test for this case, and also adds a test for the case where the
> default db is explicitly set to an empty dict.

New description:

 In `ConnectionHandler`, the explicit check for the `DEFAULT_DB_ALIAS`
 key in the databases dict comes only after an attempt to lookup that key.

 If you have at least one non-default db, but no default db, no dummy
 default will be created for you, and the `DEFAULT_DB_ALIAS` key will
 not be present. Under these circumstances, referencing the `databases`
 property directly will give a `KeyError` instead of the intended
 `ImproperlyConfigured` error.

 Worse, if you try to access a non-default db, `ensure_defaults` will
 catch that `KeyError` but misinterpret it as being for the non-default
 db name (which does in fact exist in the dict).

--

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

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

Re: [Django] #30071: Obscure error message when no default db provided

2019-01-01 Thread Django 
#30071: Obscure error message when no default db provided
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  Uncategorized|   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (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 Benjy Weinberger):

 Ticket branch here: https://github.com/benjyw/django/tree/ticket_30071

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

Re: [Django] #30071: Obscure error message when no default db provided

2019-01-01 Thread Django 
#30071: Obscure error message when no default db provided
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  Uncategorized|   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (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 Benjy Weinberger):

 * owner:  nobody => Benjy Weinberger
 * status:  new => assigned
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 See https://github.com/django/django/pull/10813

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

[Django] #30071: Obscure error message when no default db provided

2019-01-01 Thread Django 
#30071: Obscure error message when no default db provided
+
   Reporter:  Benjy Weinberger  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Uncategorized |Version:  2.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In `ConnectionHandler`, the explicit check for the `DEFAULT_DB_ALIAS`
 key in the databases dict comes only after an attempt to lookup that key.

 If you have at least one non-default db, but no default db, no dummy
 default will be created for you, and the `DEFAULT_DB_ALIAS` key will
 not be present. Under these circumstances, referencing the `databases`
 property directly will give a `KeyError` instead of the intended
 `ImproperlyConfigured` error.

 Worse, if you try to access a non-default db, `ensure_defaults` will
 catch that `KeyError` but misinterpret it as being for the non-default
 db name (which does in fact exist in the dict).

 This change moves the explicit check before the attempt to use the key,
 so that no `KeyError` is ever raised for `DEFAULT_DB_ALIAS`. It adds
 a test for this case, and also adds a test for the case where the
 default db is explicitly set to an empty dict.

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

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

Re: [Django] #17522: ModelAdmin.ordering validation too strict

2019-01-01 Thread Django 
#17522: ModelAdmin.ordering validation too strict
-+-
 Reporter:  Sebastian Goll   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, validation,   | Triage Stage:  Accepted
  ordering, strict   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Javier Abadia Miranda):

 Replying to [comment:7 Simon Charette]:
 >
 > I have to say I'm not convinced this needs to be fixed anyhow. Why
 wouldn't the following be acceptable?
 >
 Because the `ordering` tuple purpose is to specify the **default**
 ordering that the user can change afterwards by clicking on column
 headers. If I'm forced to embed the ordering in the `get_queryset()`
 method, then:
 1) I am forced to implement a get_queryset in situations where I don't
 need to do it, because defining additional columns via properties with
 `get_` methods works fine and it's convenient and consistent with
 `list_display`
 2) The user can't change the ordering afterwards, or I need to put logic
 inside `get_queryset()` to include the sorting or not depending on what
 the user does.
 The funny thing is that everything works as expected, if you can work
 around the too strict (in my opinion) validation.

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

Re: [Django] #29981: "Please correct the error below." (with no errors displayed) when changing an inline that has a one-to-one relation to the parent that uses to_field

2019-01-01 Thread Django 
#29981: "Please correct the error below." (with no errors displayed) when 
changing
an inline that has a one-to-one relation to the parent that uses to_field
---+-
 Reporter:  Bernie |Owner:  Patrik Sletmo
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   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:"14e2b1b065085c1d2d3e94ebaeefe25e12595a00" 14e2b1b0]:
 {{{
 #!CommitTicketReference repository=""
 revision="14e2b1b065085c1d2d3e94ebaeefe25e12595a00"
 Fixed #29981 -- Fixed inline formsets with a OnetoOneField primary key
 that uses to_field.
 }}}

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

[Django] #30070: Content spoofing possiblity in default 404 page

2019-01-01 Thread Django 
#30070: Content spoofing possiblity in default 404 page
---+
   Reporter:  tasn |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (Other) |Version:  1.11
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+
 A maliciously crafted URL can be reflected back to the user so that the
 user sees a 404 page with the attacker's content that may be interpreted
 as  originating from the trusted site.

 [https://github.com/django/django/pull/10809 PR] with details.

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

Re: [Django] #30050: InlineModelAdmin.has_change_permission() incorrectly called with non-None obj during add

2019-01-01 Thread Django 
#30050: InlineModelAdmin.has_change_permission() incorrectly called with 
non-None
obj during add
-+
 Reporter:  Andrea Angelini  |Owner:  nobody
 Type:  Bug  |   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:"4e4b9521236c9238fc26a77b22acf75218702c54" 4e4b9521]:
 {{{
 #!CommitTicketReference repository=""
 revision="4e4b9521236c9238fc26a77b22acf75218702c54"
 [2.1.x] Fixed #30050 -- Fixed InlineModelAdmin.has_change_permission()
 called with non-None obj during add.

 Thanks andreage for the report and suggested fix.

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

Re: [Django] #30050: InlineModelAdmin.has_change_permission() incorrectly called with non-None obj during add

2019-01-01 Thread Django 
#30050: InlineModelAdmin.has_change_permission() incorrectly called with 
non-None
obj during add
-+
 Reporter:  Andrea Angelini  |Owner:  nobody
 Type:  Bug  |   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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"02c07be95c47efaab9da7422c33ee76142f11336" 02c07be9]:
 {{{
 #!CommitTicketReference repository=""
 revision="02c07be95c47efaab9da7422c33ee76142f11336"
 Fixed #30050 -- Fixed InlineModelAdmin.has_change_permission() called with
 non-None obj during add.

 Thanks andreage for the report and suggested fix.
 }}}

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

Re: [Django] #30060: Improve extensibility of schema migration for custom backends for new Index/Check/Unique and other constraints

2019-01-01 Thread Django 
#30060: Improve extensibility of schema migration for custom backends for new
Index/Check/Unique and other constraints
-+-
 Reporter:  Pavel Tyslacki   |Owner:  nobody
 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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"0123b67f6b8304a5c32a0fe98f97ae506977454b" 0123b67]:
 {{{
 #!CommitTicketReference repository=""
 revision="0123b67f6b8304a5c32a0fe98f97ae506977454b"
 Fixed #30060 -- Moved SQL generation for indexes and constraints to
 SchemaEditor.
 }}}

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