date:20131016

[Django] #21281: trying to override settings in test case setUpClass

2013-10-16 Thread Django

#21281: trying to override settings in test case setUpClass
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Testing framework  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The override_settings decorator doesn't effect the setUpClass method (I
 believe this is because class decorators don't effect classmethods) and as
 the self.settings() method requires an object instance, there is no easy
 way to change the settings for the setUpClass method.

 Is there any reason settings() requires an instance and couldn't be class
 based?

-- 
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.91da6932f15d445e3c038ecf519389c7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8162: Increase Permission.name max_length

2013-10-16 Thread Django

#8162: Increase Permission.name max_length
-+-
 Reporter:  juliae   |Owner:  wilsoniya
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  schemamigration  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 That depends on how we fix this. If, instead of just making the name field
 ridiculously long, we take the route from comment:18, then we really don't
 need the code from #18866.

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

Re: [Django] #14930: `values_list()` fails on queryset ordered by extra column

2013-10-16 Thread Django

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  fhahn
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by timo):

 No, per our [https://docs.djangoproject.com/en/dev/internals/security
 /#supported-versions support policy] those branches are only receiving
 security fixes and critical (data loss) bug fixes respectively.

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

Re: [Django] #14930: `values_list()` fails on queryset ordered by extra column

2013-10-16 Thread Django

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  fhahn
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by knoffhoff):

 Hello, will this fix also be integrated into the stable branches 1.4 and
 1.5?

 Best 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/065.620b88cb05eeb934a7eac34343cf3296%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21169: Deletion in custom reverse managers

2013-10-16 Thread Django

#21169: Deletion in custom reverse managers
-+-
 Reporter:  sebastian|Owner:  loic84
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by loic84):

 * needs_docs:  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/067.f2de02399bed4501cd3b1dc019b2433f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8162: Increase Permission.name max_length

2013-10-16 Thread Django

#8162: Increase Permission.name max_length
-+-
 Reporter:  juliae   |Owner:  wilsoniya
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  schemamigration  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mjtamlyn):

 More accurately, the code from #18866 should stay, but the 39 changes to
 something bigger. Just in case someone wants a verbose name of 500
 characters. (Why???!)

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

Re: [Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
-+-
 Reporter:  cam.w.lee@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  javascript escape| Triage Stage:
  admin filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by timo):

 By the way, you should report security issues like this privately.  For
 Django, see djangoproject.com/security

-- 
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/077.028d70a27a4214b2e90a83cc331cc0bf%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16969: Avoid selecting production database prior to test database setup/teardown

2013-10-16 Thread Django

#16969: Avoid selecting production database prior to test database 
setup/teardown
--+
 Reporter:  andreas_pelme |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 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
--+

Comment (by claudep):

 In my patch, then, what about subclassing `nodb_connection()` in the
 Oracle backend and returning `self.connection`?

-- 
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/071.d4b8ecd1260d4cb7ce340ae36d422e3d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21259: Wizard sets queryset instead of instance on InlineFormset

2013-10-16 Thread Django

#21259: Wizard sets queryset instead of instance on InlineFormset
-+-
 Reporter:  banderkat@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.formtools|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  wizard,  | Triage Stage:  Accepted
  InlineFormSet  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kkillebrew):

 * needs_better_patch:  1 => 0


Comment:

 That worked!  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/077.903a5620f7a2ee87e619cbc4d107aed5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
-+-
 Reporter:  cam.w.lee@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  javascript escape| Triage Stage:
  admin filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by cam.w.lee@…):

 Ya. I'm going to look into this with Grappelli and report a bug there if
 needed.

 Thanks for the help and sorry this turned out to be invalid (or not I
 guess - better that there is no bug).

-- 
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/077.98ea0e0a77ae7ab60a45fee4773911f1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8162: Increase Permission.name max_length

2013-10-16 Thread Django

#8162: Increase Permission.name max_length
-+-
 Reporter:  juliae   |Owner:  wilsoniya
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  schemamigration  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shai):

 #18866 has been fixed. Now, when this is fixed, we need to remember to un-
 fix 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/064.d52e8cc6aaea9e46699cc4851ba262be%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
-+-
 Reporter:  cam.w.lee@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  javascript escape| Triage Stage:
  admin filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 Ok, this is a cross-site scripting (XSS) security vulnerability so
 definitely let whoever know once you track down the issue further. Try
 upgrading your dependencies to the latest versions before reporting it if
 possible.

-- 
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/077.52c489c63b2fa4ecd2b14e8fc3dca3d9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13245: manually set db_table should not validate if it needs to be truncated

2013-10-16 Thread Django

#13245: manually set db_table should not validate if it needs to be truncated
-+-
 Reporter:  skoom|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by shai):

 * cc: shaib (removed)
 * cc: shai (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.dea7570abad2c5e975d8ad9e9815aa40%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13245: manually set db_table should not validate if it needs to be truncated

2013-10-16 Thread Django

#13245: manually set db_table should not validate if it needs to be truncated
-+-
 Reporter:  skoom|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by shai):

 Hi Tim,

 Yes, I disagree with the proposed solution -- actually, with the bug
 itself as it stands -- because it means some perfectly-working apps will
 suddenly stop working on Oracle; apps developed on other backends are
 particularly susceptible to this.

 We probably need a documentation fix here. Other than that, we need to be
 consistent, but the other backends' limitations are so seldom met, that it
 is indeed very low priority.

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

Re: [Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
-+-
 Reporter:  cam.w.lee@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  javascript escape| Triage Stage:
  admin filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by anonymous):

 I just realized something: maybe this is an issue with Grappelli. I just
 turned off Grappelli and I'm not getting alerts anymore.

