date:20110919

Re: [Django] #16884: Add message level argument to ModelAdmin's message_user

2011-09-19 Thread Django

#16884: Add message level argument to ModelAdmin's message_user
+---
   Reporter:  shelldweller  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  admin
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+---

Comment (by shelldweller):

 It appears that CSS classes and images are already there.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16887: Allow Update/CreateView to have fields/exclude arguments

2011-09-19 Thread Django

#16887: Allow Update/CreateView to have fields/exclude arguments
---+---
   Reporter:  linovia  |  Owner:  linovia
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:  wontfix  |   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 russellm):

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


Comment:

 I can see what you're trying to do here; I'm just not convinced it's the
 right way to go. `exclude` isn't the only Meta argument for a form, so the
 end-game of what you're proposing is for UpdateView and CreateView to also
 accept all the arguments that ModelForm.meta can take.

 Personally, I put this down as a case for "Explict is better than
 implicit"; yes, it's slightly more typing to require an explicit form
 definition, but it's also very clear which arguments are form related, and
 which are view related. It also means that there's no potential for
 argument collision between the namespace for form arguments, and the
 namespace for view arguments.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16887: Allow Update/CreateView to have fields/exclude arguments

2011-09-19 Thread Django

#16887: Allow Update/CreateView to have fields/exclude arguments
---+---
   Reporter:  linovia  |  Owner:  linovia
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   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 linovia):

 * owner:  nobody => linovia


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16887: Allow Update/CreateView to have fields/exclude arguments

2011-09-19 Thread Django

#16887: Allow Update/CreateView to have fields/exclude arguments
---+---
   Reporter:  linovia  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   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 linovia):

 * needs_docs:   => 0
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16887: Allow Update/CreateView to have fields/exclude arguments

2011-09-19 Thread Django

#16887: Allow Update/CreateView to have fields/exclude arguments
-+---
 Reporter:  linovia  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Generic views
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  1|  Easy pickings:  0
UI/UX:  0|
-+---
 The general idea behind generic views is to ease the development.
 One of the issue I have found is that removing fields from the form leads
 to extra work by redefining another model form for that view.

 {{{
 class MilestoneForm(forms.ModelForm):
 class Meta:
 model = models.Milestone
 exclude = ('project', 'slug')

 class CreateMilestone(generic.CreateView):
 model = models.Milestone
 template_name_suffix = 's/new'
 form_class = MilestoneForm
 }}}

 whereas we could have a much simpler way:

 {{{
 class CreateMilestone(generic.CreateView):
 model = models.Milestone
 template_name_suffix = 's/new'
 exclude = ('project', 'slug')
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5446: New model fields for languages and countries at least

2011-09-19 Thread Django

#5446: New model fields for languages and countries at least
-+-
   Reporter:  Raphaël|  Owner:  marinho
  Hertzog | Status:  reopened
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  feature_request
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by windbottle):

 * cc: windbottle (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16886: Memcached socket file usage is undocumented

2011-09-19 Thread Django

#16886: Memcached socket file usage is undocumented
-+-
   Reporter:  ddbeck |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 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 carljm):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks great! Thanks for checking that out, and thanks for the
 contribution!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16886: Memcached socket file usage is undocumented

2011-09-19 Thread Django

#16886: Memcached socket file usage is undocumented
+---
   Reporter:  ddbeck|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  SVN   |   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 ddbeck):

 Thank you for the feedback. I tested it without the double `unix:` and it
 works appropriately. I updated the patch to remove the double `unix:` and
 to add the missing comma.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16886: Memcached socket file usage is undocumented

2011-09-19 Thread Django

#16886: Memcached socket file usage is undocumented
+---
   Reporter:  ddbeck|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  SVN   |   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 carljm):

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


Comment:

 Is the double unix: really required for this to work? I know it wasn't
 with the CACHE_BACKEND setting.

 Otherwise (with an added comma to clarify that the unix-path section is
 separate from the ip:port section) this looks good to me.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16886: Memcached socket file usage is undocumented

