date:20140314

Re: [Django] #22232: Template extends tag can cause recursion

2014-03-14 Thread Django

#22232: Template extends tag can cause recursion
-+--
 Reporter:  galedragon   |Owner:  Saidin7979
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.6
 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 Saidin7979):

 * cc: nathanrandal@… (added)


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

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

Re: [Django] #22232: Template extends tag can cause recursion

2014-03-14 Thread Django

Comment (by russellm):

Hrm. This is an interesting problem. On the one hand, it would be nice to
raise a humane error message, but if it's only going to catch the one-
level recursion case, I'm starting to wonder if it's worth the effort.
Adding a potentially expensive check to the top of every template load so
that you can present a nicer error message in the edge case of recursive
templates seems like too high a price to pay.

If we can't find an efficient way to catch the complex circular case, I'm
inclined to turn this into a documentation fix (ie. noting in the
discussion around extends that circular loops may cause stack overflow
errors).

One option might be to handle this at render time, rather than at load
time. If you put something in the context that tracks which templates have
been used, and you try to re-use a template name, that indicates a
circular loop, and you can raise an error. This should be relatively cheap
(a set lookup & insertion on each new template file used); as long as we
can find a clean place to track the data, it might suffice as a solution.

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

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

Re: [Django] #21989: AU locale has incorrect Day Of Week

2014-03-14 Thread Django

#21989: AU locale has incorrect Day Of Week
-+-
 Reporter:  russellm |Owner:
 Type:  Bug  |  Saidin7979
Component:   |   Status:  closed
  Internationalization   |  Version:  1.6
 Severity:  Normal   |   Resolution:  fixed
 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 Russell Keith-Magee ):

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


Comment:

 In [changeset:"bb2c58c70133b3a03437e7d45510b062cb31b36c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bb2c58c70133b3a03437e7d45510b062cb31b36c"
 Merge pull request #2430 from NathanRSmith/ticket_21989

 Fixed #21989 - Modified first day of week in AU locale.

 Although Australia is a signatory to ISO 8601, there's a lot of evidence
 to suggest that this is in the same category as "officially, the USA uses
 metric". See the ticket for supporting details.
 }}}

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

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

[django/django] cfbc88: Changed start of week for Australia to Sunday as r...

2014-03-14 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: cfbc887b2ca5824eaec1267864c6d6ed9df1a204
  
https://github.com/django/django/commit/cfbc887b2ca5824eaec1267864c6d6ed9df1a204
  Author: Nathan Smith 
  Date:   2014-03-14 (Fri, 14 Mar 2014)

  Changed paths:
M django/conf/locale/en_AU/formats.py

  Log Message:
  ---
  Changed start of week for Australia to Sunday as requested in 
https://code.djangoproject.com/ticket/21989


  Commit: bb2c58c70133b3a03437e7d45510b062cb31b36c
  
https://github.com/django/django/commit/bb2c58c70133b3a03437e7d45510b062cb31b36c
  Author: Russell Keith-Magee 
  Date:   2014-03-15 (Sat, 15 Mar 2014)

  Changed paths:
M django/conf/locale/en_AU/formats.py

  Log Message:
  ---
  Merge pull request #2430 from NathanRSmith/ticket_21989

Fixed #21989 - Modified first day of week in AU locale.

Although Australia is a signatory to ISO 8601, there's a lot of evidence to 
suggest that this is in the same category as "officially, the USA uses metric". 
See the ticket for supporting details.


Compare: https://github.com/django/django/compare/d22b291890c1...bb2c58c70133

-- 
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/5323ac5f3817b_6b06d83d44667e1%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22271: Providing initial SQL data

2014-03-14 Thread Django

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

Comment:

Well, strictly, I don't think there's anything that would stop you from
putting all your initial SQL for an app into the file for a single model.
The contents of initial SQL files aren't validated to make sure that they
only apply to a single model, so the code will "just run".

The only difference would be *when* the code is run; the model file you
choose to put the initial SQL in will determine the order in which it is
executed. During initial development, the initial SQL file for a
particular model won't be run unless that the table for that model has
been created.

On top of all that, initial SQL is a pattern that is an "emergency escape
hatch" - it's a way to handle the last 2% of use cases you can't hit with
Django itself. I'm not sure it's worth spending a whole lot of time
revamping initial SQL handling to support a slightly different
organisation of initial SQL content.