-- 
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/077.07a7c94b4e634c7715f6027b4f2d64aa%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
-+-
 Reporter:  cam.w.lee@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  javascript escape| Triage Stage:
  admin filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by cam.w.lee@…):

 If you're unable to re-produce, it might be fixed in a more recent version
 of Django (I'm on 1.4). I wasn't able to test with a newer version of
 Django, but did do some searching and couldn't find any mention of this
 anywhere.

-- 
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/077.7ba6a7f3d10c33b7b3397f8210f8638a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
-+-
 Reporter:  cam.w.lee@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  javascript escape| Triage Stage:
  admin filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by cam.w.lee@…):

 The filter is defined in the model admin:
 
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_filter

 You simply specify which database fields should be filterable. From our
 code (simplified):

 {{{
 class VehicleAdmin( ModelAdmin ):

 list_filter = ('UnitName')

 }}}

-- 
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/077.c1a69d7292b103183b0c02b8bf887c52%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
-+-
 Reporter:  cam.w.lee@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  javascript escape| Triage Stage:
  admin filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 How is this filter generated? I tried `ModelAdmin.list_filter` but
 couldn't reproduce.

-- 
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/077.4352a1a11bd38e9e78cbd294ebdb23e6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21280: Avoid generating empty migrations on serialization failures

2013-10-16 Thread Django

#21280: Avoid generating empty migrations on serialization failures
--+
   Reporter:  timo|  Owner:
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 If a model fails to serialize, an empty migration file will be generated
 which needs to be removed manually. You'll get an error like
 "django.db.migrations.loader.BadMigrationError: Migration 0001_initial in
 app auth has no Migration class" if you try to migrate without doing so.

 We should either verify that there won't be any errors before creating the
 migration file or remove the empty file if there is an error.

-- 
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.194b2cc865aa0ba72690351213082200%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21279: Field content not escaped in admin filter

2013-10-16 Thread Django

#21279: Field content not escaped in admin filter
--+
 Reporter:  cam.w.lee@…   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:|Version:  1.4
  contrib.admin   |   Keywords:  javascript escape admin filter
 Severity:  Normal|  Has patch:  0
 Triage Stage:  Unreviewed|  UI/UX:  0
Easy pickings:  1 |
--+
 A user of our system recently entered the following as their name:

 {{{
 ">alert()
 }}}

 This caused an issue in the admin interface. Although this user data was
 sanitized properly in the list view and change form, when we added an
 admin filter on this field, we started getting Javascript alerts when
 browsing the admin. Turns out that there is no escaping in the options of
 the filter even though they're pulled from the database and could be user
 entered content.

 This is what we see in the list options:
 {{{
 ">
 }}}

 And this is what the HTML looks like:
 {{{
 
 All
 
 ">alert()
 005
 
 }}}

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

Re: [Django] #19323: Add django.contrib.redirects setting for turning redirect on/off.

2013-10-16 Thread Django

#19323: Add django.contrib.redirects setting for turning redirect on/off.
-+-
 Reporter:  Melevir  |Owner:  Melevir
 Type:  New feature  |   Status:  new
Component:  contrib.redirects|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  schemamigration, | Triage Stage:
  redirects, is_active   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

 * version:  1.4 => master
 * easy:  1 => 0


Comment:

 @ZeevG, migrations is still under active development and I don't think
 we're quite ready to add them to contrib apps yet. Stay tuned.

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

Re: [Django] #21142: Cannot run migrations that reference django.contrib.auth.models.User (was: Referencing the User model and migrations)

2013-10-16 Thread Django

#21142: Cannot run migrations that reference django.contrib.auth.models.User
-+
 Reporter:  mario.pfeifer@…  |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  Migration, Auth  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by timo):

 I've looked into adding migrations to `contrib.auth`, but ran into #21275.
 It's also unclear how migrations are supposed to work with "swappable"
 models like `User`. Obviously, we want to ignore it if a project uses a
 custom user.

-- 
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/082.24e53719f1e184a8d235a62ee2ffd266%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8116: django.template.loader.select_template should not silently skip a template which includes another template that does not exist

2013-10-16 Thread Django

#8116: django.template.loader.select_template should not silently skip a 
template
which includes another template that does not exist
-+
 Reporter:  Michael P. Jung  |Owner:  shanx
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  sprint2013   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by unaizalakain):

 I would rather add a `template_name` attribute to the TemplateDoesNotExist
 class. This attribute could be used not only in this case but also in
 normal TemplateDoesNotExist exception.

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

Re: [Django] #7220: django.contrib.auth.models.AbstractBaseUser.last_login should allow null=True (was: Last_login in django.contrib.auth should has null=True)

2013-10-16 Thread Django

#7220: django.contrib.auth.models.AbstractBaseUser.last_login should allow
null=True
-+-
 Reporter:  veena|Owner:  anonymous
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  contrib.auth |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  schemamigration  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

 * keywords:  auth last login user => schemamigration
 * type:  Bug => Cleanup/optimization


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

Re: [Django] #21259: Wizard sets queryset instead of instance on InlineFormset

2013-10-16 Thread Django

#21259: Wizard sets queryset instead of instance on InlineFormset
-+-
 Reporter:  banderkat@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.formtools|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  wizard,  | Triage Stage:  Accepted
  InlineFormSet  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by timo):

 I believe you will need to include:
 {{{
 class Meta:
 app_label = 'formtools'
 }}}
 on the model.

-- 
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/077.2d486f6537ddd687134adc01112f815e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16969: Avoid selecting production database prior to test database setup/teardown

2013-10-16 Thread Django

