Re: [Django] #17792: pickled object's __setstate__() ignores exceptions

[Django]

#17792: pickled object's __setstate__() ignores exceptions
+--
 Reporter:  rpq__@… |Owner:  nobody
 Type:  Uncategorized   |   Status:  reopened
Component:  Uncategorized   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  session pickle  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by rpq__@…):

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


Comment:

 hi,

 pickle, __setstate__, and TypeError are python concepts, however, i have
 an app where *any* exception thrown in a pickled object's __setstate__()
 for use in request.session are silently caught/ignored by django.  this
 should not be difficult to reproduce.  i verified that this does not
 happen in "pure python"; uncaught exceptions raised in a pickled object's
 __setstate__() were being thrown as expected.

-- 
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] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+-
 Reporter:  pixelcort|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  1
-+-

Comment (by anonymous):

 I was looking for a solution to this as well

 I've created a repository underwhich I started with a clone of 1.3.1

 I initially applied the above patch and then modified it to extend the
 functionality

 as a result there are 2 new classes admin.NestedTabularInline and
 admin.NestedStackedInline

 I fixed the ability to use the add more button on the initial inline and
 will be doing some work to fix the add more button for the nested inlines

 I've not fully tested the stacked inlines but if someone wants to give
 them a whirl I think they are good to go

 [https://bitbucket.org/daveleblanc/django-nested-inlines]

-- 
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] #17853: Fixture error output has wrong fixture name

[Django]

#17853: Fixture error output has wrong fixture name
+
 Reporter:  treborhudson@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.4-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 In django/core/management/commands/loaddata.py it computes the `full_path`
 of the fixture files (~line 163) in a for loop, but all of that is wrapped
 up in a try/except block. If the naked Exception block (~line 231) is
 triggered, the `full_path` is often wrong.  In the cases I've seen it,
 it's a completely different file and often with a '.bz2' extension, which
 I'm not using.

-- 
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] #16605: Can't client.login() in tests if contrib.SessionMiddleware is not in MIDDLEWARE_CLASSES

[Django]

#16605: Can't client.login() in tests if contrib.SessionMiddleware is not in
MIDDLEWARE_CLASSES
---+
 Reporter:  jbalogh|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.3
 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 russellm):

 * severity:  Normal => Release blocker


Comment:

 Marking as a release blocker because it's a backwards incompatible change.
 Even if the fix for release purposes is documentation-only, this is
 something we should address before final.

 The proposed patch looks like a reasonable approach, but it needs tests,
 and it feels like something that might be a useful general capability for
 other parts of the codebase (i.e., 'dot-path named class is a subclass
 of...')

-- 
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] #7639: Locmem is not multiprocess nor threadsafe

[Django]

#7639: Locmem is not multiprocess nor threadsafe
-+-
 Reporter:  permon   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Cache system)  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by projectgus):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Would it please be possible to change the phrase "This cache is multi-
 process" to "per-process" (will attach possible patch.) Per-process seems
 to be a more accurate description of how the cache works.

 I realise the subsequent paragraph explains it perfectly (thanks!), but
 there must be other idiot newbies like me who skimmed the docs before
 making a new admin command, thought "great, multi-process, no need to
 change anything!" and then wondered why their cache didn't invalidate
 cleanly. Before I, of course, RTed-rest-of-the-FM. :)

-- 
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] #17327: contrib.auth management commands ignores --database option

[Django]

#17327: contrib.auth management commands ignores --database option
-+-
 Reporter:  skam |Owner:
    |  brianriley
 Type:  New feature  |   Status:  reopened
Component:  contrib.auth |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  django db models | Triage Stage:  Ready for
  createsuperuser management |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by brianriley):

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


Comment:

 Seems like most multi DB management commands are in regressiontests, so I
 moved the createsuperuser tests there. This will ensure that they aren't
 run when you run the tests on your Django project.

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
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|
-+-

