date:20160831

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

2016-08-31 Thread Django

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |Owner:  andkon
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by jdufresne):

 * needs_tests:  1 => 0


Comment:

 A test has been added to the PR above.

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

Re: [Django] #27039: ModelFields with 'default' value set and 'required'=False in form does not use default value

2016-08-31 Thread Django

#27039: ModelFields with 'default' value set and 'required'=False in form does 
not
use default value
-+-
 Reporter:  devbis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  default non- | Triage Stage:  Accepted
  required modelform |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by AlexHill):

 The issue was that when a field on a prefixed form had a default, its
 (unprefixed) name wasn't found in form.data, so the instance would always
 be populated with the default value. Fixed with `form.add_prefix()`.

 PR at https://github.com/django/django/pull/7195

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

Re: [Django] #27159: Pickling query from queryset causes unintended queryset evaluation

2016-08-31 Thread Django

#27159: Pickling query from queryset causes unintended queryset evaluation
-+-
 Reporter:  jtiai|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (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 jtiai):

 I added crude, initial test to {{{queryset_pickle}}} to
 https://github.com/jtiai/django/tree/issue_27159

 Interesting enough, if you check pickled output it's clearly visible that
 it contains all instances from Parent-model.

 If you compare query output as a string both are equal.

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

[Django] #27164: Multiple problems with multiple database docs for 1.8 and possibly other versions

2016-08-31 Thread Django

#27164: Multiple problems with multiple database docs for 1.8 and possibly other
versions
--+
Reporter: michaelcoconnor | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) |Version: 1.8
Severity: Normal| Keywords: multiple
| databases docs
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 1 | UI/UX: 0
--+
I am running (1, 8, 7, 'final', 0); this ticket pertains specifically to
https://docs.djangoproject.com/en/1.8/topics/db/multi-db/ and to the code
snippets in it.

First, in the discussion of Database Routers and in the code for the
router AuthRouter(), the declaration of the method controlling migrations
is allow_migrate(db, app_label, model_name=None, *hints), which is stated
to be new in 1.8, the 1.7 version having been deprecated. However, in
reality in (1, 8, 7, 'final', 0) only the 1.7 version of this method
works.

Secondly, the AuthRouter() code is designed to only permit apps with
app_label =='auth' to be migrated to the database of the same name--- all
other apps spill over, via the PrimaryReplicaRouter(), to one of the other
databases and are migrated there. However, at the bottom of the page it
clearly states that "auth models — User, Group and Permission — are linked
together and linked to ContentType, so they must be stored in the same
database as ContentType". Thus, unless django_content_type is somehow
naturally given an app_label of 'auth', it would appear that this is a
contradiction.

The third matter is the 'default': {} recommendation. With several tries I
only get an error message to the effect that {} can't be empty.

In all it appears that the given code was never tested.

I can recommend a simple example, for which the painful "Example purposes
only!" disclaimer should be unnecessary. I am now happy with one database
being 'default':{...}, with the name of the database being also 'default'.
For that one I provide no router at all. For two others I use an
AuthRouter()-type that rigidly connects each of two apps of my own to a
corresponding database of the two. And so only the two routers for the two
databases are in the settings.py router chain.

With that, I have thrown away the migrations folders and checked to be
sure that the makemigrations-migrate sequence does the correct migrations.
It does--- the auth models and django_site, django_session,
django_migrations and django_content_type all end up in the 'default'
database; my models end up in the others.

Finally, "admin depends on auth, so their models must be in the same
database as auth" should be corrected (e.g. "its models").

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

Re: [Django] #27163: Unable to specify multiple pythonpath in django-admin

2016-08-31 Thread Django

#27163: Unable to specify multiple pythonpath in django-admin
-+-
 Reporter:  AlJohri  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by AlJohri):

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


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

Re: [Django] #27163: Unable to specify multiple pythonpath in django-admin

2016-08-31 Thread Django

Comment (by AlJohri):

Yeah, that makes sense.