#16969: Avoid selecting production database prior to test database
setup/teardown
--+
Reporter: andreas_pelme |Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Testing framework | Version: master
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
--+

Comment (by shai):

Oracle does not support "databases" in the sense that other backends do;
the NAME parameter is actually part of selecting the server you connect
to. The tests worked with the patch because the patch changed the generic
create_test_db function, which the Oracle backend overrides. In fact,
Oracle doesn't use the TEST_NAME at all (except for printing) -- it uses a
TEST_USER and TEST_TBLSPACE instead.

To summarize: On Oracle, you connect as a user to a server. There is only
one "database". You cannot avoid connecting to it, AFAIK.

--
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/071.3ae336c2931f6b999ae4453888b69b6d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21270: pep8 cleanup: multiple statements on one line (colon)

2013-10-16 Thread Django

#21270: pep8 cleanup: multiple statements on one line (colon)
--+
 Reporter:  timo  |Owner:  alasdair
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   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 alasdair):

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


Comment:

 I'd like to have a go at this.

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

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

Re: [Django] #21275: Cannot use migrations if model field specifies validators

2013-10-16 Thread Django

#21275: Cannot use migrations if model field specifies validators
+--
 Reporter:  timo|Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by loic84):

 * cc: loic@… (added)
 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 POC https://github.com/loic/django/compare/ticket21275.

-- 
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.132e30c325c398f9b3ca52b3698fc062%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 2992f4: Fixed #19657 -- Made sql commands honor allow_migr...

2013-10-16 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 2992f428614349b0dfe0f4183905f492fd3f62c2
  
https://github.com/django/django/commit/2992f428614349b0dfe0f4183905f492fd3f62c2
  Author: Claude Paroz 
  Date:   2013-10-16 (Wed, 16 Oct 2013)

  Changed paths:
M django/core/management/sql.py
M tests/commands_sql/tests.py

  Log Message:
  ---
  Fixed #19657 -- Made sql commands honor allow_migrate

Thanks Manel Clos for the report and the initial patch, and
Marc Tamlyn and Tim Graham for the review.


  Commit: 650b6fd90efea058c54800d2ba0e0976547894a3
  
https://github.com/django/django/commit/650b6fd90efea058c54800d2ba0e0976547894a3
  Author: Claude Paroz 
  Date:   2013-10-16 (Wed, 16 Oct 2013)

  Changed paths:
M django/core/management/commands/flush.py
M django/core/management/commands/migrate.py
M django/core/management/sql.py
M django/db/backends/__init__.py
M django/db/utils.py

  Log Message:
  ---
  Add get_migratable_models util method to ConnectionRouter


Compare: https://github.com/django/django/compare/91c77eeab837...650b6fd90efe

-- 
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/525eb8e12fb8a_4c96bd7d4c127355%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19657: sql, sqlcustom, sqlindexes and sqlall do not take allow_syncdb into account

2013-10-16 Thread Django

#19657: sql, sqlcustom, sqlindexes and sqlall do not take allow_syncdb into 
account
-+-
 Reporter:  manelclos@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  sql sqlall database  |  checkin
  router |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"2992f428614349b0dfe0f4183905f492fd3f62c2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2992f428614349b0dfe0f4183905f492fd3f62c2"
 Fixed #19657 -- Made sql commands honor allow_migrate

 Thanks Manel Clos for the report and the initial patch, and
 Marc Tamlyn 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/077.c0e52eea249f2f6c9e59923a4bebe805%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21278: Using dumpdata to create unit test fixtures causes duplicate foreign keys for auth permissions. Excluding auth causes other referenced auth models to be missing.

2013-10-16 Thread Django

#21278: Using dumpdata to create unit test fixtures causes duplicate foreign
keys
for auth permissions. Excluding auth causes other referenced auth models
to be missing.
---+
Reporter: ellisd23@… | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth |Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
This seems to be a pretty fundamental issue, since models will frequently
reference User. There are many instances of users having frustrations
with contrib apps that are auto-generated upon migration/sync (e.g.
[http://stackoverflow.com/questions/853796/problems-with-contenttypes-
when-loading-a-fixture-in-django contenttypes]).

For contenttypes, this issue can be mitigated by excluding the app and
using --natural. But for contrib.auth, if the app is excluded, any
referenced User objects in fixture data will be missing. If the app is
not excluded, duplicate permissions will be created, since the post-
migration signal will have already created them. Since there is a unique
key restraint, the importing of the fixture data will fail. It's a catch
22.

Developers can manually remove the permissions from the fixture data, or
override fixture loading in their tests to remove the data, but it seems
to me that since this is such a basic piece of functionality, there should
be a simple interface to do such a thing. It'd be nice to have something
simpler for contenttypes as well, rather than "--exclude contenttypes
--natural".

--
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/061.8613f6ead8656b9da8ef82277fd5d427%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static files

2013-10-16 Thread Django

#21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static 
files
-+
 Reporter:  dblack+django@…  |Owner:  vajrasky
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  master
 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
-+

Comment (by timo):

 Correct, although I would expect the subclass to simply look like this:
 {{{
 class CustomStaticFilesStorage(StaticFilesStorage):
 file_permissions_mode = 0o644
 directory_permissions_mode = 0o600
 }}}

-- 
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/085.a756ec9f467c43e5c981c92228551047%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static files

2013-10-16 Thread Django

#21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static 
files
-+
 Reporter:  dblack+django@…  |Owner:  vajrasky
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  master
 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 vajrasky):

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