2011-09-19 Thread Django

#16886: Memcached socket file usage is undocumented
+---
 Reporter:  ddbeck  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Documentation
  Version:  SVN |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  1   |  Easy pickings:  0
UI/UX:  0   |
+---
 The [https://docs.djangoproject.com/en/dev/topics/cache/#memcached
 Memcached docs] do not describe how to use `CACHES` with Memcached and a
 Unix socket file. The most Google-able instructions, found in ticket
 #10168, do not apply the Django 1.3+ method of configuring caches.

 Such docs would be particularly useful to users in shared hosting
 environments, since Memcached does not provide any kind of authentication.
 With socket file permissions, such users can protect their instance of
 memcached from unauthorized use.

 Attached, you'll find my proposed addition to the docs to make this usage
 more discoverable.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16353: With multi-databases, if django.contrib.sites.models.Site is not synchronized on all databases, Django's tests fail

2011-09-19 Thread Django

#16353: With multi-databases, if django.contrib.sites.models.Site is not
synchronized on all databases, Django's tests fail
-+---
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Testing framework
Version:  1.3|   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  |
-+---

Comment (by aaugustin):

 The full test suite passes under SQLite (just a sanity check).

 Under Oracle, with the patch, I get this result:
 http://ci.myks.org/job/Django%20+%20Oracle/5/#showFailuresLink [[BR]]
 where the official CI server gets this: http://ci.django-
 cms.org/job/Django/database=oracle,python=python2.7/271/#showFailuresLink

 Both have 81 failures, so it isn't more broken with my patch than without.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16851: Accessing a forms field value in a template

2011-09-19 Thread Django

#16851: Accessing a forms field value in a template
-+---
   Reporter:  from_a_far@…   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   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 linovia):

 Actually, {{ form.apple.value }} will not be correct if value is None.
 {{ form.apple.value|default_if_none:"" }} is a better choice.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16878: Improve the "intword" filter

2011-09-19 Thread Django

#16878: Improve the "intword" filter
-+-
   Reporter:  crodjer|  Owner:  crodjer
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.humanize
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by crodjer):

 I understand this is not of much importance. I was going through the code
 and found this so wrote a quick patch.

 I have fixed the code to pass the translation regression tests and updated
 the tests to cover some new larger numbers. Also to make it look cleaner
 updated the code so that in the conversions list the exponent to 10 is
 specified instead of numbers with large number of zeroes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16353: With multi-databases, if django.contrib.sites.models.Site is not synchronized on all databases, Django's tests fail

2011-09-19 Thread Django

#16353: With multi-databases, if django.contrib.sites.models.Site is not
synchronized on all databases, Django's tests fail
-+---
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Testing framework
Version:  1.3|   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 aaugustin):

 * needs_tests:  1 => 0