It was a pretty weird reason to need the parameter. I was sourcing a bash
script that set my `PYTHONPATH` and other environment variables when
developing locally. I tried doing the same thing when moving to docker via
`docker-compose run myapp source myscript && django-admin dbshell
--settings=myapp.settings` but apparently you can't do that. So my next
option was `docker-compose run myapp django-admin dbshell
--settings=myapp.settings --pythonpath="lib:admin"`. After submitting that
PR, I realized I could just set `PYTHONPATH` as an environment variable in
docker-compose like a normal person and that solved my issue.

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

Re: [Django] #24112: Inconsistency in TestCase.assertInHTML

2016-08-31 Thread Django

#24112: Inconsistency in TestCase.assertInHTML
---+
 Reporter:  plumdog|Owner:  adamzap
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 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:"ca2ccf54ffa95cf001260b917dd267fda60e93d5" ca2ccf54]:
 {{{
 #!CommitTicketReference repository=""
 revision="ca2ccf54ffa95cf001260b917dd267fda60e93d5"
 Fixed #24112 -- Fixed assertInHTML()'s counting if needle has no root
 element.
 }}}

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

Re: [Django] #27143: SearchQuery is not combinable using more than one `&` or `|` operators

2016-08-31 Thread Django

#27143: SearchQuery is not combinable using more than one `&` or `|` operators
--+
 Reporter:  hixi  |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:  Search| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * version:  master => 1.10


Comment:

 [https://github.com/django/django/pull/7176 PR]. Please uncheck "Patch
 needs improvement" after you update it.

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

Re: [Django] #25181: Add a localdate() function to get date in a different time zone

2016-08-31 Thread Django

#25181: Add a localdate() function to get date in a different time zone
-+-
 Reporter:  timgraham|Owner:  kswiat
 Type:  New feature  |   Status:  closed
Component:  Utilities|  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 GitHub ):

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


Comment:

 In [changeset:"ff1e7b4eb43737bf2752197036663cee58922317" ff1e7b4e]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff1e7b4eb43737bf2752197036663cee58922317"
 Fixed #25181 -- Added localdate() function to get date in a different time
 zone.

 Thanks Konrad Świat for the original patch.
 }}}

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

Re: [Django] #27110: makemigrations shouldn't create `django_migrations` table in external databases

2016-08-31 Thread Django

#27110: makemigrations shouldn't create `django_migrations` table in external
databases
-+-
 Reporter:  direx|Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 There's a [https://github.com/django/django/pull/7194 new PR] which uses
 the database routers idea.

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

Re: [Django] #27162: Move CreateExtension to django.db.backends.postgresql

2016-08-31 Thread Django

#27162: Move CreateExtension to django.db.backends.postgresql
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 timgraham):

 I understand the purity behind the rationale, but the new import path
 (`django.db.backends.postgresql.migrations.operations.CreateExtension`)
 seems a bit unwieldy. I guess the pattern looks better for third-party
 backends that don't have "django.db.backends" in the import path. Also, I
 think this is the first time we would have users importing code directly
 from a database backend. I guess that's a more common pattern for third-
 party backends which may provide custom fields. It raises the question why
 we have `contrib.postres` instead of putting that in the backend though.

 Is it impossible to import from the current location without adding
 `contrib.postgres` to `INSTALLED_APPS`?

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

Re: [Django] #27161: TypedChoiceField fails to validate properly when used with ArrayField (was: TypedChoiceField validation bug)

2016-08-31 Thread Django

#27161: TypedChoiceField fails to validate properly when used with ArrayField
--+
 Reporter:  th13f |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  TypedChoiceField  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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


Comment:

 I observed one test failure with the patch:
 `test_typedchoicefield_special_coerce`.

 If it's possible to add a test that's not dependent on `contrib.postgres`,
 that would be ideal. Of course, we could add that test too.

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

Re: [Django] #27157: AdminForm may crash if model_admin argument is None (was: AdminForm model_admin cannot be None)

2016-08-31 Thread Django

* stage: Unreviewed => Accepted

Comment:

I guess, for example, we need to account for `model_admin=None` in a place
like