Comment:

 Let me get this straight.

 So FileSystemStorage has self.file_permissions_mode and
 self.directory_permissions_mode. Their values come from
 settings.FILE_UPLOAD_PERMISSIONS and
 settings.FILE_UPLOAD_DIRECTORY_PERMISSIONS.

 For StaticFilesStorage, the situation is same. But if you dislike the
 permissions, all you have to do is...


 {{{
 class CustomStaticFilesStorage(StaticFilesStorage):
   def __init__(self, location=None, base_url=None, *args, **kwargs):
 self.file_permissions_mode = 0o644
 self.directory_permissions_mode = 0o600
 super(CustomStaticFilesStorage, self).__init__(location, base_url,
  *args, **kwargs)

 settings.STATICFILES_STORAGE = CustomStaticFilesStorage()
 }}}


 Is that what is in your mind?

-- 
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/085.53312aa8f270e3d4206c45f592413d8d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16969: Avoid selecting production database prior to test database setup/teardown

2013-10-16 Thread Django

#16969: Avoid selecting production database prior to test database 
setup/teardown
--+
 Reporter:  andreas_pelme |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 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
--+

Comment (by claudep):

 Here's an alternative patch. Should be thoroughly reviewed!

-- 
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/071.4aed43e5a51a3f4191fe53c8df7397c8%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 91c77e: Avoided hardcoding Permission.name max_length

2013-10-16 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 91c77eeab837ff793311ac5b0321015a4e66d6da
  
https://github.com/django/django/commit/91c77eeab837ff793311ac5b0321015a4e66d6da
  Author: Tim Graham 
  Date:   2013-10-16 (Wed, 16 Oct 2013)

  Changed paths:
M django/contrib/auth/management/__init__.py

  Log Message:
  ---
  Avoided hardcoding Permission.name max_length

refs #18866.



-- 
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/525eb147b3a12_4cab129bd5468364%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18866: model Meta verbose_name too long error message not obvious

2013-10-16 Thread Django

#18866: model Meta verbose_name too long error message not obvious
--+
 Reporter:  elena |Owner:  toyg
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"91c77eeab837ff793311ac5b0321015a4e66d6da"]:
 {{{
 #!CommitTicketReference repository=""
 revision="91c77eeab837ff793311ac5b0321015a4e66d6da"
 Avoided hardcoding Permission.name max_length

 refs #18866.
 }}}

-- 
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.6684a5da96389a817f6d5aec08eb23e0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21259: Wizard sets queryset instead of instance on InlineFormset

2013-10-16 Thread Django

#21259: Wizard sets queryset instead of instance on InlineFormset
-+-
 Reporter:  banderkat@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.formtools|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  wizard,  | Triage Stage:  Accepted
  InlineFormSet  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by kkillebrew):

 Thanks for the notes.  I'm having some issues with the test models.  I put
 the new models.py in django.contrib.formtools.tests, and I see runtests.py
 says in the verbose output 'Creating table formtools_testmodel', but then
 the test fails with 'OperationalError: no such table: tests_poet'.

-- 
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/077.0b6300d6035488d4ff4440b2e9f45654%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21276: Bad trademark link on /community/logos/ (was: Bad link)

2013-10-16 Thread Django

#21276: Bad trademark link on /community/logos/
-+-
 Reporter:  radiotipo@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  *.djangoproject.com  |  Version:
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timo):

 * status:  new => closed
 * resolution:   => fixed
 * component:  Uncategorized => *.djangoproject.com
 * version:  1.4 =>
 * type:  Uncategorized => Bug


Comment:

 Fixed, thank-you.

-- 
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/077.f00839037d855eaf4e530d09a66b440f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21276: Bad link

2013-10-16 Thread Django

#21276: Bad link
---+--
 Reporter:  radiotipo@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 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 radiotipo@…):

 Replying to [comment:1 timo]:
 > Where did you find the link? I believe the link you are looking for is
 https://www.djangoproject.com/trademarks/
 >


 I found it here:
 https://www.djangoproject.com/community/logos/

 I'm trying to submit a screen capture showing the actual position of the
 URL, but it's right in the first paragraph at the top, see 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/077.b8940bf88b2490aeb89e871cf1ec07f4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21259: Wizard sets queryset instead of instance on InlineFormset

2013-10-16 Thread Django

#21259: Wizard sets queryset instead of instance on InlineFormset
-+-
 Reporter:  banderkat@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.formtools|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  wizard,  | Triage Stage:  Accepted
  InlineFormSet  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timo):

 * needs_better_patch:  0 => 1
 * needs_tests:  1 => 0


Comment:

 Thanks, I left comments for improve on the PR. Please uncheck "Patch needs
 improvement" when 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/077.267e05def0b4732927e89c84689f1d31%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19657: sql, sqlcustom, sqlindexes and sqlall do not take allow_syncdb into account

2013-10-16 Thread Django

#19657: sql, sqlcustom, sqlindexes and sqlall do not take allow_syncdb into 
account
-+-
 Reporter:  manelclos@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  sql sqlall database  |  checkin
  router |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timo):

 * 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/077.5bb52d726d3ca47225fe9d42dea265a8%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21275: Cannot use migrations if model field specifies validators

2013-10-16 Thread Django

#21275: Cannot use migrations if model field specifies validators
+--
 Reporter:  timo|Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 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 timo):

 After discussion with loic84 in #django-developers, it appears that
 validators should be serializable and that this error is due to the regex
 used by the username field of `contrib.auth.models.AbstractUser` not being
 serializable. Loic says validators may be useful for data migrations,
 hence a possible reason not to exclude them entirely.

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

Re: [Django] #19973: Management commands migration to argparse

2013-10-16 Thread Django

Comment (by claudep):

Before starting with the implementation, there is a design decision to
make. `argparse` doesn't provide the same declarative syntax that
`optparse` used to provide with `make_option`. I see two main ways to go
forward:

