date:20150319

Re: [Django] #24508: F() object operations do not correcly reflect with annotate

2015-03-19 Thread Django

#24508: F() object operations do not correcly reflect with annotate
-+-
 Reporter:  mijamo   |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8rc1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  F()  | 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 jarshwah):

 * owner:  nobody => jarshwah
 * status:  new => assigned
 * has_patch:  0 => 1
 * stage:  Unreviewed => Ready for checkin


Comment:

 Turned out this wasn't so difficult to fix. I've opened a PR
 https://github.com/django/django/pull/4352

 I can't see there being in compatibility concerns. The behaviour is now
 inline with `filter(a=2+F('b')`.

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

[Django] #24509: Allow Expressions when saving new models

2015-03-19 Thread Django

#24509: Allow Expressions when saving new models
--+
Reporter: AlexHill | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) |Version: master
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
Opening a ticket after discussion on IRC with Josh.

You can use `Expression` when updating models, but it would also be useful
to be able to use them when creating models, particularly in order to
apply database functions to newly-inserted values.

My specific use case for this is a PostgreSQL `TSVectorField`, where
instead of just inserting a value, I want to insert
`strip(to_tsvector(, unaccent()))`. Ideally, I would be
able to define these all as `Func`s and insert an `Expression`.

I propose to fix this by making `SQLInsertCompiler` check for
`resolve_expressions` and `as_sql`, as `SQLUpdateCompiler` does.

Alex

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

Re: [Django] #24508: F() object operations do not correcly reflect with annotate

2015-03-19 Thread Django

#24508: F() object operations do not correcly reflect with annotate
-+-
 Reporter:  mijamo   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8rc1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  F()  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 Part of this problem will be solved by
 https://github.com/django/django/pull/4349

 {{{
 SomeModel.objects.all().annotate(computed = ExpressionWrapper(None +
 F('some_field'), output_field = FloatField()))
 }}}

 Where `ExpressionWrapper` replaces your previous (and incorrectly
 documented) `Expression`.

 The second part, where you get different results depending on which node
 is left or right could possibly be fixed, but we may not be able to if it
 results in backwards compatibility problems.

 What is the field type of `some_field` in your example? An integer or
 float?

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

Re: [Django] #24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN

2015-03-19 Thread Django

#24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN
--+
 Reporter:  mattrobenolt  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  CSRF  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  csrf  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by streeter):

 * cc: django@… (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.4863b7aec285e70dca0f865677718ee6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24085: @login_required decorator redirects to a locale specific URL when using i18n_patterns

2015-03-19 Thread Django

#24085: @login_required decorator redirects to a locale specific URL when using
i18n_patterns
-+-
 Reporter:  thedrow  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  authentication i18n  | Triage Stage:
  login_required |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Please reopen if Claude's suggestion doesn't work.

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

Re: [Django] #24347: parameter 'widget' of BoundField.as_widget is ignored

2015-03-19 Thread Django

#24347: parameter 'widget' of BoundField.as_widget is ignored
-+-
 Reporter:  srkunze  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8beta1
 Severity:  Normal   |   Resolution:
 Keywords:  BoundField,  | Triage Stage:
  as_widget  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by timgraham):

 I think datetimes maybe complicating the issue. It seems like at least one
 of the issues is that for the following form:
 {{{
 class MyForm(forms.Form):
 foo = forms.IntegerField(initial=1, show_hidden_initial=True)

 form = MyForm({'foo': 5})
 }}}
 You expect the hidden input to be rendered with "1" instead of "5".
 {{{
 Foo:
 
 
 }}}
 Is that correct?

 By the way, I tried looking at your tests, but they didn't pass even when
 I uncommented "# uncomment to see changes with correctly formatted hidden-
 initial" -- not sure if that was intended or not?

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

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

Re: [Django] #24285: get_admin_log template tag doesn't work without for_user parameter

2015-03-19 Thread Django

#24285: get_admin_log template tag doesn't work without for_user parameter
-+-
 Reporter:  yairchu  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yairchu):

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

Re: [Django] #24500: Django runtests - 3 tests fail on windows due to encoding troubles