[https://github.com/django/django/blob/d8ef5b0e6501692b8b767ebccddc936f496d77e8/django/contrib/admin/helpers.py#L185
AdminReadonlyField]. It's not so clear to me why `model_admin` is an
optional argument (see bcd9482a2019158f4580c24cd50ee8bfae9b2739), perhaps
for backwards compatibility. A better resolution might be a deprecation
path toward making those arguments required unless there's argument
against it. In your case, if you using that formset for the admin, then a
possibility would be to declare the formset in
`ModelAdmin.get_changelist_formset()` so you can access to the
`ModelAdmin` class (`self`).

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

Re: [Django] #27151: FK index created two times on PostgreSQL if referenced table PK is varchar (was: FK index created two times if referenced table PK is varchar)

2016-08-31 Thread Django

#27151: FK index created two times on PostgreSQL if referenced table PK is 
varchar
-+
 Reporter:  kkujawinski  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 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):

 * stage:  Unreviewed => Accepted


Comment:

 I could reproduce at d8ef5b0e6501692b8b767ebccddc936f496d77e8.

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

Re: [Django] #27163: Unable to specify multiple pythonpath in django-admin

2016-08-31 Thread Django

#27163: Unable to specify multiple pythonpath in django-admin
-+-
 Reporter:  AlJohri  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I don't understand why the `--pythonpath` option was added in the first
 place (#357). Is there some reason `PYTHONPATH=$PYTHONPATH:...` doesn't
 work? Is it just more verbose? Regarding your use case, I'd like to
 encourage best practices and that doesn't really seem like a pattern to
 encourage.

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

[Django] #27163: Unable to specify multiple pythonpath in django-admin

2016-08-31 Thread Django

#27163: Unable to specify multiple pythonpath in django-admin
+
 Reporter:  AlJohri |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Core (Management commands)  |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  1   |  UI/UX:  0
+
 I am unable to specify multiple pythonpaths django-admin. This can either
 be colon separated paths or specifying the pythonpath parameter multiple
 times.

 please see this pull request for colon separated paths:
 https://github.com/django/django/pull/7189

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

Re: [Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-31 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
-+-
 Reporter:  edmorley |Owner:  edmorley
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  1.10
 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:"d8ef5b0e6501692b8b767ebccddc936f496d77e8" d8ef5b0e]:
 {{{
 #!CommitTicketReference repository=""
 revision="d8ef5b0e6501692b8b767ebccddc936f496d77e8"
 Fixed #27152 -- Supported comma delimiter in memcached LOCATION string.
 }}}

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

Re: [Django] #27142: makemigrations fails on special database connections

2016-08-31 Thread Django

* needs_tests: 1 => 0

Comment:

Some tests are added and the patch might be ready for review, however, I
think the addition of consistency checks in `makemigrations`, even with
these changes, could remain backwards-incompatible in some edge cases. For
example, a project with a read-only database that defines some database
routers but hasn't setup a router to prevent migrating on the read-only
database will need to add a rule in a router's `allow_migrate()` to
prevent the consistency check. Previously, I think Django would be usable
without such a rule (of course, a developer could break things by making a
mistake like invoking `manage.py migrate --database=readonly_database`). I
guess anyone in favor of this check in `makemigrations` would deem the
backwards-incompatibility acceptable, provided a note is added in the
release notes.

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

Re: [Django] #27142: makemigrations fails on special database connections

2016-08-31 Thread Django

#27142: makemigrations fails on special database connections
-+
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   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):

 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 Work in progress [https://github.com/django/django/pull/7194 PR] with the
 database routers concept. Tests yet to be 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/066.b5923e020e994b4ca7e1784f1012db88%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25181: Add a localdate() function to get date in a different time zone (was: Move views.generic.dates.timezone_today() to utils.timezone)

2016-08-31 Thread Django

#25181: Add a localdate() function to get date in a different time zone
-+-
 Reporter:  timgraham|Owner:  kswiat
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 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 timgraham):

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

Re: [Django] #27140: Prevent template rendering from hiding a property's TypeError

2016-08-31 Thread Django

#27140: Prevent template rendering from hiding a property's TypeError
-+
 Reporter:  azmeuk   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.10
 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 GitHub ):

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