Comment (by akaariai):

 An update about MySQL: it has [http://dev.mysql.com/doc/refman/5.0/en
 /date-and-time-functions.html#function_convert-tz convert_tz] function
 which does something equivalent to AT TIME ZONE. However, there are some
 problems with convert_tz:
   - The timezone table for MySQL has to be loaded, if I understand the
 documentation correctly this is not done by default
   - If you try to convert a datetime using an unknown (to MySQL) timezone
 name, you get null back
   - If the datetime falls out of the range 1970-2038 you will not get any
 conversion, you get the input datetime back.

 So, the convert_tz function would cure the problem for MySQL, assuming the
 datetime converted is in range 1970-2038. That could be documented as
 known limitation. This was the last missing piece of this puzzle:
   - SQLite should be easy to support by using Python code directly in the
 query.
   - PostgreSQL and Oracle should work using AT TIME ZONE syntax. Python
 <-> DB timezone names must match or there must be a converter.
   - MySQL should work with convert_tz (with the above cave-eats), Again
 Python <-> DB timezone names must match or there must be a converter.

 There is a lot of work left to actually implement the above properly for
 all core databases. However, that should be pretty straightforward coding
 to do. The big problem is converting the timezone names from Python to DB
 format. Any ideas how to do that in somewhat clean fashion?

-- 
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] #17852: Documentation for Testing utilities is incorrect for create_test_db etc.

[Django]

#17852: Documentation for Testing utilities is incorrect for create_test_db etc.
+--
 Reporter:  mountainpaul@…  |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Documentation   |  Version:  1.4-beta-1
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Changes (by anonymous):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * 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.

Re: [Django] #17850: Passing FormWizard.as_view(form_list) a dynamic form_list

[Django]

#17850: Passing FormWizard.as_view(form_list) a dynamic form_list
-+-
 Reporter:  Jeffrey Horn |Owner:  nobody
    |   Status:  new
 Type:  Bug  |  Version:
Component:  contrib.formtools|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:  formwizard   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jrhorn424):

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


Comment:

 Using a slightly different technique yields a different error.


 {{{
 TypeError: get_initkwargs() takes at least 2 arguments (1 given)
 # in
 "/django/django/contrib/formtools/wizard/views.py", line 118, in as_view
 }}}


 #urls.py

 {{{
 from django.conf.urls import patterns, url

 from views import survey_wizard

 urlpatterns = patterns('',
 url(r'^(?P[0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12})$',
 survey_wizard),
 )
 }}}

 views.py:

 {{{
 class SurveyWizard(CookieWizardView):

 def get_form_list(self):
 form_list = get_survey_page_list(self.kwargs['survey'])
 return form_list

 ### This fails, too ###
 # @property
 # def form_list(self):
 # form_list = get_survey_page_list(self.kwargs['survey'])
 # return form_list

 survey_wizard = SurveyWizard.as_view()
 }}}

 I suspect this is because !SurveyWizard.as_view() is expecting an argument
 to pass along to get_initkwargs. Werkzeug:


 {{{
 >>> dir()
 ['args', 'cls', 'kwargs']
 >>> args
 ()
 >>> kwargs
 {}
 >>> cls
 
 }}}

 However, I'm at a loss as to how else to get a dynamically generated list
 of forms into form_list.

-- 
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] #17852: Documentation for Testing utilities is incorrect for create_test_db etc.

[Django]

#17852: Documentation for Testing utilities is incorrect for create_test_db etc.
+
 Reporter:  mountainpaul@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Documentation   |Version:  1.4-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  1   |  UI/UX:  0
+
 versions 1.4/Trunk and 1.3

 https://docs.djangoproject.com/en/dev/topics/testing/#module-
 django.test.utils

 The docs states "... Django provides a number of utility methods in the
 django.test.utils module"

 The following functions are not in that module:

 create_test_db
 destroy_test_db

-- 
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] #17851: Db Field instances cannot be compared to other objects (was: Db Field instances cannot be to other objects)

[Django]

#17851: Db Field instances cannot be compared to other objects
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  field compare|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17851: Db Field instances cannot be to other objects