Comment:

 This regression was introduced in r16027 (trunk) and r16028 (1.3.X). It
 was duplicated in GIS in r16749 (trunk) and r16751 (1.3.X).

 The goal was to fix #15573, a problem linked to the re-implementation of
 auto-incremented sequences (which was itself a regression, but at this
 point the history isn't relevant any longer). However, the "fix" doesn't
 look optimal: it introduces in the core some code that's specific to a
 contrib app (sites) and also this regression. Furthermore, it doesn't
 include any tests.

 Attached patch reverts r16027 and r16749, and proposes another fix for
 #15573, a much more simple and predictable one.

 Note that the `post_syncdb` signal is fired right after the tables are
 created or flushed, so there's no risk to overwrite an existing Site.

 

 I tested the patch manually with the procedure described in #16828.

 I'm still stuck writing automated tests. In fact, it's extremely difficult
 to test the initialization of the `django_site` table in the test
 databases, because of a chicken'n'egg problem. Since the table is created
 before the tests start running, we can't pull a trick like in
 `tests/modeltests/proxy_model_inheritance/tests.py`. I don't think hacking
 the internals of the app cache to deregister the app, drop the table and
 resync it is a good idea.

 Suggestions welcome. Otherwise, I hope we can revert a commit that didn't
 include tests and demonstrably broke stuff even if it's impossible to
 write automated tests for either behavior.

 Finally, note that the new changes are already covered by all the tests
 that fail when SITE_ID != 1 — see #15573.

 

 This patch must be backported to 1.3.X.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16885: django.test.testcases.connections_support_transactions always returns False if TEST_MIRROR is used

2011-09-19 Thread Django

#16885: django.test.testcases.connections_support_transactions always returns 
False
if TEST_MIRROR is used
---+---
 Reporter:  grimfandjango  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Testing framework
  Version:  SVN|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 If a project is set up with multiple databases, and at least one of the
 databases uses the TEST_MIRROR option,
 django.test.testcases.connections_support_transactions will always return
 False, forcing any tests inheriting from TestCase into the (substantially
 slower) TransactionTestCase mode.

 Example: take the test case:


 {{{
 class TestTest(TestCase):
 def test_connections_support_transactions(self):
 import django.test.testcases
 self.assertTrue(django.test.testcases.connections_support_transactions())
 }}}


 and the database setup:


 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': '/tmp/foo.db',  # Or path to database
 file if using sqlite3.
 }
 }
 }}}


 Test output:


 {{{
 Creating test database for alias 'default'...
 .
 --
 Ran 1 test in 0.000s

 OK
 }}}


 Switch to:


 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': '/tmp/foo.db',  # Or path to database
 file if using sqlite3.
 },
 'reporting': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': '/tmp/foo2.db',
 'TEST_MIRROR': 'default',
 }
 }
 }}}


 Test output:


 {{{
 FAIL: test_connections_support_transactions
 (foo.testit.tests.TestTest)
 --
 Traceback (most recent call last):
   File "/../venvs/django_svn/foo/../foo/testit/tests.py", line 15, in
 test_connections_support_transactions
 self.assertTrue(django.test.testcases.connections_support_transactions())
 AssertionError: False is not True

 }}}

 The same problem occurs with the MySQL backend if configured analogously.

 The underlying issue is that in ''conn.features.supports_transactions for
 conn in connections.all()'' in connections_support_transactions,
 ''conn.features.supports_transactions'' is ''None'' for the alias.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16878: Improve the "intword" filter

2011-09-19 Thread Django

#16878: Improve the "intword" filter
-+-
   Reporter:  crodjer|  Owner:  crodjer
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.humanize
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * needs_better_patch:   => 1
 * version:  1.3 => SVN
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Accepting, though I think this is pretty low priority.

 There should be tests added to cover the newly-supported bigger numbers,
 but they should go in `regressiontests/humanize/tests.py` with the
 existing intword 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16873: removal of deprecated settings.DATABASE code causes shell scripts to raise ImproperlyConfigured

2011-09-19 Thread Django

#16873: removal of deprecated settings.DATABASE code causes shell scripts to 
raise
ImproperlyConfigured
-+-
   Reporter:  ptone  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Release blocker
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by carljm):

 * severity:  Normal => Release blocker


Comment:

 Regression, bumping to release blocker.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8408: add a new meta option: don't do count(*) in admin

2011-09-19 Thread Django

#8408: add a new meta option: don't do count(*) in admin
-+-
   Reporter:  lidaobing  |  Owner:  nobody
   Type:  New| Status:  reopened
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by charles@…):

 This is not just MySQL. PostgreSQL has a separate query for cheap, inexact
 counts (with statistics collected during the most recent ANALYZE) -- but
 exact counts are expensive; I have a table where a `SELECT COUNT(*)` is
 typically running upward of 50 seconds.

 Perhaps on PostgreSQL we could run a query like `select reltuples from
 pg_class where relname=?;`, and use the traditional pagination system if
 the result is under 20,000 or so, or a newer one otherwise?

 See also http://wiki.postgresql.org/wiki/Slow_Counting

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16884: Add message level argument to ModelAdmin's message_user