1. Keep declarative syntax and mostly the same Command API that we have
now. Instead of importing `make_option` from `optparse`, we would import
it from a Django-provided utility, optionally renaming it `make_argument`.
Internally, this would only build a list of parameters that we would then
pass to `add_argument` calls in `create_parser`.[[BR]]
''Advantages'': nicer declarative syntax, less changes for custom
command writers (and accessorily easier for `call_command` to get default
values without instantiating the parser)

2. Depart from the current declarative syntax and change the documentation
about adding options for custom commands, basically instructing to
subclass `create_parser` (or more probably create a new subclassable
method `BaseCommand.add_arguments(self, parser)`) and to add arguments by
calling `parser.add_argument(`).[[BR]]
''Advantages'': closer approach to standard 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/062.58ee8a428c3c510222dbd3445dc939c6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16969: Avoid selecting production database prior to test database setup/teardown

2013-10-16 Thread Django

#16969: Avoid selecting production database prior to test database 
setup/teardown
--+
 Reporter:  andreas_pelme |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 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
--+

Comment (by timo):

 Regarding PostgreSQL, the answer appears to be "Yes". From the
 [http://www.postgresql.org/docs/9.1/interactive/app-initdb.html PostgreSQL
 docs]:

   "The `postgres` database is a default database meant for use by users,
 utilities and third party applications."

 Additional information in this [http://stackoverflow.com/questions/2370525
 /default-database-named-postgres-on-postgresql-server stackoverflow
 question].

-- 
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/071.44f465ce636d5a367b9d7620d725d5b8%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #7836: django.test.client._session should check for session middleware instead

2013-10-16 Thread Django

#7836: django.test.client._session should check for session middleware instead
---+
 Reporter:  trevor |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 unaizalakain):

 What if `_sesion` arises an exception if no subclass of the session
 middleware is found?

-- 
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.04a443a74a17014f12d0dce8fe3ca93d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21277: Running tests should not require "real" database

2013-10-16 Thread Django

#21277: Running tests should not require "real" database
-+-
 Reporter:  tobias9  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.5
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  test mysql   | Triage Stage:
  databases  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Duplicate of #16969

-- 
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.1103762316545e02257821bc2787541a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #7836: django.test.client._session should check for session middleware instead

2013-10-16 Thread Django

Comment (by vzima):

Replying to [comment:11 unaizalakain]:
> I'm probably missing something, where's the need of checking if some
kind of session middleware exists? If not present, wouldn't `{}` be
returned anyways?
In application, the attribute `request.session` is created by
`SessionMiddleware`. If missing you will get `AttributeError`.
In tests, you get either empty dictionary or `SessionStore`.

The problem here is no error is indicated by client when you don't have
sessions installed, but `client.login` does not do a valid login. This is
problem which is not quite easy to find.
>
> BTW, shouldn't it be better if the engine module import happen outside
`_session` and instead of checking for `if coockie` `if cookie is not
None` is checked?
It wouldn't. You can change settings for the test and you want the test to
use yours.

--
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.279e5e85396abb011c6c18426f73bd5b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21276: Bad link

2013-10-16 Thread Django

#21276: Bad link
---+--
 Reporter:  radiotipo@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 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 timo):

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


Comment:

 Where did you find the link? I believe the link you are looking for is
 https://www.djangoproject.com/trademarks/

-- 
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/077.3ba2ea62d3ec1ea9171f3e09bb9cd57a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #7836: django.test.client._session should check for session middleware instead

2013-10-16 Thread Django

#7836: django.test.client._session should check for session middleware instead
---+
 Reporter:  trevor |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 unaizalakain):

 * cc: unai@… (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/064.d03d90bba3494bfdccd33bf652de%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21277: Running tests should not require "real" database

2013-10-16 Thread Django

#21277: Running tests should not require "real" database
---+--
 Reporter:  tobias9|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.5
 Severity:  Normal |   Keywords:  test mysql databases
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 I am trying to run tests against my django project prior to creating the
 "real" database used by my project.  The database should not be necessary
 to exist to simply run tests, as it will create a test db named test_*
 (test_mydb in my example).  This is really for the purposes of running
 tests in a Bamboo (or other CI) environment.  This is on both a Linux Mint
 15 desktop and a Ubuntu 13.04 Amazon Elastic Bamboo instance running
 Python 2.7.4, Django 1.5.4, and MySQL 5.5.32.

 MySQL database as specified in my settings.py:


 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql',
 'NAME': 'mydb',
 'USER': 'django',
 'PASSWORD': 'topsecret',
 'HOST': '',
 'PORT': '',
 }
 }
 }}}


 Running the tests generates the following error/traceback (again, I have
 not created the database named 'mydb' at this point):

 {{{
 > python manage.py test --traceback

 Creating test database for alias 'default'...
 Traceback (most recent call last):
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/management/base.py", line 222, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/management/commands/test.py", line 72, in execute
 super(Command, self).execute(*args, **options)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/management/base.py", line 255, in execute
 output = self.handle(*args, **options)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/management/commands/test.py", line 89, in handle
 failures = test_runner.run_tests(test_labels)
   File "/usr/local/lib/python2.7/dist-packages/django/test/simple.py",
 line 370, in run_tests
 old_config = self.setup_databases()
   File "/usr/local/lib/python2.7/dist-packages/django/test/simple.py",
 line 315, in setup_databases
 self.verbosity, autoclobber=not self.interactive)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/creation.py", line 281, in create_test_db
 self._create_test_db(verbosity, autoclobber)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/creation.py", line 343, in _create_test_db
 cursor = self.connection.cursor()
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/__init__.py", line 326, in cursor
 cursor = util.CursorWrapper(self._cursor(), self)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/mysql/base.py", line 406, in _cursor
 self.connection = Database.connect(**kwargs)
   File "/usr/lib/python2.7/dist-packages/MySQLdb/__init__.py", line 81, in
 Connect
 return Connection(*args, **kwargs)
   File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line
 187, in __init__
 super(Connection, self).__init__(*args, **kwargs2)
 OperationalError: (1049, "Unknown database 'mydb'")
 }}}


 Now, if I simply create the database 'mydb' without running syncdb (and/or
 migrate with south integration), the tests can run:

 {{{
 > mysqladmin --user=root --password=veryverysecret create mydb
 }}}


 and then run the same command above it works:

 {{{
 > python manage.py test --traceback

 Creating test database for alias 'default'...
 
..s..x...
 --
 Ran 481 tests in 28.853s

 OK (skipped=1, expected failures=1)
 Destroying test database for alias 'default'...
 }}}