[Django]

#17851: Db Field instances cannot be to other objects
--+---
 Reporter:  charettes |  Owner:  charettes
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:  field compare
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+---
 
[https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L126-L128
 `django.db.models.fields.Field.__cmp__`] assumes that it's always compared
 to a another `Field` instance thus raising an `AttributeError` when the
 following code is executed:

 {{{#!python
 from django.db.models.fields import Field

 Field() == None
 }}}

 It should make sure that `other` is a `Field` instance before accessing
 the `creation_counter` property and if not return `NotImplemented`.

 I stumbled on this issue when trying to use a `PickledObjectField` to
 store `Field` instance. When calling `full_clean` on the field it raised
 an `AttributeError` because it was trying to compare it `EMPTY_VALUES`:
 {{{value in EMPTY_VALUES}}}.

 I agree that this is NOT a common use case of the Field class however I
 think that `Field` instances should be able to compare themselves to other
 objects without raising a confusing `AttributeError`.

 I'm attaching a patch that sticks with simple comparison (although we
 should REALLY move to advanced comparison) with tests.

 Here's a chat log I had on #python concerning simple comparison:
 {{{
 charettes 13:31:23
 What should an object that implements __cmp__ method should return if it
 can't compare to other.
 papna 13:31:49
 charettes: 1) Don't write __cmp__ methods unless you're targetting
 mesozoic Python 2) NotImplemented
 charettes 13:32:41
 papna: But the doc doesn't say that... it says only to use it for advanced
 comparaison
 charettes 13:32:58
 papna: http://docs.python.org/reference/datamodel.html#object.__cmp__
 papna 13:33:42
 charettes: Why are you using __cmp__?
 charettes 13:34:42
 papna: actually I'm writing a patch for a project that used this method...
 should I suggest to switch to adavanced comparaison?
 papna 13:36:43
 charettes: IIRC __cmp__ still uses the paradigm that __eq__ and friends
 and __add__ and friends and plenty of other stuff does, but I might be
 wrong. It's not flexible, which is why it has been deprecated well over a
 decade.
 charettes 13:37:27
 papna: aight ty for your time
 }}}

 I can adapt the current patch to use advanced comparison instead if you
 prefer.

-- 
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] #17850: Passing FormWizard.as_view(form_list) a dynamic form_list

[Django]

#17850: Passing FormWizard.as_view(form_list) a dynamic form_list
+
 Reporter:  Jeffrey Horn   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  contrib.formtools   |Version:  1.4-beta-1
 Severity:  Normal  |   Keywords:  formwizard
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 The following technique fails to provide the expected behavior. The error
 returned is:
 {{{
 TypeError: issubclass() arg 1 must be a class
 # happens in
 /django/contrib/formtools/wizard/views.py", line 166, in get_initkwargs
 }}}

 urls.py:
 {{{
 from django.conf.urls import patterns, url

 # from views import survey_wizard
 from views import SurveyWizard
 from forms import get_survey_page_list

 # I'd rather do this dynamically as well, but this *should* work
 survey_page_list = get_survey_page_list('274a442b-67ec-
 11e1-b010-78ca39b1b597')

 urlpatterns = patterns('',
 url(r'^(?P[0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12})$',
 SurveyWizard.as_view(form_list=survey_page_list)),
 )
 }}}

 forms.py:
 {{{
 def get_survey_page_list(survey):
 """
 Build a list of survey pages for the form wizard to use.

 args:
 survey - a unicode string passed in from a URL parameter
 """
 survey_page_list = []

 # Since we're receiving a captured URL parameter, we have to use that
 # string to acutally fetch the survey object.
 s = Survey.objects.get(pk=survey)
 for page in s.page_set.all().order_by('number'):
 step_name = unicode(page.number)
 form_class = make_survey_page_form(survey, page.number)
 survey_page_list.append((step_name, form_class))

 return SortedDict(survey_page_list)
 }}}

 Looking into the Werkzeug debugger reveals that the functions called in
 forms.py are grabbing and returning a SortedDict of forms:
 {{{
 >>> dir()
 ['args', 'cls', 'condition_dict', 'form', 'form_list', 'i',
 'init_form_list', 'initial_dict',   ]
 >>> form_list
 django.utils.datastructures.SortedDict({u'1': , u'2': , u'3': })
 >>> initial_dict
 >>> init_form_list
 django.utils.datastructures.SortedDict({u'0': u'1', u'1': u'2', u'2':
 u'3'})
 }}}

-- 
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] #17849: testing framework fails when contrib.auth not in settings.