2011-09-19 Thread Django

#16884: Add message level argument to ModelAdmin's message_user
+---
   Reporter:  shelldweller  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  admin
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+---
Changes (by Alex):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Uncategorized => contrib.admin
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16884: Add message level argument to ModelAdmin's message_user

2011-09-19 Thread Django

#16884: Add message level argument to ModelAdmin's message_user
--+---
 Reporter:  shelldweller  |  Owner:  nobody
 Type:  New feature   | Status:  new
Milestone:|  Component:  Uncategorized
  Version:  SVN   |   Severity:  Normal
 Keywords:  admin |   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  1
UI/UX:  1 |
--+---
 I think it would be really nice to extend message_user method to allow
 warning and error messages to be output by admin actions.
 So in
 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L675
 method signature would change as follows:

 {{{
 - def message_user(self, request, message):
 + def message_user(self, request, message, level=INFO):
 }}}

 Semantics and look-n-feel:

 * DEBUG, INFO, SUCCESS: Admin action completed successfully; shows the
 green checkbox image (same as for representing True)
 * ERROR: Admin action did not complete; shows the stop sign image (same as
 for False)
 * WARNING: Admin action completed but not as smooth as expected; perhaps
 there should be a new icon for this (white question mark on red circle?)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16875: db.model.FileField's close method doesn't close

2011-09-19 Thread Django

#16875: db.model.FileField's close method doesn't close
-+---
   Reporter:  arthur78@… |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Uncategorized
Version:  1.3|   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by carljm):

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


Comment:

 Lines 124-127 in
 
[https://code.djangoproject.com/browser/django/trunk/django/db/models/fields/files.py#L124
 django/db/models/fields/files.py] certainly seems to define a close method
 that ought to work. (The object that you get when you access a `FileField`
 from a model instance is actually `FieldFile`). Closing "needsinfo"
 pending more detailed reproduction instructions.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16873: removal of deprecated settings.DATABASE code causes shell scripts to raise ImproperlyConfigured

2011-09-19 Thread Django

#16873: removal of deprecated settings.DATABASE code causes shell scripts to 
raise
ImproperlyConfigured
-+-
   Reporter:  ptone  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 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:  0
-+-
Changes (by carljm):

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


Comment:

 I think this side-effect of the back-compat shim was actually accidental:
 it seems pretty clear from `django/db/__init__.py` that the intention of
 that code was to immediately raise `ImproperlyConfigured` if there was no
 default database.

 Nevertheless, I just discussed this with Alex and we agree that the
 accidental 1.3 behavior is actually preferable to the current trunk
 behavior. Raising `ImproperlyConfigured` at import time sucks and should
 be avoided whenever possible, and in this case we can avoid it, by setting
 up a "default" database for you, using the dummy backend, if you have no
 databases defined. The dummy backend will still error if you try to use
 it, but that's much better than an import-time error (especially since
 many parts of Django import the ORM, its hard to predict which those are,
 and it could change between releases).

 If the user does have databases defined, but no "default" one, that case
 should be better handled than it is now, but not by creating a dummy
 default. That issue is tracked by #16752.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16883: Importing models.py from not-installed app prevents any other app with that label from loading

2011-09-19 Thread Django