-- 
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/dja

[Django] #21276: Bad link

2013-10-16 Thread Django

#21276: Bad link
---+
 Reporter:  radiotipo@…|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I was trying to reach the "logo standards" so I could find out how to
 apply your trademark to a design about a Django Course, but in the way I
 found this URL which looks like totally wrong:

 
https://www.djangoproject.com/trademarks/%3EDjango%20Trademark%20Licensing%20Agreement%3C/a%3E%20and%20%3Ca%20href=

 Please let me know if there is another way around to get that document,
 thanks a lot!

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

[Django] #21275: Cannot use migrations if model field specifies validators

2013-10-16 Thread Django

#21275: Cannot use migrations if model field specifies validators
--+
   Reporter:  timo|  Owner:
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 My assumption is that we shouldn't try to serialize the `validators`
 attribute.

 Traceback:
 {{{
   File "/home/tim/.virtualenvs/foo/local/lib/python2.7/site-
 packages/django/db/migrations/writer.py", line 185, in serialize
 raise ValueError("Cannot serialize: %r" % value)
 ValueError: Cannot serialize: 
 }}}

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

Re: [Django] #7836: django.test.client._session should check for session middleware instead

2013-10-16 Thread Django

#7836: django.test.client._session should check for session middleware instead
---+
 Reporter:  trevor |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 unaizalakain):

 I'm probably missing something, where's the need of checking if some kind
 of session middleware exists? If not present, wouldn't ``{}`` be returned
 anyways?

 BTW, shouldn't it be better if the engine module import happen outside
 ``_session`` and instead of checking for ``if coockie`` ``if cookie is not
 None`` is checked?

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

Re: [Django] #21224: TypedChoiceField does not properly coerce 'None' in certain circumstances

2013-10-16 Thread Django

#21224: TypedChoiceField does not properly coerce 'None' in certain 
circumstances
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 This may be addressed in master (1.7) with #20649 - could you take a look
 and see if that meets your use case?

-- 
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.360613ec261488b361bc3966837be949%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21274: django-admin's --template option fails to download from https via proxy

2013-10-16 Thread Django

#21274: django-admin's --template option fails to download from https via proxy
---+--
 Reporter:  blueyed|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  master
 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 timo):

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


Comment:

 Do you have a suggested fix (or an idea of how complex the fix might be)?
 Depending on the answer, it may be more effort than it's worth to maintain
 this code in Django - I'm unfamiliar with Squid so I could be completely
 wrong. One could also download the zip using something like wget and then
 use a local path to the zip file, right?

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

Re: [Django] #18400: Unexpected {% if %} behavior

2013-10-16 Thread Django

#18400: Unexpected {% if %} behavior
--+
 Reporter:  apollo13  |Owner:  susan
 Type:  Bug   |   Status:  assigned
Component:  Template system   |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  template, if, length  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by anonymous):

 Thanks you susan

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

Re: [Django] #21242: Allow more IANA schemes in URLValidator

2013-10-16 Thread Django

#21242: Allow more IANA schemes in URLValidator
--+
 Reporter:  saschpe   |Owner:  saschpe
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by saschpe):

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


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

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

Re: [Django] #21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static files

2013-10-16 Thread Django

#21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static 
files
-+
 Reporter:  dblack+django@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  Version:  master
 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
-+

Comment (by timo):

 Rather than adding a setting for this (we are trying to avoid settings),
 should we instead suggest subclassing the `STATICFILES_STORAGE` class and
 overriding the new `permissions_mode` attribute this patch offers?

-- 
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/085.0270623495f16e0bfd05462b45ed6774%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17235: Multipartparser shouldn't leave the QueryDict mutable

2013-10-16 Thread Django

#17235: Multipartparser shouldn't leave the QueryDict mutable
---+
 Reporter:  apollo13   |Owner:  hirokiky
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by claudep):

 #18553 was marked as a duplicate

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

Re: [Django] #18553: Django multipart parser creates mutable QueryDict

2013-10-16 Thread Django

#18553: Django multipart parser creates mutable QueryDict
---+-
 Reporter:  k_bx   |Owner:  fred
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 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 claudep):

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


Comment:

 Duplicate of #17235

-- 
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.6dd53054f9105537bb05e8fd40e2a1a8%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18659: Remove `request.REQUEST`

2013-10-16 Thread Django

#18659: Remove `request.REQUEST`
--+
 Reporter:  aaugustin |Owner:  bouke
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  HTTP handling |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timo):

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


Comment:

 Mailing list thread to make sure there is consensus to move forward with
 this:
 https://groups.google.com/d/topic/django-developers/yw7OPb_O0QA/discussion

 The patch would also need to be updated to reflect the fact that the
 deprecation would start in 1.7 (1.6 is feature frozen at this time).