[Django]

#17849: testing framework fails when contrib.auth not in settings.
-+-
 Reporter:  on.celebi@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  auth_user test auth  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by on.celebi@…):

 Sorry I wasn't clear. This is not the same issue, it has the same
 symptoms. This one is highly similar because with the same testcase
 (removing contrib.auth from INSTALLED_APPS) you obtain the same error
 output. But this time this is because of "contenttypes" app dependency to
 "auth" rather than "messages" 's one which was fixed for ticket #14632.

 Maybe a better ticket would be "better dependency management between apps
 for the testing  framework" instead of creating some tickets and fixes
 which just hide the error 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.

Re: [Django] #6712: choosing tests with command line among tests provided by custom 'suite' method

[Django]

#6712: choosing tests with command line among tests provided by custom 'suite'
method
---+
 Reporter:  alainD |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by ukch):

 * cc: joel@… (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] #17849: testing framework fails when contrib.auth not in settings.

[Django]

#17849: testing framework fails when contrib.auth not in settings.
-+-
 Reporter:  on.celebi@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  auth_user test auth  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ramiro):

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


Comment:

 So you are seeing 1.3.x and this was fixed in trunk afterwards the 1.3
 release. Unfortunately, according to the
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions backporting policy] in effect, such fix isn't going
 to be ported to 1.3.x.

 Duplicate of #14632.

-- 
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] #16074: Class-based views clash get_context_data

[Django]

#16074: Class-based views clash get_context_data
-+-
 Reporter:  emyller  |Owner:  tobias
 Type:  Bug  |   Status:  assigned
Component:  Generic views|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  cbv  | 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 dbrgn):

 * cc: dbrgn (added)


Comment:

 This is an important change, many mixin implementations might depend on
 this in the future. If this does not go into 1.4, it should be in 1.5 for
 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.

[Django] #17849: testing framework fails when contrib.auth not in settings.

[Django]

#17849: testing framework fails when contrib.auth not in settings.
---+-
 Reporter:  on.celebi@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.3
 Severity:  Normal |   Keywords:  auth_user test auth
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 This is the same issue than Ticket #14632, it still exists in Django
 1.3.1.
 This time, it's the contenttypes app which is causing the bug because of a
 dependency with auth.

-- 
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] #15636: django.contrib.staticfiles - "collectstatic" makes all files names lowercase.

[Django]

#15636: django.contrib.staticfiles - "collectstatic" makes all files names
lowercase.
-+-
 Reporter:  drakaar  |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Replying to [comment:19 wooyek]:
 > Sorry, my bad. The trunk version has been already been corrected. I did
 not check the details of this ticket when I was looking for it. I was
 writing under an assumption that it was for 1.3.1 version (silly me).

 Thanks for this clarification.

 So you are seeing 1.3.x and this was fixed in trunk afterwards the 1.3
 release. Unfortunately, according to the
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions backporting policy] in effect this isn't going to be
 ported to 1.3.x. We are going to fix it only in trunk if it efefctively
 still exists there.

 This leaves us with the report by user george.ma1982 that reopened this
 ticket on March 1 2012 but without specifying what Django release/revision
 he is using.

 If he is able to give us that information and it results he is using trunk
 then we still need information from him how to reproduce this and the
 ''needsinfo'' closing-reason of this ticket is correct, if he reports he
 us using 1.3.x then we can change the closing reason to ''fixed''.

 In any case the ''closed'' status is correct.