#16883: Importing models.py from not-installed app prevents any other app with 
that
label from loading
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Milestone:   |Component:  Database
  Version:  SVN  |  layer (models, ORM)
 Keywords:   | Severity:  Normal
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
 If a models.py from an app that is not listed in INSTALLED_APPS happens to
 be imported for whatever reason, that (not-installed) app takes over the
 app-label in the app cache, making it impossible for any app actually in
 INSTALLED_APPS to use that app-label. This is wrong - an import should not
 have such a side effect. INSTALLED_APPS should be the arbiter of what apps
 are actually found in the app cache.

 The fix for #16283 worked around this problem and removed the immediate
 symptom, but didn't address the underlying issue.

 The fix for #15866 addressed a similar issue, but didn't fix this.

 This may be fixed in the app-loading branch, and in any case is closely-
 related to the changes there.

 Attached tarball is a simplest-case settings.py and app demonstrating the
 issue; run "manage.py validate" to see the problem. The models from
 contrib.auth are being validated even though that app is not installed,
 simply because its models.py has been imported. The presence of another
 INSTALLED_APP with the "auth" app-label causes the app cache to be
 confused into thinking that contrib.auth is actually installed, when it is
 not.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16882: Clarify in the doc why one should not use 'init_command' after initial database creation

2011-09-19 Thread Django

#16882: Clarify in the doc why one should not use 'init_command' after initial
database creation
-+-
 Reporter:  julien   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:
Milestone:   |  Documentation
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
 In `[1]`, the doc says in regards to the 'init_command' DATABASES
 settting's option, "After your tables have been created, you should remove
 this option", presumably for performance reasons. These reasons should be
 clarified.

 `[1]` https://docs.djangoproject.com/en/dev/ref/databases/#creating-your-
 tables

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4528: Add DATABASE_PRE_SYNCDB to settings

2011-09-19 Thread Django

#4528: Add DATABASE_PRE_SYNCDB to settings
-+-
   Reporter:  Johan  |  Owner:  Silver_Ghost
  Bergström  | Status:  assigned
   Type:  New|  Component:  Core (Management
  feature|  commands)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  database_pre_syncdb
 Resolution: |  sql syncdb
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by Silver_Ghost):

 * cc: Silver_Ghost (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4528: Add DATABASE_PRE_SYNCDB to settings

2011-09-19 Thread Django

#4528: Add DATABASE_PRE_SYNCDB to settings
-+-
   Reporter:  Johan  |  Owner:  Silver_Ghost
  Bergström  | Status:  assigned
   Type:  New|  Component:  Core (Management
  feature|  commands)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  database_pre_syncdb
 Resolution: |  sql syncdb
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by Silver_Ghost):

 * owner:  nobody => Silver_Ghost
 * status:  new => assigned
 * needs_tests:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4574: add CSS classes to rendered calendar

2011-09-19 Thread Django

#4574: add CSS classes to rendered calendar
-+-
   Reporter:  calvin@…   |  Owner:  xian
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  newforms-  |   Keywords:  nfa-someday
  admin  |  javascript admin
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-
Changes (by Silver_Ghost):

 * cc: Silver_Ghost (added)
 * needs_better_patch:  1 => 0
 * keywords:  nfa-someday => nfa-someday javascript admin
 * needs_tests:  1 => 0
 * easy:  0 => 1


Comment:

 ''fcurella'', your patch completely does not work for me.  I've attached
 working one.

 Also there is no way to testing Javacript since it need special
 instruments such as Selenium.  Django has only server-side tests at the
 moment.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself

2011-09-19 Thread Django

#16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself
-+-
   Reporter:  Gumnos |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  SHORT_DATETIME_FORMAT
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-

Comment (by julien):

 Yes you are correct. Thanks for contributing!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16820: CheckboxInput.value_from_datadict with '0'

2011-09-19 Thread Django

#16820: CheckboxInput.value_from_datadict with '0'
--+
   Reporter:  danfairs|  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Forms
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+