2015-03-19 Thread Django

#24500: Django runtests - 3 tests fail on windows due to encoding troubles
--+
 Reporter:  pakal |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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 pakal):

 Hum I tried different ways of catching decoding exceptions to provide a
 fallback, but it broke more tests elsewhere

 In the end, I just special-cased the "xgettest -V" call, which doesn't
 respect utf-8 encoding, and let the rest encode/decode as is (CF attached
 patch). Tested on windows 7, on latest python2 and python3 interpreters.

 In the patch I also added some encoding details to an error message (to
 help, since encoding troubles are recurring), but maybe it's too much
 information, I don't know.

 I'm amazed, though, that xgettext, which is supposed to deal with
 internationalization, doesn't provide parameters to controls its output
 encoding, doesn't say anything about it in its docs (afaik), and has
 different stdout encodings in its different commands...

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

Re: [Django] #24500: Django runtests - 3 tests fail on windows due to encoding troubles

2015-03-19 Thread Django

#24500: Django runtests - 3 tests fail on windows due to encoding troubles
--+
 Reporter:  pakal |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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
--+
Changes (by pakal):

 * Attachment "0001-Fix-gettext-tools-output-encoding-troubles.patch"
 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/063.167bafffb6ef1577d05c8a18650729ec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24508: F() object operations do not correcly reflect with annotate (was: F() object operations correcly reflecting with annotate)

2015-03-19 Thread Django

#24508: F() object operations do not correcly reflect with annotate
-+-
 Reporter:  mijamo   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8rc1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  F()  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mijamo):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0


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

[Django] #24508: F() object operations correcly reflecting with annotate

2015-03-19 Thread Django

#24508: F() object operations correcly reflecting with annotate
--+
 Reporter:  mijamo|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8rc1
 Severity:  Release blocker   |   Keywords:  F()
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hello,

 This ticket is related to the 1.8 new feature of using various F
 operations within an annotation.

 I have spotted 2 problems so far :
 1) F('field') * 2 apparently isn't the same as 2 * F('field')
 Description of the problem :

 {{{
 SomeModel.objects.all().annotate(computed = F('some_field') * 2)
 Works as expected

 SomeModel.objects.all().annotate(computed = 2 * F('some_field'))
 E: django.core.exceptions.FieldError: Expression contains mixed types. You
 must set output_field

 SomeModel.objects.all().annotate(computed = Expression(2 *
 F('some_field'), output_field = FloatField()))
 E : TypeError: __init__() got multiple values for argument 'output_field'
 }}}
 The last exception, about init, is the most problematic as it doesn't
 state anything about where is the problem (no info in the traceback)

 2) When  a F object is added to None, it causes a conflict
 Description of the problem :

 {{{
 SomeModel.objects.all().annotate(computed = F('some_field') + None)
 Works as expected

 SomeModel.objects.all().annotate(computed = None + F('some_field'))
 E: django.core.exceptions.FieldError: Expression contains mixed types. You
 must set output_field

 SomeModel.objects.all().annotate(computed = Expression(None +
 F('some_field'), output_field = FloatField()))
 E : TypeError: __init__() got multiple values for argument 'output_field'
 }}}

 You might wonder why there would be a None in the construction. For me it
 is because I am building the object in a for, so I have something like
 this :

 {{{
 annotation = None
 for field in fields_to_be_added:
 annotation += F(field)
 SomeModel.objects.all().annotate(annotation)
 }}}

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

Re: [Django] #24469: Revisit strategy of escaping Django's form elements in non-Django forms

2015-03-19 Thread Django