Comment:

 In [changeset:"59afe61a970dd60df388e7cda9041ef3c0e770cb" 59afe61a]:
 {{{
 #!CommitTicketReference repository=""
 revision="59afe61a970dd60df388e7cda9041ef3c0e770cb"
 Fixed #27140 -- Prevented template rendering from hiding a property's
 TypeError.
 }}}

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

Re: [Django] #20892: Allow configuring the memcached Client with CACHES 'OPTIONS'

2016-08-31 Thread Django

#20892: Allow configuring the memcached Client with CACHES 'OPTIONS'
-+
 Reporter:  alex@…   |Owner:  edmorley
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.5
 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:"65ec8fa8ca56a5378345375e1079025c96d0b833" 65ec8fa]:
 {{{
 #!CommitTicketReference repository=""
 revision="65ec8fa8ca56a5378345375e1079025c96d0b833"
 Fixed #20892 -- Allowed configuring memcached client using OPTIONS.

 Previously, the MemcachedCache backend ignored `OPTIONS` and
 PyLibMCCache used them to set pylibmc behaviors. Both backends now
 pass `OPTIONS` as keyword arguments to the client constructors.
 }}}

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

Re: [Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-31 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
-+-
 Reporter:  edmorley |Owner:  edmorley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 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 timgraham):

 * stage:  Accepted => Ready for checkin


Comment:

 Pending a few cosmetic edits.

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

Re: [Django] #27154: Allow comparing CallableFalse/CallableTrue with bitwise or

2016-08-31 Thread Django

#27154: Allow comparing CallableFalse/CallableTrue with bitwise or
-+-
 Reporter:  tomchristie  |Owner:  alexyer
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 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:"7c57f5cf8cd10b69d0c76ba97ab048ccc2917c55" 7c57f5c]:
 {{{
 #!CommitTicketReference repository=""
 revision="7c57f5cf8cd10b69d0c76ba97ab048ccc2917c55"
 [1.10.x] Fixed #27154 -- Allowed comparing CallableBool with bitwise or.

 Thanks Tim for the review.

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

Re: [Django] #27162: Move CreateExtension to django.db.backends.postgresql

2016-08-31 Thread Django

#27162: Move CreateExtension to django.db.backends.postgresql
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 claudep):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #1873: Multi-select admin filter for RelatedFields

2016-08-31 Thread Django

#1873: Multi-select admin filter for RelatedFields
+
 Reporter:  marc@…  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.admin   |  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  nfa-changelist  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  1
+

Comment (by collinanderson):

 I finally thought of a possible way to do this:

 Use urls like `?fieldname__in=4__in=3`

 We'd need to support that both in the front end (generating those urls),
 and in the backend (handling repeated parameters and making sure they
 become lists).

 I recommend only supporting the OR case (or at least starting with that).
 It's the expected user experience on the web, and I think it would be the
 most useful. (AND would only be useful in some cases for many to many's.)

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

[Django] #27162: Move CreateExtension to django.db.backends.postgresql

2016-08-31 Thread Django

#27162: Move CreateExtension to django.db.backends.postgresql
-+-
   Reporter:  claudep|  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  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  |
-+-
 The CreateExtension currently lives in
 `django.contrib.postgres.operations`. I think that it's a core
 functionality of the PostgreSQL backend and it should be usable without
 requiring contrib.postgres. PostGIS users might want to use it to add
 extensions in migrations. I therefore suggest to move it to a new location
 inside `django.db.backends.postgresql`. Backwards compatibility is kept as
 `CreateExtension` will still be imported from the same module it is
 defined in currently.

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

Re: [Django] #27157: AdminForm model_admin cannot be None

2016-08-31 Thread Django

#27157: AdminForm model_admin cannot be None
---+--
 Reporter:  tpazderka  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 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 tpazderka):

 This is just a stub as our class is not based on `BaseFormset` but rather
 reimplements its methods...
 I am not sure if this is sufficient. If not, I will try to write more
 complete example.

 {{{
 #!python
 class ContactFormset(BaseFormset):
 @property
 def forms(self):
  """
  Iterates through forms and returns them wrapped by `AdminForm`.
  """
  for form, datatype in zip(self._forms, self.get_types()):
  yield AdminForm(form, (self.get_fieldset(datatype), ), {},
 self.get_readonly_fields(datatype))
 }}}

 The last line has to be replaced by:
 {{{
 #!python
 yield AdminForm(form, (self.get_fieldset(datatype), ), {},
 self.get_readonly_fields(datatype),  model_admin=ModelAdmin(MojeidUser,
 AdminSite))
 }}}
 in order to work in django 1.9 and later.

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

Re: [Django] #27159: Pickling query from queryset causes unintended queryset evaluation

2016-08-31 Thread Django

#27159: Pickling query from queryset causes unintended queryset evaluation
-+-
 Reporter:  jtiai|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (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 timgraham):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 I didn't attempt to reproduce but I trust the reporter. If you could
 transform the reproduction information into a test case for
 `queryset_pickle`, that's always helpful.

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

Re: [Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-31 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
--+
 Reporter:  edmorley  |Owner:  edmorley
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Cache system)   |  Version:  1.10
 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 edmorley):

 * cc: emorley@… (added)
 * 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/066.daa0f8e39acc66e9ea4541315c995293%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27157: AdminForm model_admin cannot be None

2016-08-31 Thread Django

#27157: AdminForm model_admin cannot be None
---+--
 Reporter:  tpazderka  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 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:

 Can you give some example code that causes this error? `AdminForm` isn't a
 public API, and I'm not sure if you're calling it directly or triggering
 the problem some other way.

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

Re: [Django] #27160: Document that running the Django test suite requires creating the databases and, on PostgresQL, a superuser (was: Improve `Unit tests` section in `Contributing to Django`)

2016-08-31 Thread Django

#27160: Document that running the Django test suite requires creating the 
databases
and, on PostgresQL, a superuser
--+
 Reporter:  pacahon   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.9
 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):

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