Comment (by danfairs):

 To my knowledge, no browser sends '0'. We discovered this while testing
 our
 API against various (custom) clients, some of which didn't behave quite as
 we'd asked, and sent '0'.

 We're reusing our web forms for the API to do data validation, wherever
 possible.

 The current behaviour led to a surprising - to our eyes - situation where
 you could have code like this (abridged from our internal test suite):

 {{{
 class FlagModel(models.Model):
 flag = models.BooleanField()


 class DefaultModelForm(forms.ModelForm):
 # This form will get an auto-generated BooleanField, which uses
 # the CheckboxInput widget.
 class Meta:
 model = FlagModel

 def clean(self):
 # Now, because BooleanField.to_python knows about '0',
 # cleaned_data actually contains False. '0' and '1' can
 # be posted by RadioSelect widgets.
 cleaned_data = super(DefaultModelForm, self).clean()
 if cleaned_data.get('flag') != False:
 raise forms.ValidationError(u'Flag must be false!')
 return cleaned_data


 class CheckTestCase(TestCase):

 def setUp(self):
 self.m = FlagModel.objects.create(flag=True)

 def test_checkbox(self):
 formset_class = forms.models.modelformset_factory(
 FlagModel,
 max_num=1,
 form=DefaultModelForm
 )
 formset = formset_class({
 'form-INITIAL_FORMS': '1',
 'form-TOTAL_FORMS': '1',
 'form-0-id': str(self.m.pk),
 'form-0-flag': '0',
 }, queryset=FlagModel.objects.all())

 # Before the patch is applied, formset.is_valid() will return
 # True - with the implication that the flag field has been
 # checked and has been set to False
 #self.assertFalse(formset.is_valid())

 # Since the form validates, flag should be false... right?
 formset.save()
 m = FlagModel.objects.get(pk=self.m.pk)

 # To our surprise, m.flag actually turns out to be True at this
 point,
 # so this assertion fails.
 self.assertFalse(m.flag)
 }}}

 What made this more confusing was that other fields on the real model
 actually
 did save.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16881: db.backends.util.format_number fails with valid inputs

2011-09-19 Thread Django

#16881: db.backends.util.format_number fails with valid inputs
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+---
 We see the error "quantize result has too many digits for current context"
 when using a DecimalField with max_digits=7 decimal_places=2 ie the
 following call fails

 format_number(Decimal('914123.22'), 7, 2)

 I believe this is due to the statement

 context.prec = max_digits

 whereas I think it should be

 context.prec = max_digits+decimal_places

 but I am not sure.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16880: Missing tags 1.2.6, 1.2.7 and 1.3.1 at github

2011-09-19 Thread Django

#16880: Missing tags 1.2.6, 1.2.7 and 1.3.1 at github
-+---
   Reporter:  vzima  |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Uncategorized
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   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 jezdez):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => fixed
 * needs_tests:   => 0
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself

2011-09-19 Thread Django

#16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself
-+-
   Reporter:  Gumnos |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  SHORT_DATETIME_FORMAT
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-

Comment (by Tim Chase ):

 I modified the right one in my local git repo (the documentation for
 SHORT_DATETIME_FORMAT should cross-reference SHORT_DATE_FORMAT; appearing
 before SITE_ID as shown in the diff), but I suspect that the diff may have
 had sufficiently ambiguous context to pinpoint the right cross-reference.
 Either way, I'm glad to have it fixed.

 -Tim (Gumnos)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16879: request.user does not synchronize using SET_SESSION_COOKIE

2011-09-19 Thread Django

#16879: request.user does not synchronize using SET_SESSION_COOKIE
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  closed
   Type:  Bug|  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 The ''identifier'' of the session is the same on both sites but the
 ''contents'' of the session is different. On one site, the session
 contains some information that says that the user is logged in. On the
 other it doesn't.

 So this isn't a bug in Django.

 I don't know what's the best way to share authentication. You may have to
 write a custom authentication backend. If you want to discuss that, the
 django-users mailing list is a better place than Trac anyway. 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16880: Missing tags 1.2.6, 1.2.7 and 1.3.1 at github

2011-09-19 Thread Django

#16880: Missing tags 1.2.6, 1.2.7 and 1.3.1 at github
---+---
 Reporter:  vzima  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 Last tags present are 1.3 and 1.2.5. Please sync new ones.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16879: request.user does not synchronize using SET_SESSION_COOKIE