#24469: Revisit strategy of escaping Django's form elements in non-Django forms
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Accepted
  escape template jinja2 |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MoritzS):

 * cc: MoritzS (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.0b6ed90711a2dff1e110c5eda5018176%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24470: Serialization of base classes is not customizable for migrations

2015-03-19 Thread Django

#24470: Serialization of base classes is not customizable for migrations
-+
 Reporter:  rockymeza|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  1.7
 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 carljm):

 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 On the one hand, I think there is definitely a point where we just have to
 say "auto-generated migrations are on a best-effort basis, if you're doing
 complex things then you will probably have to edit the auto-generated
 migrations by hand."

 On the other hand, this specific feature request looks relatively elegant
 and generic, and I think would probably find use cases beyond this
 specific situation , so provided the implementation isn't too complex in
 practice I think it's reasonable.

 I've marked accepted, but if anyone with more migrations experience thinks
 there are serious problems here, feel free to reverse that!

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

Re: [Django] #24472: Define internal types explicitly for related fields

2015-03-19 Thread Django

#24472: Define internal types explicitly for related fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I guess this is consistent with the other built-in fields. Could you add
 regression tests?

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

Re: [Django] #24506: Proxying User model creates an invalid migration

2015-03-19 Thread Django

#24506: Proxying User model creates an invalid migration
-+-
 Reporter:  tinloaf  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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 timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Could you provide a minimal project that we could download to reproduce
 the issue? Did you test with Django 1.8?

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

Re: [Django] #24507: Add the possibility to create only one index on CharField

2015-03-19 Thread Django

#24507: Add the possibility to create only one index on CharField
-+-
 Reporter:  rodo |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  index| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rodo):

 I'm compiling some stats on indexes usage on our production server. After
 that I'll open a discusion on the Devml, 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/062.e7970a6a8ba2d61b7bee8bda26780ba6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24507: Add the possibility to create only one index on CharField

2015-03-19 Thread Django

#24507: Add the possibility to create only one index on CharField
-+-
 Reporter:  rodo |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  index| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I'm not a DBA, so I don't have any performance numbers. Maybe you could
 provide some. If so, could you open a discussion on the
 DevelopersMailingList to ask to see if anyone thinks such an option to
 disable those indexes is worthwhile? We can reopen one of the tickets if
 so.

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

Re: [Django] #24502: Using non model fields in an admin ModelForm does not work if the field is listed in fieldsets (and fields I think)

2015-03-19 Thread Django

#24502: Using non model fields in an admin ModelForm does not work if the field
is
listed in fieldsets (and fields I think)
---+--
Reporter: bdauvergne |Owner: nobody
Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 1.7
Severity: Normal | Resolution: needsinfo
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 timgraham):

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

Comment:

Your example is too complicated for me to debug and reproduce (for example
`attribute.contribute_to_form` isn't part of Django), and there's evidence
that referring to non-model fields does work, see

https://github.com/django/django/commit/dc3d2ac98c1bcfad74d3e9523caf07e7e9fb15aa
for tests. Please reopen if you can simplify your example so it can be
reproduced (ideally, as a test for Django's test suite that passes on 1.5
and fails in 1.7). If you can
[https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
tickets/#bisecting-a-regression bisect the regression] all the better.

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

Re: [Django] #24507: Add the possibility to create only one index on CharField

2015-03-19 Thread Django

#24507: Add the possibility to create only one index on CharField
-+-
 Reporter:  rodo |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  index| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rodo):

 Sorry for the duplicate.
 As a DBA point of view it's a little bit strange to maintain an index that
 is never used, it's consumming IO on write operation and disk space. If I
 look at our indexes statistics a part of them are never used, and it's
 always these additionnal indexes.
 I'm agree that is not difficult to remove them, but why createing them if
 it's for removing them just after ?

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

Re: [Django] #24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN

2015-03-19 Thread Django

#24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN
--+
 Reporter:  mattrobenolt  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  CSRF  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  csrf  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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

Re: [Django] #24507: Add the possibility to create only one index on CharField

2015-03-19 Thread Django

#24507: Add the possibility to create only one index on CharField
-+-
 Reporter:  rodo |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  index| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Duplicate of #24088. Do you have any data to substantiate the performance
 motive? I don't think it would be difficult to use a `RunSQL` migration to
 manually drop the index you don't want. This might be easier than
 implementing a flag that only has specialized uses.

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

Re: [Django] #24483: keepdb migrations break choices as generators

2015-03-19 Thread Django

#24483: keepdb migrations break choices as generators
-+-
 Reporter:  davidszotten |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  migrations test  | Triage Stage:  Accepted
  keepdb |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  assigned => new
 * needs_better_patch:  0 => 1
 * owner:  timgraham =>


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

Re: [Django] #24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN

2015-03-19 Thread Django

#24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN
--+--
 Reporter:  mattrobenolt  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  CSRF  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  csrf  | Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by mattrobenolt):

 I've opened a discussion on the mailing list as suggested by timgraham
 since this is related to security: https://groups.google.com/forum/#!topic
 /django-developers/tEEw02RhV0M

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