Comment:

 I'll document these requirements when I get a chance.

 It could be nice to remove the requirement of creating the databases, but
 I'm not sure how feasible this is. The problem looks like it's caused by
 module level queries for detecting database features.

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

Re: [Django] #27158: Incorrect positioning of admin' horizontal/vertical filter widgets in RTL languages (was: Small issue with positioning admin page filters in RTL languages)

2016-08-31 Thread Django

#27158: Incorrect positioning of admin' horizontal/vertical filter widgets in 
RTL
languages
+
 Reporter:  mehdipourfar|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  admin, ui, css  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  1
+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted
 * easy:  1 => 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/070.e7cbe2362d509f0e53b0e31b3f3da95e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27161: TypedChoiceField validation bug

2016-08-31 Thread Django

#27161: TypedChoiceField validation bug
--+--
 Reporter:  th13f |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  TypedChoiceField  | Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by claudep):

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


Comment:

 I've already struggled with this in the past. Did you check if tests are
 passing with your proposal?

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

Re: [Django] #27150: Document that a name should be provided when wrapping file-like objects that don't have one with File

2016-08-31 Thread Django

#27150: Document that a name should be provided when wrapping file-like objects
that don't have one with File
--+
Reporter: pacahon |Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.10
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 pacahon):

As I understood from #26495 python file-like objects works fine with
`requests` library, because in CPython file objects use `object.__bool__`
and always returns True if no `__bool__` and `__len__`.

> I think documenting that you should pass a name for file-like objects
that don't have one is the best course of action.

It's little bit strange for me to allow pass `name=None` to
`Storage.save`, while disallow use empty name for file-like objects. Maybe
we can restore default `__bool__` behavior in `Storage.save` method?
{{{
content.__bool__ = lambda _: True
}}}

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

Re: [Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-31 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
--+
 Reporter:  edmorley  |Owner:  edmorley
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Cache system)   |  Version:  1.10
 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 alexyer):

 Ok. Not a problem.

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

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

Re: [Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-31 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
--+
 Reporter:  edmorley  |Owner:  edmorley
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Cache system)   |  Version:  1.10
 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 edmorley):

 * owner:  alexyer => edmorley