-- 
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.924725451f0f96e5329de9a59aef251d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21271: Django's usage of smtplib.SMTP should have a timeout

2013-10-16 Thread Django

#21271: Django's usage of smtplib.SMTP should have a timeout
--+
 Reporter:  edevil|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Mail)   |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  smtp timeout  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by edevil):

 Can't you use the global_setting in assertEqual(), so that the value isn't
 hardcoded?

 As for the backend, currently send_messages() already skips close() when
 _send() throws an exception. But in the case of timeouts, smtplib
 automatically closes the underlying connection.

-- 
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.05e549d469e60e924e94d666d28c28ff%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 3918ee: Fixed #7551 -- Made GFK allow None init argument.

2013-10-16 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3918eeb9fde03a2ad1941bce022615fff8eae34d
  
https://github.com/django/django/commit/3918eeb9fde03a2ad1941bce022615fff8eae34d
  Author: Bouke Haarsma 
  Date:   2013-10-16 (Wed, 16 Oct 2013)

  Changed paths:
M django/contrib/contenttypes/generic.py
M tests/generic_relations/models.py
M tests/generic_relations/tests.py

  Log Message:
  ---
  Fixed #7551 -- Made GFK allow None init argument.

Thanks SamBull for the report.



-- 
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/525e72acf216_629b126bd485792c%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #7551: GenericForeignKey fails if initialized to None during model init

2013-10-16 Thread Django

#7551: GenericForeignKey fails if initialized to None during model init
-+-
 Reporter:  SamBull  |Owner:  bouke
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  contrib.contenttypes   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  contenttypes |  Needs documentation:  0
  genericforeignkey  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"3918eeb9fde03a2ad1941bce022615fff8eae34d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3918eeb9fde03a2ad1941bce022615fff8eae34d"
 Fixed #7551 -- Made GFK allow None init argument.

 Thanks SamBull for the report.
 }}}

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

[django/django] 763ac8: First pass on squashmigrations command; files are ...

2013-10-16 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 763ac8b642bc21b5a05c0d540c962804b36454ec
  
https://github.com/django/django/commit/763ac8b642bc21b5a05c0d540c962804b36454ec
  Author: Andrew Godwin 
  Date:   2013-10-16 (Wed, 16 Oct 2013)

  Changed paths:
M django/core/management/commands/migrate.py
A django/core/management/commands/squashmigrations.py
M django/db/migrations/loader.py
M django/db/migrations/writer.py

  Log Message:
  ---
  First pass on squashmigrations command; files are right, execution not.



-- 
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/525e71f656caf_4c96bd7d4c100372%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18160: Auth - Unknown Encoding Error when syncdb

2013-10-16 Thread Django

#18160: Auth - Unknown Encoding Error when syncdb
--+-
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  duplicate
 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 claudep):

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


Comment:

 Was fixed in #19933

-- 
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.438032484312f9a76badd318909f1109%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 42f866: Improve migration optimizer to be able to optimize...

2013-10-16 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 42f8666f6aed126d9606e00688087a76dd17afc6
  
https://github.com/django/django/commit/42f8666f6aed126d9606e00688087a76dd17afc6
  Author: Andrew Godwin 
  Date:   2013-10-16 (Wed, 16 Oct 2013)

  Changed paths:
M django/db/migrations/operations/base.py
M django/db/migrations/operations/models.py
M django/db/migrations/optimizer.py
M tests/migrations/test_optimizer.py

  Log Message:
  ---
  Improve migration optimizer to be able to optimize through other ops



-- 
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/525e66087163e_615e13f9d5430662%40hookshot-fe6-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17149: MediaDefiningClass not used as base class for other form meta classes

2013-10-16 Thread Django

#17149: MediaDefiningClass not used as base class for other form meta classes
--+
 Reporter:  bradley.ayers@…   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Forms |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 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 claudep):

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


Comment:

 Fixed by [ac5ec7b8bcc5623cc05d4df900c39e194f5affcf].

-- 
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/081.db62507d7f8de06710bee98626662afb%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21273: Add read only support for Oracle XE to django.contrib.gis

2013-10-16 Thread Django