Re: [Django] #14645: Exclude query with multiple conditions for the same multi-value relation not correct

2015-03-19 Thread Django

#14645: Exclude query with multiple conditions for the same multi-value relation
not correct
-+-
 Reporter:  Ben Buchwald |Owner:  nobody
  |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  exclude manytomany   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by seddonym):

 I've been looking at correcting the documentation and have just realised
 that one of the statements in the original bug report is wrong: "This
 works correctly for filter() but for exclude() it is operating the same as
 if it was 2 separate exclude() calls."

 Actually, the behaviour is a bit different:

 `Song.objects.exclude(release_set__format='cd',release_set__released=1)`
 would exclude Songs that have ''both'' CD releases ''and'' releases that
 have gone out.

 
`Song.objects.exclude(release_set__format='cd').exclude(release_set__released=1)`,
 on the other hand, would exclude Songs that have ''either'' CD releases
 ''or'' releases that have gone out.

 I've made a gist that sums this up in the form of tests:
 https://gist.github.com/seddonym/84407891a11389419c14

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

[Django] #24507: Add the possibility to create only one index on CharField

2015-03-19 Thread Django

#24507: Add the possibility to create only one index on CharField
--+
 Reporter:  rodo  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:  index
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 As describe in the doc adding a db_index=True on CharField automatically
 create 2 indexes on some backends to speedup LIKE queries. But in some
 case the second index is not necessary when you know you always lookup on
 the entire string.
 Having a new option too only create simple index may be a good
 improvement, actually on high volume database we need to maintain our
 indexes outside of Django cause of that.

 Regards

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

Re: [Django] #24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN

2015-03-19 Thread Django

#24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN
--+--
 Reporter:  mattrobenolt  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  CSRF  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  csrf  | Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Could you provide a reference for "we want to be a bit more strict ..."?
 For example, is this part of an RFC or something that other frameworks
 implement?

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

Re: [Django] #24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN

2015-03-19 Thread Django

#24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN
--+--
 Reporter:  mattrobenolt  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  CSRF  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  csrf  | Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by carljm):

 Tim, the "we want to be more strict" is something Django already
 implements (checking `REFERER` against the request host on an HTTPS
 request). Matt's feature request is for that check to be against
 `CSRF_COOKIE_DOMAIN` rather than the request host, to allow for cross-
 subdomain requests. I think this is reasonable, and probably the way it
 should have worked from the beginning.

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

Re: [Django] #24496: Check CSRF Referer against CSRF_COOKIE_DOMAIN

2015-03-19 Thread Django

Comment (by mattrobenolt):

I think the comment in this file explains it best:
{{{
# Suppose user visits http://example.com/
# An active network attacker (man-in-the-middle, MITM) sends a
# POST form that targets https://example.com/detonate-bomb/ and
# submits it via JavaScript.
#
# The attacker will need to provide a CSRF cookie and token, but
# that's no problem for a MITM and the session-independent
# nonce we're using. So the MITM can circumvent the CSRF
# protection. This is true for any HTTP connection, but anyone
# using HTTPS expects better! For this reason, for
# https://example.com/ we need additional protection that treats
# http://example.com/ as completely untrusted. Under HTTPS,
# Barth et al. found that the Referer header is missing for
# same-domain requests in only about 0.2% of cases or less, so
# we can use strict Referer checking.
}}}

https://github.com/django/django/blob/668d53cd125175eb708cc0af143f47b42cd42153/django/middleware/csrf.py#L135-L149

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