Comment:

 Ah I have this finished locally already - sorry thought I'd set the ticket
 assignee already!

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

Re: [Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-31 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
--+
 Reporter:  edmorley  |Owner:  alexyer
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Cache system)   |  Version:  1.10
 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 alexyer):

 * status:  new => assigned
 * owner:  nobody => alexyer


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

Re: [Django] #27039: ModelFields with 'default' value set and 'required'=False in form does not use default value

2016-08-31 Thread Django

#27039: ModelFields with 'default' value set and 'required'=False in form does 
not
use default value
-+-
 Reporter:  devbis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  default non- | Triage Stage:  Accepted
  required modelform |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>


Comment:

 Reopening as
 
[https://github.com/django/django/commit/325dd0befea3012c42eefa061f509fbdf1b6a8aa#commitcomment-18843670
 Alex Hill reported] that this isn't working with prefixed forms.

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

Re: [Django] #27154: Allow comparing CallableFalse/CallableTrue with bitwise or

2016-08-31 Thread Django

#27154: Allow comparing CallableFalse/CallableTrue with bitwise or
-+-
 Reporter:  tomchristie  |Owner:  alexyer
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 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:"b7fb608142a0be568bc5dce952de5e6aefc2488c" b7fb6081]:
 {{{
 #!CommitTicketReference repository=""
 revision="b7fb608142a0be568bc5dce952de5e6aefc2488c"
 Fixed #27154 -- Allowed comparing CallableBool with bitwise or.

 Thanks Tim for the review.
 }}}

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

Re: [Django] #27154: Allow comparing CallableFalse/CallableTrue with bitwise or (was: Minor difference in behavior between CallableFalse/CallableTrue and False/True.)

2016-08-31 Thread Django

#27154: Allow comparing CallableFalse/CallableTrue with bitwise or
-+-
 Reporter:  tomchristie  |Owner:  alexyer
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 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 timgraham):

 * has_patch:  0 => 1
 * 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/069.df9413e43a5e452e843d0e080fea8cce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27161: TypedChoiceField validation bug

2016-08-31 Thread Django

#27161: TypedChoiceField validation bug
--+
 Reporter:  th13f |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Forms |Version:  master
 Severity:  Normal| Resolution:
 Keywords:  TypedChoiceField  |   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by th13f):

 * Attachment "Running_coerce_in_TypedChoiceField_to_python_method.patch"
 added.

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

[Django] #27161: TypedChoiceField validation bug

2016-08-31 Thread Django