-- 
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] #17785: PostgreSQL Introspection: get_relations() broken after drop column

[Django]

#17785: PostgreSQL Introspection: get_relations() broken after drop column
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  psycopg2 |  Needs documentation:  0
  introspection  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by guettli):

 * needs_tests:  1 => 0


Comment:

 I updated the patch. It has a unittest now. I tested it with sqlite (test
 get skipped, since it does not support DROP COLUMN) and psycopg2.

-- 
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] #15636: django.contrib.staticfiles - "collectstatic" makes all files names lowercase.

[Django]

#15636: django.contrib.staticfiles - "collectstatic" makes all files names
lowercase.
-+-
 Reporter:  drakaar  |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by wooyek):

 Sorry, my bad. The trunk version has been already been corrected. I did
 not check the details of this ticket when I was looking for it. I was
 writing under an assumption that it was for 1.3.1 version (silly me).

 Answering your question: NTFS.

 Again sorry for code analysis instead of test case, there is a problem:
 
https://code.djangoproject.com/browser/django/branches/releases/1.3.X/django/utils/_os.py#L37

 And here it is corrected:
 https://code.djangoproject.com/browser/django/trunk/django/utils/_os.py#L42

 If you still need a test case, I'll try to write one. All I did up till
 now is create a no-app project with one static file. But when I got to
 learning how to write test for django framework itself I found that the
 trunk version is OK.

 The project is here:
 http://www.dropbox.pl/file.php?name=449D082A80C3D12C33FBDF5E67AC35AE

 Poke me if the test case is still needed, but you'll have to give me some
 time find my way in the test for static files

-- 
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] #15636: django.contrib.staticfiles - "collectstatic" makes all files names lowercase.

[Django]

#15636: django.contrib.staticfiles - "collectstatic" makes all files names
lowercase.
-+-
 Reporter:  drakaar  |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by ramiro):

 Replying to [comment:17 wooyek]:
 > Everything is done on one single machine, single disk. I'll try to
 provide a test case.
 >

 (the anonymous above was me from a cell phone)

 Thanks, which fileystem? FAT? NTFS?

-- 
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] #17848: Template context processors cache needs to be restored after it is cleared

[Django]

#17848: Template context processors cache needs to be restored after it is 
cleared
-+--
 Reporter:  ryankask |Owner:  ryan
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  tests| Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--

Comment (by ryankask):

 You're right. That's much simpler.

-- 
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] #17848: Template context processors cache needs to be restored after it is cleared

[Django]

#17848: Template context processors cache needs to be restored after it is 
cleared
-+--
 Reporter:  ryankask |Owner:  ryan
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  tests| Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by claudep):

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


Comment:

 I think it would be easier to just empty the cache again at the end of the
 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] #15636: django.contrib.staticfiles - "collectstatic" makes all files names lowercase.

[Django]

#15636: django.contrib.staticfiles - "collectstatic" makes all files names
lowercase.
-+-
 Reporter:  drakaar  |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by wooyek):

 Everything is done on one single machine, single disk. I'll try to provide
 a test case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17848: Template context processors cache needs to be restored after it is cleared

[Django]

#17848: Template context processors cache needs to be restored after it is 
cleared
-+
 Reporter:  ryankask |  Owner:  ryan
 Type:  Bug  | Status:  new
Component:  contrib.auth |Version:  1.4-beta-1
 Severity:  Release blocker  |   Keywords:  tests
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  1|  UI/UX:  0
-+
 I contributed the portion of the patch for #16366 where
 ``context._standard_context_processors`` is set to ``None`.

 Unfortunatley, I neglected to restore the cache as it was at the end of
 the test.

 The effect of this is that cache is now wrong for the rest of my project
 (and will be for others) and other tests fail.

 This patch fixes this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17847: Broken Link

[Django]

#17847: Broken Link
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 To clarify -- the Django Book isn't an official resource of the Django
 project; even if we wanted to update it, we couldn't.

-- 
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.