If you've got a particularly compelling use case that I've missed, please
start a discussion on django-developers.

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

Re: [Django] #21587: Make generic RedirectView default to permanent=False

2014-03-14 Thread Django

#21587: Make generic RedirectView default to permanent=False
--+
 Reporter:  wraus@…   |Owner:  Melevir
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:  redirect, view| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by kcphysics):

 Added deprecation warning for default change from True to False in the
 upcoming versions.

 Added documentation about the change to the docs.

 Added test to make sure that warnings are issued.

 Done in https://github.com/django/django/pull/2432

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

[django/django] d22b29: Fixed #22001 -- Ensure db_type is respected.

2014-03-14 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d22b291890c1736a40c0ad97448c7318df2eebb2
  
https://github.com/django/django/commit/d22b291890c1736a40c0ad97448c7318df2eebb2
  Author: Marc Tamlyn 
  Date:   2014-03-14 (Fri, 14 Mar 2014)

  Changed paths:
M AUTHORS
A django/contrib/gis/tests/migrations/migrations/0001_initial.py
A django/contrib/gis/tests/migrations/test_commands.py
M django/db/models/fields/__init__.py
A gis/tests/migrations/__init__.py 
b/django/contrib/gis/tests/migrations/__init__.py
A gis/tests/migrations/migrations/__init__.py 
b/django/contrib/gis/tests/migrations/migrations/__init__.py
M tests/field_subclassing/fields.py
M tests/field_subclassing/tests.py

  Log Message:
  ---
  Fixed #22001 -- Ensure db_type is respected.

db_parameters should respect an already existing db_type method and
return that as its type string. In particular, this was causing some
fields from gis to not be generated.

Thanks to @bigsassy and @blueyed for their work on the patch.

Also fixed #22260


-- 
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/53238439ce1ce_7010b09d34544c6%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22260: Custom model field: field.db_type not called for (initial) migration / docs wrong? (DurationField)

2014-03-14 Thread Django

#22260: Custom model field: field.db_type not called for (initial) migration / 
docs
wrong? (DurationField)
+--
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 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 Marc Tamlyn ):

 * resolution:  duplicate => fixed


Comment:

 In [changeset:"d22b291890c1736a40c0ad97448c7318df2eebb2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d22b291890c1736a40c0ad97448c7318df2eebb2"
 Fixed #22001 -- Ensure db_type is respected.

 db_parameters should respect an already existing db_type method and
 return that as its type string. In particular, this was causing some
 fields from gis to not be generated.

 Thanks to @bigsassy and @blueyed for their work on the patch.

 Also fixed #22260
 }}}

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

Re: [Django] #22001: GeoDjango (contrib.gis) does not create geometry columns in 1.7a2

2014-03-14 Thread Django

#22001: GeoDjango (contrib.gis) does not create geometry columns in 1.7a2
-+
 Reporter:  steko|Owner:  bigsassy
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Marc Tamlyn ):

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


Comment:

 In [changeset:"d22b291890c1736a40c0ad97448c7318df2eebb2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d22b291890c1736a40c0ad97448c7318df2eebb2"
 Fixed #22001 -- Ensure db_type is respected.

 db_parameters should respect an already existing db_type method and
 return that as its type string. In particular, this was causing some
 fields from gis to not be generated.

 Thanks to @bigsassy and @blueyed for their work on the patch.

 Also fixed #22260
 }}}

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

Re: [Django] #22232: Template extends tag can cause recursion

2014-03-14 Thread Django

#22232: Template extends tag can cause recursion
-+--
 Reporter:  galedragon   |Owner:  Saidin7979
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.6
 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
-+--

Comment (by Saidin7979):

 Pull Request: https://github.com/django/django/pull/2431

 This patch checks the template node list for self extension.

 During the exploration of this issue we noticed that there may be another
 case when a recursion error could occur.  This issue addresses the case
 when a template extends itself, but a circular extension could occur
 further up the ancestry.  Should I handle this case as well?  It is not
 immediately clear how I could do this efficiently.

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

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by merb):

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by merb):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 Oh thanks, i didn't saw the checks. Currently I was really busy.
 Btw. thanks for the quick fix. ;)

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

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