#27161: TypedChoiceField validation bug
+--
 Reporter:  th13f   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  master
 Severity:  Normal  |   Keywords:  TypedChoiceField
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+--
 Example model:

 {{{
 from django.contrib.postgres.fields import ArrayField

 class ArrayFieldTestModel(models.Model):
 CHOICES = map(lambda x: (x, str(x)), range(10))

 test_field = ArrayField(models.IntegerField(choices=CHOICES),
 blank=True, null=True)

 }}}


 On form saving we'll got validation error for valid choices:
 [[Image(https://snag.gy/DGNVtR.jpg)]]

 This is caused by validation ordering:
 1. TypedChoiceField clean method called
 2. Field clean method called (super)
 3. to_python method called, which should transform value to correct, but
 it doesn't.
 3. TypedChoiceField validate called, which raise ValidationError: no such
 choice. He is trying to find string value in integers array and can't do
 this.
 4. after super clean method, TypedChoiceField is trying to coerce value
 (it's too late, error was raised before this).

 this can be easily fixed by moving _coerce call into `to_python`.

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

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

Re: [Django] #27158: Small issue with positioning admin page filters in RTL languages

2016-08-31 Thread Django

#27158: Small issue with positioning admin page filters in RTL languages
+--
 Reporter:  mehdipourfar|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  admin, ui, css  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  1
+--

Comment (by mehdipourfar):

 Hi,
 Larger images are here:

 http://uploads.im/0B6JX.jpg
 http://uploads.im/J8AqP.jpg

 I've blurrified images but the only important thing is the position of
 filter horizontal boxes that one can see even in thumbnails.
 Thank you for your consideration.

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

[Django] #27160: Improve `Unit tests` section in `Contributing to Django`

2016-08-31 Thread Django

#27160: Improve `Unit tests` section in `Contributing to Django`
--+
 Reporter:  pacahon   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I'm talking about
 [https://docs.djangoproject.com/en/1.9/internals/contributing/writing-code
 /unit-tests/#using-another-settings-module Using another settings module]
 subsection.

 Django system tests freezes on my machine with default settings (sqlite),
 so I decided to try `postgresql` as backend.
 I created user with CREATEDB permissions and replaced DB settings with

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql_psycopg2',
 'USER': 'test',
 'PASSWORD': 'test',
 'HOST': 'localhost',
 'NAME': 'test_d'
 },
 'other': {
 'ENGINE': 'django.db.backends.postgresql_psycopg2',
 'USER': 'test',
 'PASSWORD': 'test',
 'HOST': 'localhost',
 'NAME': 'test_o',
 }
 }
 }}}

 After that I got an error:

 {{{
 django.db.utils.OperationalError: FATAL:  database "test_d" does not exist
 }}}

 When docs says:
 {{{
 Test databases get their names by prepending test_ to the value of the
 NAME settings for the databases defined in DATABASES. These test databases
 are deleted when the tests are finished.
 }}}
 I'm waiting that `runtests` will create `test_test_o` and `test_test_d`
 for me and I no need in `test_d` and `test_o` databases at all.

 Maybe I'm doing something wrong or docs should be improved?

 P.S. After I created dbs manually, I got:

 {{{
 psycopg2.ProgrammingError: permission denied to create extension "hstore".
 HINT:  Must be superuser to create this extension.
 }}}

 Mb it's engine specific error, I'm not sure.

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

Re: [Django] #27131: send_mail() error on Python 2 if smtp server uses CRAM-MD5 auth method

2016-08-31 Thread Django

#27131: send_mail() error on Python 2 if smtp server uses CRAM-MD5 auth method
-+-
 Reporter:  slavugan |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  send_mail| Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 As suggested by Tim on the pull request, a workaround on older Django
 could be to define email username and pasword as bytestrings.

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

Re: [Django] #5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for different fields

2016-08-31 Thread Django

#5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for
different fields
-+-
 Reporter:  ciantic@…|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  SplitDateTimeWidget  | Triage Stage:  Accepted
  MultiWidget|
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Before this is reviewed, we should have a pull request with the proposed
 patch, including tests and docs.

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

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

[Django] #27159: Pickling query from queryset causes unintended queryset evaluation

2016-08-31 Thread Django

#27159: Pickling query from queryset causes unintended queryset evaluation
---+
 Reporter:  jtiai  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 According to documentation pickling queryset.query should be correct
 approach and it should only pickle only relevant information to recreate
 queryset.query again.

 Given models:
 {{{#!python
 from django.db import models

 # Create your models here.
 class ParentModel(models.Model):
 name = models.CharField(max_length=64)

 class ChildModel(models.Model):
 name = models.CharField(max_length=64)

 parent = models.ForeignKey('ParentModel', related_name='children')
 }}}

 Following querys, when pickled causes unwanted evaluation and creating
 quite large pickled result:
 {{{#!python
 for x in range(1,1):
 ParentModel(name='Parent {}'.format(x), ).save()

 ChildModel(name='Child 1', parent=ParentModel.objects.all()[0]).save()

 parents_1 = ParentModel.objects.all().values_list('pk', flat=True)
 children_1 = ChildModel.objects.filter(parent__in=parents_1)

 pickled_stuff_1 = pickle.dumps(children_1.query)

 parents_2 = ParentModel.objects.all()
 children_2 = ChildModel.objects.filter(parent__in=parents_2)

 pickled_stuff_2 = pickle.dumps(children_2.query)

 # First len is about 74 kilobytes, second len is about 2 megabytes.
 print len(pickled_stuff_1), len(pickled_stuff_2)
 }}}

 When comparing sizes of pickled queries both are relatively big. When
 inspecting latter pickle it can be seen that it actually contains all
 instances from fully evaluated queryset. Same behavior exists in 1.8 and
 1.10 as well.

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

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