#21273: Add read only support for Oracle XE to django.contrib.gis
-+-
 Reporter:  vinhussey|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  GIS  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vinhussey):

 = Example model =

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

 class Floods(models.Model):
 flood_id = models.IntegerField(primary_key=True)
 ...
 geoloc = models.TextField(blank=True)
 }}}

 = Settings =

 This example used django core, not django.contrib.gis
 settings.py
 {{{
 DATABASES = {
 'remote': {
 'ENGINE': 'django.db.backends.oracle', # Add
 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
 'NAME': 'XE',  # Or path to database file if
 using sqlite3.
 ...
 },
 }}}

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

Re: [Django] #21273: Add read only support for Oracle XE to django.contrib.gis

2013-10-16 Thread Django

#21273: Add read only support for Oracle XE to django.contrib.gis
-+-
 Reporter:  vinhussey|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  GIS  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vinhussey):

 = Polygon example =

 {{{
 >>> from import_data.models import *
 >>> f = Floods.objects.get(flood_id=305)
 >>> g = f.geoloc
 >>> g
 
 >>> dir(g)
 ['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__',
 '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__',
 '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
 'type']
 >>> gtype = str(int(g.__getattribute__('SDO_GTYPE')))
 >>> print gtype
 2003
 >>> gdims = gtype[0]
 >>> gdims
 '2'
 >>> gtopo = gtype[1]
 >>> gtopo
 '0'
 >>> ggeomtype = gtype[2:]
 >>> ggeomtype
 '03'
 >>> gsrid = g.__getattribute__('SDO_SRID')
 >>> gsrid
 82086.0
 >>> gpoint_x = g.__getattribute__('SDO_POINT').X
 >>> gpoint_y = g.__getattribute__('SDO_POINT').Y
 >>> gpoint_z = g.__getattribute__('SDO_POINT').Z
 >>> print gpoint_x, gpoint_y, gpoint_z
 158775.736744 155058.070105 None
 >>> print g.__getattribute__('SDO_ELEM_INFO')
 [1.0, 1003.0, 1.0]
 >>> print g.__getattribute__('SDO_ORDINATES')
 [158851.770034052, 155240.090599927, 158814.553479071, 155238.39040849303,
 158783.91910735102, 155236.430187781, 158758.984345447, 155234.259943421,
 158738.883116615, 155231.929681045, 158722.73284741, 155229.469404029,
 158709.667461087, 155226.92911800402, 158698.804384201, 155224.358828602,
 158689.277540007, 155221.79854032502, 158680.352825359, 155219.268255426,
 158671.914763359, 155216.767973906, 158663.96335400498, 155214.267692386,
 158656.539839049, 155211.747408614, 158649.652466839, 155209.197121463,
 158643.32598242702, 155206.57682643, 158637.58513086, 155203.866521262,
 158632.438160491, 155201.056204833, 158627.918064717, 155198.11587376602,
 158624.04958859, 155195.035526933, 158620.865725509, 155191.805163209,
 158618.39946887302, 155188.424782593, 158616.692060433, 155184.874382835,
 158615.768245238, 155181.153963933, 158615.652768339, 155177.253524761,
 158616.395119835, 155173.17306532, 158618.003548075, 155168.882582232,
 158620.436811311, 155164.382075495, 158623.645419442, 155159.631540607,
 158627.55513731902, 155154.61097531402, 158632.12472319198,
 155149.29037623902, 158637.28819026198, 155143.659742256,
 158642.98780007902, 155137.689069986, 158649.174062542,
 155131.33835492402, 158655.789239203, 155124.62759932398,
 158662.800336662, 155117.58680656302, 158670.166113169,
 155110.32598902902, 158677.853575324, 155102.895152351, 158685.846226427,
 155095.384306664, 158694.094576378, 155087.863459851, 158702.573880129,
 155080.42262204702, 158711.24289592798, 155073.131801134,
 158720.07687872602, 155066.061004995, 158728.98509667302,
 155059.20023250402, 158737.893314621, 155052.539482534, 158746.727297419,
 155046.078755086, 158755.388064868, 155039.788046781, 158763.809630169,
 155033.677358746, 158771.901261471, 155027.716687602, 158779.58872362602,
 155021.896032223, 158786.80602983403, 155016.205391483, 158793.569676794,
 155010.604760877, 158799.912657907, 155005.064137029, 158805.876214922,
 154999.54351543201, 158811.493341239, 154994.002891583, 158816.805278607,
 154988.41226210402, 158821.853268778, 154982.73162249, 158826.66205679902,
 154976.930969363, 158831.289381122, 154970.970298219, 158835.77648349598,
 154964.859610184, 158840.19759907, 154958.60890638301, 158844.626962994,
 154952.228187944, 158849.11406536802, 154945.737457118, 158853.73314134,
 154939.136713904, 158858.55017771202, 154932.45596168202,
 158863.631161282, 154925.695200452, 158869.009085451, 154918.884433591,
 158874.650956818, 154912.14367461202, 158880.474291883, 154905.612939281,
 158886.42135219803, 154899.42224223702, 158892.417902613,
 154893.70159811902, 158898.397956328, 154888.581021566, 158904.279029843,
 154884.220530595, 158910.00338471, 154880.730137593, 158915.488537428,
 154878.219854946, 158920.61076274802, 154876.67968153, 158925.22159037,
 154876.05961171302, 158929.180798347, 154876.329642117,
 158932.36466142803, 154877.41976486, 158934.624709315, 154879.30997768903,
 158935.812471708, 154881.930272722, 158935.812471708, 154885.260647707,
 158934.525729116, 154889.23109476102, 158932.11721093, 154893.79160825402,
 158928.80962259902, 154898.86217917703, 158924.825669573,
 154904.3828007

Re: [Django] #21273: Add read only support for Oracle XE to django.contrib.gis

2013-10-16 Thread Django

#21273: Add read only support for Oracle XE to django.contrib.gis
-+-
 Reporter:  vinhussey|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  GIS  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vinhussey):

 = Correction to WKT in example =

 {{{
 >>> g_ewkt = "SRID=%s;POINT(%f %f)" %
 (str(int(g.__getattribute__('SDO_SRID'))),
 g.__getattribute__('SDO_POINT').X, g.__getattribute__('SDO_POINT').Y)
 >>> g_ewkt
 'SRID=82086;POINT(162913.389524 340748.357977)'
 }}}

 = Note on SRID =
 Before version 10, Oracle used it's own SRIDs.  The sample is Irish Grid
 1965, this corresponds to EPSG:29903.

-- 
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.53540c223341d2ddf4d0ef326f4bf157%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21273: Add read only support for Oracle XE to django.contrib.gis

2013-10-16 Thread Django

#21273: Add read only support for Oracle XE to django.contrib.gis
-+-
 Reporter:  vinhussey|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  GIS  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vinhussey):

 * cc: vinhussey (added)
 * needs_docs:   => 1
 * version:  1.4 => master
 * needs_tests:   => 1
 * needs_better_patch:   => 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/067.00c75ea6a03826ed409337fbb3701b27%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

72 matches

Mail list logo