Re: [Django] #21989: AU locale has incorrect Day Of Week

2014-03-14 Thread Django

#21989: AU locale has incorrect Day Of Week
-+-
 Reporter:  russellm |Owner:
 Type:  Bug  |  Saidin7979
Component:   |   Status:  assigned
  Internationalization   |  Version:  1.6
 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
-+-

Comment (by Saidin7979):

 Pull Request: https://github.com/django/django/pull/2430

 ISO 8601 does say Monday is the start of the week for Australia, but if
 you decide you would like to have it be Sunday, here is a pull request for
 that.

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

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Baptiste Mispelon ):

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


Comment:

 In [changeset:"37f7f233f5f30c28ea60a7fbc272ffd296e2dbe1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="37f7f233f5f30c28ea60a7fbc272ffd296e2dbe1"
 Fixed #22272 -- Fixed regression in DecimalField when using
 decimal_places=0.

 Thanks to trac user merb 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/062.02ef02fb43009ed1152a7feeb3c54db3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 37f7f2: Fixed #22272 -- Fixed regression in DecimalField w...

2014-03-14 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 37f7f233f5f30c28ea60a7fbc272ffd296e2dbe1
  
https://github.com/django/django/commit/37f7f233f5f30c28ea60a7fbc272ffd296e2dbe1
  Author: Baptiste Mispelon 
  Date:   2014-03-14 (Fri, 14 Mar 2014)

  Changed paths:
M django/db/models/fields/__init__.py
M tests/field_deconstruction/tests.py

  Log Message:
  ---
  Fixed #22272 -- Fixed regression in DecimalField when using decimal_places=0.

Thanks to trac user merb 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/53233ba76e979_4ac38dbd3c500f2%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21466: override_settings(LOGIN_URL=…) does not work when not first test

2014-03-14 Thread Django

#21466: override_settings(LOGIN_URL=…) does not work when not first test
---+--
 Reporter:  jnns   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords:  settings   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by bacongobbler):

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


Comment:

 apologies, I forgot to add the output of my tests!

 {{{
 ./manage.py test api
 Creating test database for alias 'default'...
 ...F
 ==
 FAIL: test_auth (api.tests.test_auth.AuthTest)
 --
 Traceback (most recent call last):
   File "/api/tests/test_auth.py", line 64, in test_auth
 self.assertEqual(response.status_code, 403)
 AssertionError: 201 != 403

 --
 Ran 60 tests in 29.056s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 }}}

 When i modify the setting to `True` in settings.py, the test passes
 without failure.

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

Re: [Django] #21466: override_settings(LOGIN_URL=…) does not work when not first test

2014-03-14 Thread Django

#21466: override_settings(LOGIN_URL=…) does not work when not first test
---+--
 Reporter:  jnns   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.6
 Severity:  Normal |   Resolution:  invalid
 Keywords:  settings   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by matthewf@…):

 I think I'm hitting the same issue as well. In my project, I have set a
 variable called `REGISTRATION_ENABLED`. However, when I try to override
 this setting in my tests, it's never read. Changing the setting beforehand
 in my settings.py makes the test pass, however. This is how it's used in
 my tests:

 {{{
 def test_auth(self):
 """
 Test that a user can register using the API, login and logout
 """
 # test registration workflow
 submit = {
 'username': 'Otto',
 'password': 'password',
 'first_name': 'first_name',
 'last_name': 'last_name',
 'email': 'em...@email.com',
 'is_superuser': False,
 'is_staff': False,
 }
 url = '/api/auth/register'
 response = self.client.post(url, json.dumps(submit),
 content_type='application/json')
 self.assertEqual(response.status_code, 201)
 # test disabled registration
 with self.settings(REGISTRATION_ENABLED=False):
 submit['username'] = 'anothernewuser'
 response = self.client.post(url, json.dumps(submit),
 content_type='application/json')
 self.assertEqual(response.status_code, 403)
 }}}

 And the code block in my views:

 {{{
 class HasRegistrationAuth(permissions.BasePermission):
 """
 Checks to see if registration is enabled
 """
 def has_permission(self, request, view):
 return settings.REGISTRATION_ENABLED
 }}}

 Note that I'm using https://github.com/tomchristie/django-rest-framework
 in my application.

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