Re: [Django] #15667: Implement template-based widget rendering

2015-03-19 Thread Django

#15667: Implement template-based widget rendering
+
 Reporter:  brutasse|Owner:  brutasse
 Type:  New feature |   Status:  new
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by timgraham):

 I haven't read through all the history of this ticket, but I guess it
 might work something like this: by default, widgets are rendered with
 Django templates. If you have jinja2 configured in `TEMPLATES`, then
 widgets can be rendered with it. The main point is not to add jinja2 as a
 requirement for 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/066.35d789745dc30939f424a451fb0ae299%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24500: Django runtests - 3 tests fail on windows due to encoding troubles

2015-03-19 Thread Django

#24500: Django runtests - 3 tests fail on windows due to encoding troubles
--+
 Reporter:  pakal |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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 claudep):

 Yes, let's fix this at `gettext_popen_wrapper` level for now.

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

[Django] #24506: Proxying User model creates an invalid migration

2015-03-19 Thread Django

#24506: Proxying User model creates an invalid migration
--+
 Reporter:  tinloaf   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hi!

 I have created a proxy model for the User model like this (in
 core.models):

 {{{
 from django.contrib.auth.models import User as OriginalUser

 class User(OriginalUser):
 objects = UserManager()
 all_objects = AllUserManager()

 class Meta:
 proxy = True
 [...]
 }}}

 I then changed some ForeignKeys that have been pointing to the original
 User to my proxy. Now makemigrations creates a migration that looks like
 this:

 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models, migrations


 class Migration(migrations.Migration):

 dependencies = [
 ('finance', '0011_auto_20141126_1447'),
 ]

 operations = [
 migrations.AlterField(
 model_name='financialdata',
 name='user',
 field=models.OneToOneField(to='core.User'),
 preserve_default=True,
 ),
 migrations.AlterField(
 model_name='mandate',
 name='user',
 field=models.ForeignKey(to='core.User'),
 preserve_default=True,
 ),
 migrations.AlterField(
 model_name='userrate',
 name='user',
 field=models.ForeignKey(to='core.User'),
 preserve_default=True,
 ),
 ]
 }}}


 Which looks OK so far. If I try to run this migration, it fails like this:

 {{{
 (venv)tinloaf@janeway alumnet % python manage.py migrate
 Operations to perform:
   Synchronize unmigrated apps: gis, bootstrap3, dajaxice,
 autocomplete_light
   Apply all migrations: sessions, ml, auth, admin, local, finance, core,
 contenttypes
 Synchronizing apps without migrations:
   Creating tables...
   Installing custom SQL...
   Installing indexes...
 Running migrations:
   Applying finance.0012_auto_20150319_1316...Traceback (most recent call
 last):
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/apps/registry.py", line 148, in get_app_config
 return self.app_configs[app_label]
 KeyError: 'core'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/db/migrations/state.py", line 84, in render
 model = self.apps.get_model(lookup_model[0], lookup_model[1])
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/apps/registry.py", line 202, in get_model
 return self.get_app_config(app_label).get_model(model_name.lower())
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/apps/registry.py", line 150, in get_app_config
 raise LookupError("No installed app with label '%s'." % app_label)
 LookupError: No installed app with label 'core'.

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/core/management/__init__.py", line 385, in
 execute_from_command_line
 utility.execute()
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/core/management/__init__.py", line 377, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/core/management/base.py", line 288, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/core/management/base.py", line 338, in execute
 output = self.handle(*args, **options)
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/core/management/commands/migrate.py", line 161, in handle
 executor.migrate(targets, plan, fake=options.get("fake", False))
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/db/migrations/executor.py", line 68, in migrate
 self.apply_migration(migration, fake=fake)
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/django/db/migrations/executor.py", line 96, in apply_migration
 if self.detect_soft_applied(migration):
   File "/mnt/data/home/tinloaf/src/alumnet/venv/lib/python3.3/site-
 packages/dja

Re: [Django] #24417: Add ModelAdmin.get_list_select_related()

2015-03-19 Thread Django

#24417: Add ModelAdmin.get_list_select_related()
-+-
 Reporter:  eskhool  |Owner:  gannetson
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 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:"35b3158d52a5fe51d3b52aec1109a30a73c5abe9" 35b3158]:
 {{{
 #!CommitTicketReference repository=""
 revision="35b3158d52a5fe51d3b52aec1109a30a73c5abe9"
 Fixed #24417 -- Added ModelAdmin.get_list_select_related()
 }}}

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

Re: [Django] #24505: Multiple ManyToManyFields to same "to" model with related_name set to '+' mix up badly

2015-03-19 Thread Django

#24505: Multiple ManyToManyFields to same "to" model with related_name set to 
'+'
mix up badly
-+-
 Reporter:  gergelypolonkai  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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 bmispelon):

 * Attachment "issue24505_testcase.diff" added.

 Reproduction testcase

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

Re: [Django] #24505: Multiple ManyToManyFields to same "to" model with related_name set to '+' mix up badly

2015-03-19 Thread Django

#24505: Multiple ManyToManyFields to same "to" model with related_name set to 
'+'
mix up badly
-+-
 Reporter:  gergelypolonkai  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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 bmispelon):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 I can confirm that something strange is going on.
 I'm attaching a testcase patch to reproduce the issue.

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