2011-09-19 Thread Django

#16879: request.user does not synchronize using SET_SESSION_COOKIE
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  new
   Type:  Bug|  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Wim Feijen ):

 * component:  Uncategorized => contrib.auth
 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16879: request.user does not synchronize using SET_SESSION_COOKIE

2011-09-19 Thread Django

#16879: request.user does not synchronize using SET_SESSION_COOKIE
+---
 Reporter:  Wim Feijen   |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Milestone:  |  Component:  Uncategorized
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 Hello,

 I have two sites running, on which I want to share request.user: meaning
 that if someone logs in to one site, he is automatically logged in to the
 other, and vice-versa.

 I'm using
 SESSION_COOKIE_DOMAIN = '.trumpetcms.nl' in both projects.

 If I inspect the session data, both websites use the same session, having
 a shared cookie where
 'sessionid': '28a1fa5874533465c0ff2889d4a.'

 But if I successfully log in to one site, then I remain anonymous on the
 other site. :(

 I believe this to be a bug. Can some-one please confirm this? Or did I
 misunderstand the documentation?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16878: Improve the "intword" filter

2011-09-19 Thread Django

#16878: Improve the "intword" filter
--+--
 Reporter:  crodjer   |  Owner:  crodjer
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  contrib.humanize
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+--
 The current code for intword function is repetitive. For each name,
 same code block is re-written.

 The patch from [https://github.com/django/django/pull/48 this] pull
 request,
 makes the code more DRY and also allowes the use words which
 represent much larger numbers then trillion. In the code, if the lots of
 zeroes don't look too good, they can be replaced to exponent form and used
 as {{{10**n}}}. I used zeroes thinking that might save some compution. The
 test in other commit can be neglected if not needed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16659: Change-list toplinks (date drilldown) should not have fixed width

2011-09-19 Thread Django

#16659: Change-list toplinks (date drilldown) should not have fixed width
-+-
   Reporter:  mofle  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  admin, list_filter,
 Resolution:  fixed  |  default
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by mofle):

 No problem. Thank for committing 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10933: Avoid " TypeError: Cannot convert Decimal("0.0000") to Decimal " when the decimal module has been reloaded

2011-09-19 Thread Django

#10933: Avoid " TypeError: Cannot convert Decimal("0.") to Decimal  " when 
the
decimal module has been reloaded
-+-
   Reporter:  gagravarr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  dceu2011
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by adrian.boczkowski@…):

 This problem also occurs with Django 1.3 on Apache + mod_wsgi. I fix it by
 changing (sorry, I can't make .diff file):
 {{{
 try:
  return decimal.Decimal(value)
 }}}

 to:

 {{{
 try:
  return decimal.Decimal(str(value))
 }}}

 I know it's rather ugly workaround than beautiful fix ;-), but it seems to
 work fine.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself

2011-09-19 Thread Django

#16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself
-+-
   Reporter:  Gumnos |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  SHORT_DATETIME_FORMAT
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-

Comment (by julien):

 @anonymous: Thanks for your patch, but note that you had modified the
 wrong line... ;-)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16855 - django/trunk/docs/ref

2011-09-19 Thread noreply

Author: julien
Date: 2011-09-19 00:33:32 -0700 (Mon, 19 Sep 2011)
New Revision: 16855

Modified:
   django/trunk/docs/ref/settings.txt
Log:
Fixed #16876 -- Fixed a cross reference in the settings reference doc. Thanks 
to Gumnos for the report.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2011-09-19 07:25:59 UTC (rev 16854)
+++ django/trunk/docs/ref/settings.txt  2011-09-19 07:33:32 UTC (rev 16855)
@@ -1718,7 +1718,7 @@
 corresponding locale-dictated format has higher precedence and will be applied.
 See :tfilter:`allowed date format strings `.
 
-See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
+See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
 
 .. setting:: SIGNING_BACKEND
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself

2011-09-19 Thread Django

#16876: Settings SHORT_DATETIME_FORMAT documentation cross-references itself
-+-
   Reporter:  Gumnos |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  SHORT_DATETIME_FORMAT
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 In [16855]:
 {{{
 #!CommitTicketReference repository="" revision="16855"
 Fixed #16876 -- Fixed a cross reference in the settings reference doc.
 Thanks to Gumnos 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16659: Change-list toplinks (date drilldown) should not have fixed width

2011-09-19 Thread Django

#16659: Change-list toplinks (date drilldown) should not have fixed width
-+-
   Reporter:  mofle  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  admin, list_filter,
 Resolution:  fixed  |  default
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by julien):

 Thank you, mofle, for the report and patch, and sorry that I forgot to
 mention you in the commit message.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16854 - django/trunk/django/contrib/admin/static/admin/css

2011-09-19 Thread noreply

Author: julien
Date: 2011-09-19 00:25:59 -0700 (Mon, 19 Sep 2011)
New Revision: 16854

Modified:
   django/trunk/django/contrib/admin/static/admin/css/changelists.css
   django/trunk/django/contrib/admin/static/admin/css/ie.css
   django/trunk/django/contrib/admin/static/admin/css/rtl.css
Log:
Fixed #16659 -- Made the admin's date drilldown links in the changelist have a 
variable width to play nicer with languages with long month names.

Modified: django/trunk/django/contrib/admin/static/admin/css/changelists.css
===
--- django/trunk/django/contrib/admin/static/admin/css/changelists.css  
2011-09-18 22:28:17 UTC (rev 16853)
+++ django/trunk/django/contrib/admin/static/admin/css/changelists.css  
2011-09-19 07:25:59 UTC (rev 16854)
@@ -165,11 +165,10 @@
 }
 
 .change-list ul.toplinks li {
-float: left;
-width: 9em;
 padding: 3px 6px;
 font-weight: bold;
 list-style-type: none;
+display: inline-block;
 }
 
 .change-list ul.toplinks .date-back a {

Modified: django/trunk/django/contrib/admin/static/admin/css/ie.css
===
--- django/trunk/django/contrib/admin/static/admin/css/ie.css   2011-09-18 
22:28:17 UTC (rev 16853)
+++ django/trunk/django/contrib/admin/static/admin/css/ie.css   2011-09-19 
07:25:59 UTC (rev 16854)
@@ -54,4 +54,10 @@
 
 .inline-deletelink {
 background: transparent url(../img/inline-delete-8bit.png) no-repeat;
+}
+
+/* IE7 doesn't support inline-block */
+.change-list ul.toplinks li {
+zoom: 1;
+*display: inline;
 }
\ No newline at end of file

Modified: django/trunk/django/contrib/admin/static/admin/css/rtl.css
===
--- django/trunk/django/contrib/admin/static/admin/css/rtl.css  2011-09-18 
22:28:17 UTC (rev 16853)
+++ django/trunk/django/contrib/admin/static/admin/css/rtl.css  2011-09-19 
07:25:59 UTC (rev 16854)
@@ -108,10 +108,6 @@
 
 /* changelists styles */
 
-.change-list ul.toplinks li {
-float: right;
-}
-
 .change-list .filtered {
 background: white url(../img/changelist-bg_rtl.gif) top left repeat-y 
!important;
 }

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16659: Change-list toplinks (date drilldown) should not have fixed width

2011-09-19 Thread Django

#16659: Change-list toplinks (date drilldown) should not have fixed width
-+-
   Reporter:  mofle  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  admin, list_filter,
 Resolution:  fixed  |  default
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-
Changes (by julien):

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


Comment:

 In [16854]:
 {{{
 #!CommitTicketReference repository="" revision="16854"
 Fixed #16659 -- Made the admin's date drilldown links in the changelist
 have a variable width to play nicer with languages with long month names.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

45 matches

Mail list logo