Re: [Django] #27158: Small issue with positioning admin page filters in RTL languages

2016-08-31 Thread Django

#27158: Small issue with positioning admin page filters in RTL languages
+--
 Reporter:  mehdipourfar|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  admin, ui, css  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  1
+--
Changes (by bmispelon):

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


Comment:

 Hi,

 The screenshots are really small and make it hard to see what's changed
 exactly.

 Could you re-upload them directly to the ticket (use the "Attachments"
 feature of Trac)?
 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/070.c2e0df5e7512ab2c21b7d1cd09e58471%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27158: Small issue with positioning admin page filters in RTL languages

2016-08-31 Thread Django

#27158: Small issue with positioning admin page filters in RTL languages
---+
 Reporter:  mehdipourfar   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.10
 Severity:  Normal |   Keywords:  admin, ui, css
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  1
---+
 Admin's filters were floated to left in RTL version and not vertically
 aligned.

 I've fixed it and sent a pull request here.
 https://github.com/django/django/pull/7183

 Before:
 [[Image(http://sl.uploads.im/t/0B6JX.jpg)]]
 After:
 [[Image(http://sk.uploads.im/t/J8AqP.jpg)]]

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

Re: [Django] #27154: Minor difference in behavior between CallableFalse/CallableTrue and False/True.

2016-08-31 Thread Django

#27154: Minor difference in behavior between CallableFalse/CallableTrue and
False/True.
--+
 Reporter:  tomchristie   |Owner:  alexyer
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  Version:  1.10
 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
--+

Comment (by alexyer):

 Here is the [https://github.com/django/django/pull/7190 PR]. 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/069.06954d11addfc0f9dfa42ee8ac9e1d1d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27154: Minor difference in behavior between CallableFalse/CallableTrue and False/True.

2016-08-31 Thread Django

#27154: Minor difference in behavior between CallableFalse/CallableTrue and
False/True.
--+
 Reporter:  tomchristie   |Owner:  alexyer
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  Version:  1.10
 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 alexyer):

 * status:  new => assigned
 * owner:  nobody => alexyer


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

[Django] #27157: AdminForm model_admin cannot be None

2016-08-31 Thread Django

#27157: AdminForm model_admin cannot be None
---+
 Reporter:  tpazderka  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When using `AdminForm` without the keyword argument `model_admin` which
 defaults to None, we get `AttributeError` by calling
 `get_empty_value_display` without checking for the `model_admin` type.
 This seems to be also true for `AdminReadonlyField` 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/052.dca4f128241f26c82409d99d77f02e99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27131: send_mail() error on Python 2 if smtp server uses CRAM-MD5 auth method

2016-08-31 Thread Django

#27131: send_mail() error on Python 2 if smtp server uses CRAM-MD5 auth method
-+-
 Reporter:  slavugan |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  send_mail| 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 Claude Paroz ):

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


Comment:

 In [changeset:"fe252c0a5a2ceb5c97aafc16a42dbe5ad03ef1e9" fe252c0a]:
 {{{
 #!CommitTicketReference repository=""
 revision="fe252c0a5a2ceb5c97aafc16a42dbe5ad03ef1e9"
 Fixed #27131 -- Passed proper string type to SMTP connection login

 Passing an Unicode string on Python 2 was crashing the connection.
 Thanks slavu...@gmail.com for the report, and Tim Graham for the review.
 }}}

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

Re: [Django] #5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for different fields

2016-08-31 Thread Django

#5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for
different fields
-+-
 Reporter:  ciantic@…|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  SplitDateTimeWidget  | Triage Stage:  Accepted
  MultiWidget|
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jameskirsop):

 * cc: james.kirsop@… (added)


Comment:

 Would love to see this reviewed at some stage. It would be particularly
 helpful in supporting the "placeholder" attribute.

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

55 matches

Mail list logo