Re: [Django] #24500: Django runtests - 3 tests fail on windows due to encoding troubles

2015-03-19 Thread Django

#24500: Django runtests - 3 tests fail on windows due to encoding troubles
--+
 Reporter:  pakal |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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
--+
Changes (by timgraham):

 * cc: claudep (added)
 * version:  1.7 => master
 * stage:  Unreviewed => Accepted


Comment:

 Claude, could you advise on the best implementation?

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

[Django] #24505: Multiple ManyToManyFields to same "to" model with related_name set to '+' mix up badly

2015-03-19 Thread Django

#24505: Multiple ManyToManyFields to same "to" model with related_name set to 
'+'
mix up badly
--+
 Reporter:  gergelypolonkai   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I have a model, ProductField, which has a fillable_by and an approvable_by
 field. Both fields are defined as

 {{{
 ManyToManyField(to=Group, related_name='+')
 }}}

 Now when I add a group to fillable_by and another one to approvable_by,
 the fillable_by gets overridden by approvable_by. I cannot find anything
 related to this in the documentation, but it seems a pretty bad behaviour
 to me.

 The problem still exists in latest 1.7.7 version.

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

Re: [Django] #24500: Django runtests - 3 tests fail on windows due to encoding troubles

2015-03-19 Thread Django

Comment (by pakal):

Thanks

I guess that's why -> your "xgettext -V" output is all-english, so ascii-
compatible, hence that it be treated as utf8, a windows codepage, or
ascii, is the same for django, and no error occurs. But for non-ascii
outputs like my french "xgettext -V", decoding breaks because the output
of Popen is cp1252 with accentuated letters, not utf8.

So we should replace "stdout = stdout.decode('utf-8')" by a proper
operation with DEFAULT_LOCALE_ENCODING. I don't know what's best -
normalize everything at popen_wrapper level (but it might break lots of
code that rely on raw DEFAULT_LOCALE_ENCODING bytes), or handle stuffs
properly in the new gettext_popen_wrapper() ? The latter i guess ?

Note that django1.7 didn't have these things, so no tests broke.

When was know the way to go, I can draft a patch to solve that non-ascii-
encoding buglet.

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

Re: [Django] #11365: django.db.models.fields.EmailField max_length should be 254

2015-03-19 Thread Django

#11365: django.db.models.fields.EmailField max_length should be 254
-+-
 Reporter:  shellsage|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  email field  | Triage Stage:
  max_length |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * resolution:  wontfix => fixed


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

Re: [Django] #15180: reverse doesn't check default_args

2015-03-19 Thread Django

#15180: reverse doesn't check default_args
-+-
 Reporter:  olaf |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.3-beta
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  resolve  | Triage Stage:  Accepted
  default_args   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bpeschier):

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


Comment:

 This was fixed in #13154

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

39 matches

Mail list logo