Comment:

 LGTM, fix and test are pretty straightforward.

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

[Django] #22273: No documentation for 1.0 or 1.1

2014-03-14 Thread Django

#22273: No documentation for 1.0 or 1.1
-+
 Reporter:  neil.suffield@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Documentation|Version:  1.1
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 The website gives the option to search for documentation on all the
 different versions of Django, but 1.0 and 1.1 documentation searches gives
 no results. There are also no table of results
 https://docs.djangoproject.com/en/1.1/contents/

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   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 bmispelon):

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


Comment:

 Actually, there are already checks in place to make sure `max_digits>0`
 and `decimal_places>=0`:
 
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L1342

 So I'm not sure I understand what comment:5 is referring to.

 I've got a patch with tests now ready for committing:
 
https://github.com/bmispelon/django/commit/37f7f233f5f30c28ea60a7fbc272ffd296e2dbe1
 Any objection to me pushing it?

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

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bmispelon):

 This patch only fixes the regression, but unless I'm mistaken, earlier
 versions of Django don't validate the value of `max_digits`, do they?

 This should be a separate ticket imho.

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by merb):

 * needs_better_patch:  0 => 1


Comment:

 Currently this patch needs improvement since:

 max_digits needs to be positive in the PostgreSQL documentation (I think
 in other databases this max_digits needs to be positive as well)

 http://www.postgresql.org/docs/9.3/static/datatype-numeric.html

 Also MySQL needs a positive value for max_digits aswell. Only
 decimal_places could be zero or positive.

 {{{
 http://www.postgresql.org/docs/9.3/static/datatype-numeric.html
 }}}

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

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


Comment:

 The following patch seems to fix the issue (you have to regenerate the
 migration file):
 {{{#!diff
 diff --git a/django/db/models/fields/__init__.py
 b/django/db/models/fields/__init__.py
 index 16a0700..dd88471 100644
 --- a/django/db/models/fields/__init__.py
 +++ b/django/db/models/fields/__init__.py
 @@ -1379,9 +1379,9 @@ class DecimalField(Field):

  def deconstruct(self):
  name, path, args, kwargs = super(DecimalField,
 self).deconstruct()
 -if self.max_digits:
 +if self.max_digits is not None:
  kwargs['max_digits'] = self.max_digits
 -if self.decimal_places:
 +if self.decimal_places is not None:
  kwargs['decimal_places'] = self.decimal_places
  return name, path, args, kwargs
 }}}

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

Re: [Django] #20422: makemessages ignores "ignore patterns"

2014-03-14 Thread Django

#20422: makemessages ignores "ignore patterns"
-+-
 Reporter:  nnseva   |Owner:  claudep
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.6
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  ignore,pattern   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by fdemmer):

 * status:  closed => new
 * needs_better_patch:  0 => 1
 * version:  1.5 => 1.6
 * resolution:  fixed =>


Comment:

 Unfortunately the assumption that "file NAME like these patterns, should
 be ignored" was not correct. According to the documentation the --ignore
 pattern should "ignore files or directories matching"
 (https://docs.djangoproject.com/en/1.6/ref/django-admin/#django-admin-
 option---ignore)

 The example given in the docs actually uses patterns with paths:

 {{{django-admin.py makemessages --locale=en_US --ignore=apps/*
 --ignore=secret/*.html}}}

 The applied patch breaks this behaviour by using {{{filename =
 os.path.basename(path)}}}

 Being able to exclude paths is important to eg. easily exclude certain
 apps in a project from translation.

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

 * stage:  Unreviewed => Accepted


Comment:

 I'm able to reproduce the issue using this simple model:
 {{{#!python
 class Foo(models.Model):
 foo = models.DecimalField(max_digits=7, decimal_places=0)
 }}}

 As noted, this works in 1.6 so the `release blocker` flag is warranted
 too.

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

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

Re: [Django] #19303: ModelAdmin.formfield_overrides is ignored for fields with choices

2014-03-14 Thread Django

#19303: ModelAdmin.formfield_overrides is ignored for fields with choices
-+-
 Reporter:  bendavis78   |Owner:
 Type:  Bug  |  LukaszBalcerzak
Component:  contrib.admin|   Status:  closed
 Severity:  Normal   |  Version:  1.5
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by claudep):

 This will be fixed in Django 1.7

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

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

Re: [Django] #19303: ModelAdmin.formfield_overrides is ignored for fields with choices

2014-03-14 Thread Django

#19303: ModelAdmin.formfield_overrides is ignored for fields with choices
-+-
 Reporter:  bendavis78   |Owner:
 Type:  Bug  |  LukaszBalcerzak
Component:  contrib.admin|   Status:  closed
 Severity:  Normal   |  Version:  1.5
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 This bug still occurs in 1.6

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

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

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:
 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 merb):

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

Re: [Django] #13809: FileField open method is only accepting 'rb' modes

2014-03-14 Thread Django

#13809: FileField open method is only accepting 'rb' modes
--+
 Reporter:  canassa   |Owner:
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  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 jetfix):

 I confirm this that this issue is still present in 1.5 =(

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

Re: [Django] #6103: tests/model_forms/tests.py could use some rewriting

2014-03-14 Thread Django

#6103: tests/model_forms/tests.py could use some rewriting
--+
 Reporter:  mtredinnick   |Owner:  claudep
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Forms |  Version:  master
 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 Claude Paroz ):

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


Comment:

 In [changeset:"72cfbdc10ab53ee9a3a9f253f38e9919728c0813"]:
 {{{
 #!CommitTicketReference repository=""
 revision="72cfbdc10ab53ee9a3a9f253f38e9919728c0813"
 Fixed #6103 -- Splitted tests in model_forms tests
 }}}

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

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

[django/django] 72cfbd: Fixed #6103 -- Splitted tests in model_forms tests

2014-03-14 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 72cfbdc10ab53ee9a3a9f253f38e9919728c0813
  
https://github.com/django/django/commit/72cfbdc10ab53ee9a3a9f253f38e9919728c0813
  Author: Claude Paroz 
  Date:   2014-03-14 (Fri, 14 Mar 2014)

  Changed paths:
M tests/model_forms/models.py
M tests/model_forms/tests.py

  Log Message:
  ---
  Fixed #6103 -- Splitted tests in model_forms tests


  Commit: 666a2ad22ff868c214bf251d1171148d943cfc82
  
https://github.com/django/django/commit/666a2ad22ff868c214bf251d1171148d943cfc82
  Author: Claude Paroz 
  Date:   2014-03-14 (Fri, 14 Mar 2014)

  Changed paths:
M tests/model_forms/models.py
M tests/model_forms/tests.py
R tests/model_forms_regress/__init__.py
R tests/model_forms_regress/models.py
R tests/model_forms_regress/tests.py

  Log Message:
  ---
  Merged model_forms_regress with model_forms tests


Compare: https://github.com/django/django/compare/5a976b4bec79...666a2ad22ff8

-- 
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/5323100c85ca8_77e1a67d4010787a%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
-+-
 Reporter:  merb |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-2
 Severity:  Release blocker  |   Resolution:
 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 merb):

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


Comment:

 Django 1.6 will work and make the model to numeric(10, 0) even South
 worked like this and made it from numeric(10, X) to numeric(10, 0) if i
 changed the value.

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

[Django] #22272: model.DecimalField with decimal_places=0

2014-03-14 Thread Django

#22272: model.DecimalField with decimal_places=0
--+-
 Reporter:  merb  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7-alpha-2
 Severity:  Release blocker   |   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Currently I can't create DecimalField with decimal_places=0 on Postgresql
 with psycopg2 (sqlite3 works as expected)

 In PostgreSQL I can create numeric fields with a scale of zero:
 http://www.postgresql.org/docs/9.3/static/datatype-numeric.html

 But the current implementation disallows this: (The Exception I hit)

 {{{
 Running migrations:
   Applying envisia_article.0001_initial...DEBUG:django.db.backends:(0.002)
 SELECT c.relname
 FROM pg_catalog.pg_class c
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relkind IN ('r', 'v', '')
 AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 AND pg_catalog.pg_table_is_visible(c.oid); args=None
 DEBUG:django.db.backends.schema:CREATE TABLE
 "envisia_article_solderresist" ("id" serial NOT NULL PRIMARY KEY, "name"
 varchar(100) NULL, "name_en" varchar(100) NULL); (params [])
 DEBUG:django.db.backends:(0.003) CREATE TABLE
 "envisia_article_solderresist" ("id" serial NOT NULL PRIMARY KEY, "name"
 varchar(100) NULL, "name_en" varchar(100) NULL); args=[]
 DEBUG:django.db.backends.schema:CREATE TABLE
 "envisia_article_bestpressurecolor" ("id" serial NOT NULL PRIMARY KEY,
 "name" varchar(100) NULL, "name_en" varchar(100) NULL); (params [])
 DEBUG:django.db.backends:(0.001) CREATE TABLE
 "envisia_article_bestpressurecolor" ("id" serial NOT NULL PRIMARY KEY,
 "name" varchar(100) NULL, "name_en" varchar(100) NULL); args=[]
 DEBUG:django.db.backends.schema:CREATE TABLE "envisia_article_cuinside"
 ("id" serial NOT NULL PRIMARY KEY, "value" numeric(10, None) NOT NULL);
 (params [])
 DEBUG:django.db.backends:(0.001) CREATE TABLE "envisia_article_cuinside"
 ("id" serial NOT NULL PRIMARY KEY, "value" numeric(10, None) NOT NULL);
 args=[]
 Traceback (most recent call last):
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/db/backends/utils.py", line
 61, in execute
 return self.cursor.execute(sql, params)
 psycopg2.DataError: invalid input syntax for integer: "none"
 LINE 1: ...nside" ("id" serial NOT NULL PRIMARY KEY, "value" numeric(10...
  ^


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/core/management/__init__.py",
 line 427, in execute_from_command_line
 utility.execute()
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/core/management/__init__.py",
 line 419, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/core/management/base.py",
 line 287, in run_from_argv
 self.execute(*args, **options.__dict__)
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/core/management/base.py",
 line 336, in execute
 output = self.handle(*args, **options)
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-
 packages/Django-1.7a2-py3.3.egg/django/core/management/commands/migrate.py",
 line 145, in handle
 executor.migrate(targets, plan, fake=options.get("fake", False))
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/db/migrations/executor.py",
 line 60, in migrate
 self.apply_migration(migration, fake=fake)
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/db/migrations/executor.py",
 line 94, in apply_migration
 migration.apply(project_state, schema_editor)
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-packages/Django-1.7a2-py3.3.egg/django/db/migrations/migration.py",
 line 97, in apply
 operation.database_forwards(self.app_label, schema_editor,
 project_state, new_state)
   File
 "/Users/schmitch/Programme/virtualenv/envisia_dashboard/lib/python3.3
 /site-

Re: [Django] #22064: Invalid related_name passes silently

2014-03-14 Thread Django

#22064: Invalid related_name passes silently
-+-
 Reporter:  mondone  |Owner:  elhippie
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-
Changes (by elhippie):

 * owner:  mondone => elhippie
 * 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.496cae4f0bd9bb37d2df4859e8aa3c39%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21906: dumpdata should not use router.allow_syncdb

2014-03-14 Thread Django

#21906: dumpdata should not use router.allow_syncdb
-+-
 Reporter:  yscumc   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.5
  commands)  |   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 Twidi):

 * cc: Twidi (added)


Comment:

 As `dumpdata` is about reading data from the database, shouldn't the
 `db_for_read` method be called ?

 By the way, by having the exact same problem as described in this ticket,
 yes, this method's name is not relevant :)

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

Re: [Django] #22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url

2014-03-14 Thread Django

#22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url
-+
 Reporter:  meenzam@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by ienzam):

 Wrote a new patch -
 
https://github.com/ienzam/django/commit/c22ce94588243da76b01e064ca36c9e63b0b54a2

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

Re: [Django] #21798: Model validation should complain if both `add_now` and `auto_add_now` are specified.

2014-03-14 Thread Django

#21798: Model validation should complain if both `add_now` and `auto_add_now` 
are
specified.
-+-
 Reporter:  charettes|Owner:  anonymous
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by pirosb3):

 I think it would be more sensible to add DeprecationWarning first, and
 then field check later. In makes it more smoother. But the final call is
 up to you two :)
 I am willing to make the changes for the choice you make. Let me know.

 Dan

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

Re: [Django] #22242: Setting cookie that is too large fails silently

2014-03-14 Thread Django

#22242: Setting cookie that is too large fails silently
-+-
 Reporter:  Euphorbium   |Owner:
   |   Status:  new
 Type:  Bug  |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by erikr):

 * version:  1.6 => master
 * component:  HTTP handling => Documentation
 * easy:  0 => 1


Comment:

 Yes, please make a documentation patch.

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

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

Re: [Django] #21798: Model validation should complain if both `add_now` and `auto_add_now` are specified.

2014-03-14 Thread Django

Comment (by erikr):

Eh, pressed enter too soon there. Two more notes:

* If we also take `default` into account this warning, I definitely agree
with charettes that we should fix this. Particularly as the behaviour in
combination with `default` is a lot less obvious.
* There are basically two options here: we could issue a
DeprecationWarning, and add a field check in the next version, or just add
the field check now. We went for the latter in #20484, but that was a
little more severe: that actually broke in some conditions. If I
understand comment:9 correctly, charette is in favour of adding the check
now - I don't feel strongly either way.

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

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

Re: [Django] #21798: Model validation should complain if both `add_now` and `auto_add_now` are specified.

2014-03-14 Thread Django

Comment (by erikr):

Well, the decision of which option is enabled has already been made
implicitly by the code. If one sets both `auto_now_add` and `auto_now`,
the behaviour is identical to only providing `auto_now`. The warning could
indicate that. I'm sure a similar deterministic precedence is present for
`default`.

The warning could be something along the lines of (not polished): `The
combining of auto_now, auto_now_add and/or default paramaters of a ..field
is deprecated. X takes precedence over Y, which takes precedence over Z`.
Note also that there are three fields that have these parameters:
DateTimeField, DateField and TimeField, to my knowledge.

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

Re: [Django] #19802: HttpResponse.set_cookie doesn't handle unicode data

2014-03-14 Thread Django

#19802: HttpResponse.set_cookie doesn't handle unicode data
---+--
 Reporter:  django@…   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords:  cookie | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by semenov):

 * status:  closed => new
 * resolution:  worksforme =>
 * version:  1.4 => 1.5
 * type:  Uncategorized => Bug
 * cc: semenov@… (added)


Comment:

 This is still broken in 1.5. To reproduce the bug, use the experiment file
 below:
 {{{#!python
 # Put this in a file called experiment19802.py and run it with:
 # django-admin.py runserver --settings=experiment19802

 from django.conf.urls import patterns, url
 from django.http import HttpResponse

 DEBUG = True
 ROOT_URLCONF = 'experiment19802'
 SECRET_KEY = 'whatever'

 def view(request):
 res = HttpResponse('OK')
 res.set_cookie('test', request.GET.get('cookie', ''))
 return res

 urlpatterns = patterns('',
 url(r'.*', view),
 )
 }}}

 and try to open: http://localhost:8000/?cookie=M%C3%BCller

 It will raise the exception:
 {{{
 Traceback:
 File "/Users/semenov/work/xxx/venv/lib/python2.7/site-
 packages/django/core/handlers/base.py" in get_response
   115. response = callback(request,
 *callback_args, **callback_kwargs)
 File "/Users/semenov/tmp/19802/experiment19802.py" in view
   13.   res.set_cookie('test', request.GET.get('cookie', ''))
 File "/Users/semenov/work/xxx/venv/lib/python2.7/site-
 packages/django/http/response.py" in set_cookie
   157. self.cookies[key] = value
 File
 
"/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py"
 in __setitem__
   591. rval, cval = self.value_encode(value)
 File
 
"/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py"
 in value_encode
   680. strval = str(val)

 Exception Type: UnicodeEncodeError at /
 Exception Value: 'ascii' codec can't encode character u'\xfc' in position
 1: ordinal not in range(128)
 }}}

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

[Django] #22271: Providing initial SQL data

2014-03-14 Thread Django

#22271: Providing initial SQL data
--+
 Reporter:  yejia2000@…   |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.6
 Severity:  Normal|   Keywords:  intial sql
 Triage Stage:  Unreviewed|  data,
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 https://docs.djangoproject.com/en/1.6/howto/initial-data/#providing-
 initial-sql-data
 why I cannot put all sql of different models in one file? Sometime it is
 better put them in one file which makes the viewing and comparing easier.
 Also it might be some work to put them into each separate file.

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

42 matches

Mail list logo