Re: [Django] #8851: Please add a default option to list_filter in the admin interface

[Django]

#8851: Please add a default option to list_filter in the admin interface
-+-
 Reporter:  Riskable |Owner:  nobody
 |   Status:  reopened
 Type:  New feature  |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  admin, list_filter,  |  Needs documentation:  0
  default|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by charettes):

 I think you can achieve this in 1.4+ by subclassing
 `django.contrib.admin.ChoicesFieldListFilter`.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #16913: Admin error when trying to delete object with a GenericRelation

[Django]

#16913: Admin error when trying to delete object with a GenericRelation
---+-
 Reporter:  r1cky  |Owner:  carljm
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by bobah22@…):

 until the bug is not fixed, [http://pastebin.com/cxChE2rw here's] snippet
 to workaround for your 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19393: Form fields ordered incorrectly when introducing addition fields

[Django]

#19393: Form fields ordered incorrectly when introducing addition fields
-+--
 Reporter:  dloewenherz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.5-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:  0|UI/UX:  0
-+--
Changes (by russellm):

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


Comment:

 Thanks for the report, but AFAICT, this is a case where Django is doing
 exactly the right thing, and your code fix is the right solution. You've
 suggested the order that you would expect the fields to appear in, but I
 can't see any basis on which Django could determine that preferred order.
 Your fields.keyOrder hack is essentially the "right" solution here -- see
 the definition for PasswordChangeForm for an analog in Django's own
 codebase.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19394: Forms in django.contrib.auth have "username" as a hardcoded field value

[Django]

#19394: Forms in django.contrib.auth have "username" as a hardcoded field value
-+--
 Reporter:  dloewenherz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.5-beta-1
 Severity:  Normal   |   Resolution:  wontfix
 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 russellm):

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


Comment:

 I completely agree. However, in this case, we're stuck between a rock and
 a hard place.

 These forms are tightly bound to the specific user model, so it's very
 hard to make a truly generic form that will work with all user models. I
 made a design decision to not try and be too smart with this -- I kept the
 UserCreationForm etc simple and username-specific, and documented the fact
 that end-users will need to define their own forms. Given that the form
 logic isn't that complicated (if you look at UserCreationForm, for
 example, most of the code is actually setting up error messages and
 regexes for parsing username), I didn't think it was *that* onerous.

 The one exception to this is the AuthenticationForm -- in that case we're
 using the conceit of calling the "unique identifier field" username,
 regardless of what it is actually called. This makes form processing for
 logins much easier.

 So - absent of a specific proposal to fix the problem -- e.g., showing how
 the form could be refactored -- I'm going to mark this wontfix. If anyone
 can propose a specific way to address this that doesn't result in
 hideously complex code, or an complex class heirarchy that stills require
 a bunch of code to be written, feel free to reopen.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19395: Improve logging section by providing a SIMPLE example

[Django]

#19395: Improve logging section by providing a SIMPLE example
-+-
 Reporter:  ken.nelson@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 I heard some people being very enthousiastic about logbook:
 http://packages.python.org/Logbook/ . Though that doesn't solve the docs,
 it might be worthwile to take a look on their website. They give an
 example right-away, and it is very clear.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19364: Wrong exception raised at django/db/models/fields/related.py:343? (DoesNotExist instead of AttributeError)

[Django]

#19364: Wrong exception raised at django/db/models/fields/related.py:343?
(DoesNotExist instead of AttributeError)
-+-
 Reporter:  lbragues@…   |Owner:  lbragues
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  DoesNotExist,| Triage Stage:  Accepted
  django.db, getattr,|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by lbragues):

 Then by throwing DoesNotExist we can't simply do a getattr call to check
 if the attribute exists in the db and if it has a value assigned, since
 DoesNotExists isn't catched by getattr.
 It goes a little bit against what you expect python to do from reading the
 python docs http://docs.python.org/3/library/functions.html#getattr (docs
 v2 is equal).
 And also if you do a dir(obj) the output shows that the object as a
 property with the name you are trying to get, so it can be a little
 confusing at first...

 So the solution I adopted to do this is to try...except:
 {{{
 try:
 #do something with object
 except DosNotExist:
 #do something on exception
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19357: Unicode errors when Django is installed under a non-ASCII path

[Django]

#19357: Unicode errors when Django is installed under a non-ASCII path
-+-
 Reporter:  kujiu|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Python 2 |  Version:  master
 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
-+-

Comment (by aaugustin):

 As discussed on IRC, I'm just wrapping ASCII string literals in `str(...)`
 to obtain native strings where necessary, under Python 2 and 3, in modules
 that have unicode_literals turned on. I'm not guessing encodings.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19393: Form fields ordered incorrectly when introducing addition fields

[Django]

#19393: Form fields ordered incorrectly when introducing addition fields
-+--
 Reporter:  dloewenherz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.5-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by dloewenherz):

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


Comment:

 For the time being, I'm just specifying the keyOrder in the form's
 __init__ method.

 {{{
 self.fields.keyOrder = ['first_name', 'last_name', 'email',
 'email_confirmation', 'password', 'password_confirmation']
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19354: Unable to set PK for custom user model

[Django]

#19354: Unable to set PK for custom user model
-+-
 Reporter:  markteisman@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:
 Severity:  Normal   |  1.5-alpha-1
 Keywords:  PK Primary Key   |   Resolution:  fixed
  Custom User| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"47c5b50d346237f30584ad9303dea8f6933ffae3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="47c5b50d346237f30584ad9303dea8f6933ffae3"
 [1.5.x] Fixed #19354 -- Do not assume usermodel.pk == usermodel.id

 Thanks markteisman at hotmail.com for the report.
 Backport of 0eeae1505 from master.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

[django/django] 47c5b5: [1.5.x] Fixed #19354 -- Do not assume usermodel.pk...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 47c5b50d346237f30584ad9303dea8f6933ffae3
  
https://github.com/django/django/commit/47c5b50d346237f30584ad9303dea8f6933ffae3
  Author: Claude Paroz 
  Date:   2012-11-29 (Thu, 29 Nov 2012)

  Changed paths:
M django/contrib/admin/options.py
M django/contrib/auth/__init__.py
M django/contrib/auth/forms.py
M 
django/contrib/auth/tests/templates/context_processors/auth_attrs_user.html
M django/contrib/auth/tokens.py
M django/contrib/auth/views.py
M docs/ref/templates/builtins.txt
M tests/regressiontests/model_formsets_regress/tests.py
M tests/regressiontests/transactions_regress/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #19354 -- Do not assume usermodel.pk == usermodel.id

Thanks markteisman at hotmail.com for the report.
Backport of 0eeae1505 from master.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19354: Unable to set PK for custom user model

[Django]

#19354: Unable to set PK for custom user model
-+-
 Reporter:  markteisman@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:
 Severity:  Normal   |  1.5-alpha-1
 Keywords:  PK Primary Key   |   Resolution:  fixed
  Custom User| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"0eeae15056edf07f786d3be5b47c14ab62eacd31"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0eeae15056edf07f786d3be5b47c14ab62eacd31"
 Fixed #19354 -- Do not assume usermodel.pk == usermodel.id

 Thanks markteisman at hotmail.com 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 https://groups.google.com/groups/opt_out.

[django/django] 0eeae1: Fixed #19354 -- Do not assume usermodel.pk == user...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0eeae15056edf07f786d3be5b47c14ab62eacd31
  
https://github.com/django/django/commit/0eeae15056edf07f786d3be5b47c14ab62eacd31
  Author: Claude Paroz 
  Date:   2012-11-29 (Thu, 29 Nov 2012)

  Changed paths:
M django/contrib/admin/options.py
M django/contrib/auth/__init__.py
M django/contrib/auth/forms.py
M 
django/contrib/auth/tests/templates/context_processors/auth_attrs_user.html
M django/contrib/auth/tokens.py
M django/contrib/auth/views.py
M docs/ref/templates/builtins.txt
M tests/regressiontests/model_formsets_regress/tests.py
M tests/regressiontests/transactions_regress/tests.py

  Log Message:
  ---
  Fixed #19354 -- Do not assume usermodel.pk == usermodel.id

Thanks markteisman at hotmail.com for the report.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19357: Unicode errors when Django is installed under a non-ASCII path

[Django]

#19357: Unicode errors when Django is installed under a non-ASCII path
-+-
 Reporter:  kujiu|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Python 2 |  Version:  master
 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
-+-

Comment (by kmtracey):

 Wait, what? It ought to be OK to pass unicode on Python 2.X to Python os
 path functions. Yes, internally Python is going to have to turn unicode
 into a bytestring for passing into the system functions...but it should be
 able to do that, we should not have to do it before calling the os path
 functions. We've gone back and forth on this before, see for example
 #11030. Django code CANNOT be responsible for figuring out what the right
 encoding is for file system paths -- utf8 is going to be wrong on Asian
 windows systems, for example. Underlying Python should be configured
 correctly to figure that out. Or am I misunderstanding what you are having
 to do here?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19378: HttpResponseRedirect fail on reverse_lazy with Python 3.2

[Django]

#19378: HttpResponseRedirect fail on reverse_lazy with Python 3.2
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 I was a bit surprised to not find existing FormView tests. Maybe I missed
 them?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19357: Unicode errors when Django is installed under a non-ASCII path

[Django]

#19357: Unicode errors when Django is installed under a non-ASCII path
-+-
 Reporter:  kujiu|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Python 2 |  Version:  master
 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
-+-

Comment (by aaugustin):

 In fact, when the unicode_literals path was applied, filesystem paths
 operations weren't changed accordingly. Python uses native strings for
 filesystem paths.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19395: Improve logging section by providing a SIMPLE example

[Django]

#19395: Improve logging section by providing a SIMPLE example
--+
 Reporter:  ken.nelson@…  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hi,

 New to Python and Django. We have been gifted with several Django sites to
 maintain. These sites are poorly written and have no debug capabilities,
 so i wanted to enable a primitive log to report on uncaught exceptions, as
 well as a place we can manually write to. I don't have all afternoon to
 work through all the permutations of Python logging; I just need the most
 basic. So, the fact that the only log config example you provided is
 humungous is disappointing.

 I'm sure many would be grateful for a minimal single textfile logging
 example they can just cut'n'paste and use ASAP. 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 https://groups.google.com/groups/opt_out.

Re: [Django] #16136: Error was: cannot import name utils

[Django]

#16136: Error was: cannot import name utils
--+--
 Reporter:  kurvenschubser@…  |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  Uncategorized |  Version:  1.3
 Severity:  Normal|   Resolution:  worksforme
 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 danols):

 * cc: ognajd@… (added)
 * ui_ux:   => 0


Comment:

 I have run into this problem today when taking over an existing project.
 The site was developed against Django 1.1, There is no 1.1 through PIP so
 I attempted to set it up against 1.3.3 but kept getting this error. After
 hours of trying to resolve this and as a last ditch effort I installed
 Django 1.2.7 and to my surprise the error went away. I have added myself
 to the CC list and so will assist further if needed. However I believe the
 work around is enough to leave this ticket closed as this project's does
 utilize an overly complicated `settings` approach which my gut tells me is
 the cause.

 {{{
 (virtualenv)root@klisrv03:trunk>$  ipython -i -- manage.py runserver
 --settings=settings_development
 Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
 Type "copyright", "credits" or "license" for more information.

 IPython 0.13.1 -- An enhanced Interactive Python.
 ? -> Introduction and overview of IPython's features.
 %quickref -> Quick reference.
 help  -> Python's own help system.
 object?   -> Details about 'object', use 'object??' for extra details.
 /srv/www/django//trunk/virtualenv/lib/python2.6/site-
 packages/django/db/__init__.py:19: DeprecationWarning: settings.DATABASE_*
 is deprecated; use settings.DATABASES instead.
   DeprecationWarning
 /srv/www/django//trunk/virtualenv/lib/python2.6/site-
 packages/django/db/__init__.py:60: DeprecationWarning: Short names for ENG
 INE in database configurations are deprecated. Prepend default.ENGINE with
 'django.db.backends.'
   DeprecationWarning
 Error: cannot import name utils
 An exception has occurred, use %tb to see the full traceback.

 SystemExit: 1


 In [1]: %tb
 ---
 SystemExitTraceback (most recent call
 last)
 /srv/www/django//trunk/virtualenv/lib/python2.6/site-
 packages/IPython/utils/py3compat.pyc in execfile(fname, *where)
 176 else:
 177 filename = fname
 --> 178 __builtin__.execfile(filename, *where)

 /srv/www/django//trunk/manage.py in ()
   9
  10 if __name__ == "__main__":
 ---> 11 execute_manager(settings)

 /srv/www/django//trunk/virtualenv/lib/python2.6/site-
 packages/django/core/management/__init__.pyc in execute_manager(settings_m
 od, argv)
 436 setup_environ(settings_mod)
 437 utility = ManagementUtility(argv)
 --> 438 utility.execute()

 /srv/www/django//trunk/virtualenv/lib/python2.6/site-
 packages/django/core/management/__init__.pyc in execute(self)
 377 sys.stderr.write(self.main_help_text() + '\n')
 378 else:
 --> 379
 self.fetch_command(subcommand).run_from_argv(self.argv)
 380
 381 def setup_environ(settings_mod, original_settings_path=None):

 /srv/www/django//trunk/virtualenv/lib/python2.6/site-
 packages/django/core/management/base.pyc in run_from_argv(self, argv)
 189 options, args = parser.parse_args(argv[2:])
 190 handle_default_options(options)
 --> 191 self.execute(*args, **options.__dict__)
 192
 193 def execute(self, *args, **options):

 /srv/www/django//trunk/virtualenv/lib/python2.6/site-
 packages/django/core/management/base.pyc in execute(self, *args, **options
 )
 212 # raise the error and quit.
 213
 sys.stderr.write(smart_str(self.style.ERROR('Error: %s\n' % e)))
 --> 214 sys.exit(1)
 215 try:
 216 self.stdout = options.get('stdout', sys.stdout)

 SystemExit: 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19378: HttpResponseRedirect fail on reverse_lazy with Python 3.2

[Django]

#19378: HttpResponseRedirect fail on reverse_lazy with Python 3.2
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * component:  Uncategorized => Generic views
 * stage:  Unreviewed => Accepted


Comment:

 Mmmmh... it's not the first time I'm confronted with issues related to the
 new Python 3 urlparse implementation and its `isinstance` dance :-(

 The problem cannot be triggered in `ModelFormMixin`-based views because
 the lazy reverse is resolved by an interpolation ({{{self.success_url %
 self.object.__dict__}}}). However, it is a problem in `FormMixin` version
 of `get_success_url`, where we probably will have to force the lazy
 evaluation.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19046: staticfiles not finding the files on Windows

[Django]

#19046: staticfiles not finding the files on Windows
-+-
 Reporter:  nelutzu_13@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:  needsinfo
 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 jezdez):

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


Comment:

 posixpath is the module that is used on POSIX systems when import os.path.
 It uses the hardcoded forward slash and a couple of other things different
 to the ntpath module that does the same for Windows systems. In other
 words os.path just a facade for the platform specific tools. The different
 modules are documented on http://docs.python.org/2/library/os.path.html

 The lstrip('/') happens there since the path passed to the serve view may
 be formatted as `http://localhost:8000/static///someother/file.ext` making
 path having a value of `//someother/file.ext`. The posix.normpath happens
 there to remove redundancies in the path (e.g. `path/to/../some//file.ext`
 is converted to `path/some/file.ext`). The finder api expects that kind of
 cleaned up name to make sure it does the right thing later on.

 As I'm not able to reproduce the issue with the current code, I'm closing
 as needsinfo. A testcase that demostrates the issue would be appreciated,
 for example.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19394: Forms in django.contrib.auth have "username" as a hardcoded field value

[Django]

#19394: Forms in django.contrib.auth have "username" as a hardcoded field value
-+
 Reporter:  dloewenherz  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.5-beta-1
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 This is a barrier to users who want to make use of these forms after the
 1.5 upgrade with custom user field names.

 E.g.

 {{{
 class UserCreationForm(forms.ModelForm):
 """
 A form that creates a user, with no privileges, from the given
 username and
 password.
 """
 error_messages = {
 'duplicate_username': _("A user with that username already
 exists."),
 'password_mismatch': _("The two password fields didn't match."),
 }
 username = forms.RegexField(label=_("Username"), max_length=30,
 regex=r'^[\w.@+-]+$',
 help_text=_("Required. 30 characters or fewer. Letters, digits and
 "
   "@/./+/-/_ only."),
 error_messages={
 'invalid': _("This value may contain only letters, numbers and
 "
  "@/./+/-/_ characters.")})
 password1 = forms.CharField(label=_("Password"),
 widget=forms.PasswordInput)
 password2 = forms.CharField(label=_("Password confirmation"),
 widget=forms.PasswordInput,
 help_text=_("Enter the same password as above, for
 verification."))

 class Meta:
 model = User
 fields = ("username",)
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19393: Form fields ordered incorrectly when introducing addition fields

[Django]

#19393: Form fields ordered incorrectly when introducing addition fields
-+
 Reporter:  dloewenherz  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.5-beta-1
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I have a ModelForm based on a User class with `fields = ('first_name',
 'last_name', 'email', 'password')`. My `RegistrationForm` looks like this:

 {{{

 class RegistrationForm(forms.ModelForm):
 email = forms.CharField(help_text="Used for logging in and account
 notifications")
 email_confirmation = forms.CharField(label="Verify Email")
 password = forms.CharField(widget=forms.PasswordInput)
 password_confirmation = forms.CharField(label="Verify Password",
 widget=forms.PasswordInput)

 class Meta():
 model = User
 fields = ('first_name', 'last_name', 'email', 'password')
 }}}

 I would expect the fields to appear in this order:

 * first_name
 * last_name
 * email
 * email_confirmation
 * password
 * password_confirmation

 But instead they appear in this order

 * first_name
 * last_name
 * email
 * password
 * email_confirmation
 * password_confirmation

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19349: admin/auth/user throws TypeError on save with invalid email address

[Django]

#19349: admin/auth/user throws TypeError on save with invalid email address
-+-
 Reporter:  tim.bowden@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:
 Severity:  Normal   |  1.5-alpha-1
 Keywords:  user email   |   Resolution:
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by jezdez):

 Yup, LGTM

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19392: Old-style url names (with dashes) throw confusing template traceback

[Django]

#19392: Old-style url names (with dashes) throw confusing template traceback
-+
 Reporter:  dloewenherz  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Template system  |Version:  1.5-beta-1
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 When migrating an existing project to Django 1.5 (one that has dashes in
 the URL names), I get a very confusing error in the template traceback.
 Namely:

 {{{
 TemplateSyntaxError at /
 Could not parse the remainder: '-login' from 'account-login'
 }}}

 {{{
 Create Account
 }}}

 The culprit is in the `filter_raw_string` regex in
 django/template/base.py. When I change 'var_chars' to `"-\w\."`(instead of
 `"\w\."`, I get a more sensible error message:

 {{{
 NoReverseMatch at /
 'url' requires a non-empty first argument. The syntax changed in Django
 1.5, see the docs.
 }}}

 I think the messaging here could be improved.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #16649: Models.save() refactoring: check updated rows to determine action

[Django]

#16649: Models.save() refactoring: check updated rows to determine action
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Sorry, the explanations above are a little confusing. Still another try:
 {{{
 s = SomeModel.objects.get(pk=someval)
 s.somecol = someval
 s.save()
 }}}
 Here save is implemented as SELECT - if not found INSERT - else UPDATE.
 The SELECT here is redundant, we have the information that SELECT was just
 done in model._state. So, we can do directly an UPDATE. If it happens so
 that nothing is updated (likely because of concurrent delete) then we will
 still do the INSERT and things work as expected.

 I have done a
 [https://github.com/akaariai/django/compare/model_save_refactor full
 refactor] of model.save_base(), this includes 4 parts:
   - What this ticket deals with - trying directly to UPDATE if the model
 was fetched from the same DB we are saving to. Also assorted cleanup to
 make this possible.
   - Cleanup to proxy parents handling (the logic is somewhat ugly
 currently)
   - A bug fix for #17341 (do not commit transaction after every parent
 model save)
   - Splitting save_base into parts so that the saving logic is easier to
 follow

 Above, the bug fix is of course needed, and the proxy parents handling
 cleanup is IMO also needed.

 I can't see any downsides to trying UPDATE directly as done in the patch.
 This should result in clear performance improvement in most cases. There
 is a problem that we have documented very explicitly the sequence of SQL
 commands .save() does but I don't think that documentation should be
 considered part of the public API. So, docs update is needed.

 The refactoring of .save_base() into parts is a stylistic question. I
 surprisingly prefer the refactored way. Some examples of things that are
 hard to see from the current writing of the code:
   - Which signals are sent for which models
   - The actual hard work is done in the if not meta.proxy: branch.
 However, it is impossible that meta.proxy is True here. And it isn't
 exactly easy to see this.
   - The origin parameter is a bit weird - it is None except for the
 outermost table save.

 Still, I'd like to get a confirmation that others prefer the new writing,
 too.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19364: Wrong exception raised at django/db/models/fields/related.py:343? (DoesNotExist instead of AttributeError)

[Django]

#19364: Wrong exception raised at django/db/models/fields/related.py:343?
(DoesNotExist instead of AttributeError)
-+-
 Reporter:  lbragues@…   |Owner:  lbragues
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  DoesNotExist,| Triage Stage:  Accepted
  django.db, getattr,|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * component:  Database layer (models, ORM) => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 The `DoesNotExist` is how relations work in Django. The attribute isn't
 missing. Getting the value for the attribute doesn't succeed as nothing
 exists for that attribute in the DB. Hence `DoesNotExist`.

 For some reason I can't find the this from the documentation. Seems
 somewhat surprising if this isn't documented...

 I am leaving this open so that we can confirm that this is documented
 somewhere.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19390: NameError in models throws ambiguous message when running syncdb

[Django]

#19390: NameError in models throws ambiguous message when running syncdb
-+-
 Reporter:  dloewenherz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-beta-1
 Severity:  Normal   |   Resolution:
 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 dloewenherz):

 I think the traceback is a bit overkill, but just showing the NameError
 without *any* context isn't really enough to do anything about it. I would
 at least show the path of the file where it originated from.

 Also, when running --traceback, it displays the exception twice:

 {{{
 Traceback (most recent call last):
   File "EXAMPLE/lib/python2.7/site-
 packages/django/core/management/base.py", line 222, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "EXAMPLE/lib/python2.7/site-
 packages/django/core/management/base.py", line 251, in execute
 self.validate()
   File "EXAMPLE/lib/python2.7/site-
 packages/django/core/management/base.py", line 277, in validate
 num_errors = get_validation_errors(s, app)
   File "EXAMPLE/lib/python2.7/site-
 packages/django/core/management/validation.py", line 35, in
 get_validation_errors
 for (app_name, error) in get_app_errors().items():
   File "EXAMPLE/lib/python2.7/site-packages/django/db/models/loading.py",
 line 165, in get_app_errors
 self._populate()
   File "EXAMPLE/lib/python2.7/site-packages/django/db/models/loading.py",
 line 71, in _populate
 self.load_app(app_name, True)
   File "EXAMPLE/lib/python2.7/site-packages/django/db/models/loading.py",
 line 95, in load_app
 models = import_module('.models', app_name)
   File "EXAMPLE/lib/python2.7/site-packages/django/utils/importlib.py",
 line 35, in import_module
 __import__(name)
   File "EXAMPLE/app/models.py", line 4, in 
 class Example(db.Model):
 NameError: name 'db' is not defined
 NameError: name 'db' is not defined
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #17911: Admin change page does not "map" None choices when they are readonly

[Django]

#17911: Admin change page does not "map" None choices when they are readonly
-+-
 Reporter:  justin.r.donnelly@…  |Owner:  edwtjo
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | 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 akaariai):

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


Comment:

 Sorry, didn't mean to reopen this one.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #17911: Admin change page does not "map" None choices when they are readonly

[Django]

#17911: Admin change page does not "map" None choices when they are readonly
-+-
 Reporter:  justin.r.donnelly@…  |Owner:  edwtjo
 Type:  Bug  |   Status:  reopened
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | 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 akaariai):

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


Comment:

 The added test doesn't work on Oracle, see #19391.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19391: Oracle test failure in 1.5.x and master

[Django]

#19391: Oracle test failure in 1.5.x and master
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.5-beta-1
 Severity:  Release blocker   |   Keywords:  oracle
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The fix for #17911 (commit 29d59a879ea5b116cc31a2fd91be1f7562e487c2)
 doesn't work on Oracle. The reason is our old friend "lets treat '' as
 NULL".

 The failure is this:
 {{{
 ==
 FAIL: test_change_form_renders_correct_null_choice_value
 (regressiontests.admin_views.tests.ReadonlyTest)
 --
 Traceback (most recent call last):
   File
 "/home/akaariai/Programming/django/tests/regressiontests/admin_views/tests.py",
 line 3211, in test_change_form_renders_correct_null_choice_value
 self.assertContains(response, 'No opinion', html=True)
   File "/home/akaariai/Programming/django/tests/django/test/testcases.py",
 line 632, in assertContains
 msg_prefix + "Couldn't find '%s' in response" % text)
 AssertionError: Couldn't find '
 No opinion
 ' in response
 }}}

 I am marking this as a release blocker because it is expected that all
 tests pass on all supported databases on release. In any other sense this
 isn't severe at all.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19390: NameError in models throws ambiguous message when running syncdb

[Django]

#19390: NameError in models throws ambiguous message when running syncdb
-+-
 Reporter:  dloewenherz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 This is a common Python error message, I wouldn't call it ambiguous. You
 can obtain the full traceback with the --traceback option.

 Maybe Django should display tracebacks by default...

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

[Django] #19390: NameError in models throws ambiguous message when running syncdb

[Django]

#19390: NameError in models throws ambiguous message when running syncdb
--+
 Reporter:  dloewenherz   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.5-beta-1
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When I start a Django 1.5 repo and forget to import a required library, I
 get a very ambiguous error when running ./manage.py syncdb

 My models.py
 {{{
 from django.contrib.auth.models import AbstractBaseUser

 class Example(db.Model):
 pass
 }}}

 {{{
 $ ./manage.py syncdb
 NameError: name 'db' is not defined
 }}}

 The file path where this error occurs should probably be noted to users. I
 can imagine it getting tough to track down when in a large project with
 lots of apps.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19367: ContentFile fails to save with filesystem storage when initialized with unicode string

[Django]

#19367: ContentFile fails to save with filesystem storage when initialized with
unicode string
--+
 Reporter:  void  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I'm still undecided about the best way to fix this. On one side, it would
 be easier and more consistent to always convert the content to bytes
 (Approach 2), but on the other side, opening text files on Python 3
 returns unicode content, so we might also reflect that difference in our
 implementation (Approach 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19356: Increase session key entropy

[Django]

#19356: Increase session key entropy
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.sessions  |  Version:  master
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Aymeric Augustin ):

 In [changeset:"83df1f3b571667f3d625c95af745c6ff687ef78e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="83df1f3b571667f3d625c95af745c6ff687ef78e"
 [1.5.x] Fixed #19356 -- Increased session key entropy.

 Backport of d913a8b from master.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

[django/django] 83df1f: [1.5.x] Fixed #19356 -- Increased session key entr...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 83df1f3b571667f3d625c95af745c6ff687ef78e
  
https://github.com/django/django/commit/83df1f3b571667f3d625c95af745c6ff687ef78e
  Author: Aymeric Augustin 
  Date:   2012-11-29 (Thu, 29 Nov 2012)

  Changed paths:
M django/contrib/sessions/backends/base.py
M django/contrib/sessions/backends/file.py

  Log Message:
  ---
  [1.5.x] Fixed #19356 -- Increased session key entropy.

Backport of d913a8b from master.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19356: Increase session key entropy

[Django]

#19356: Increase session key entropy
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.sessions  |  Version:  master
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"d913a8b41281c506451156bdebc9a1851cb49fae"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d913a8b41281c506451156bdebc9a1851cb49fae"
 Fixed #19356 -- Increased session key entropy.
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] d913a8: Fixed #19356 -- Increased session key entropy.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d913a8b41281c506451156bdebc9a1851cb49fae
  
https://github.com/django/django/commit/d913a8b41281c506451156bdebc9a1851cb49fae
  Author: Aymeric Augustin 
  Date:   2012-11-29 (Thu, 29 Nov 2012)

  Changed paths:
M django/contrib/sessions/backends/base.py
M django/contrib/sessions/backends/file.py

  Log Message:
  ---
  Fixed #19356 -- Increased session key entropy.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19388: Datetime field can not show in firefox 12

[Django]

#19388: Datetime field can not show in firefox 12
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords:  Firefox| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Python 2 => contrib.admin
 * severity:  Release blocker => Normal


-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19388: Datetime field can not show in firefox 12

[Django]

#19388: Datetime field can not show in firefox 12
-+--
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 2 |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  Firefox  | 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):

 I cannot reproduce the problem with the information you have provided.

 The admin properly displays the change view for a model with two date time
 fields under Firefox with Django 1.4.

 See attached screenshot.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19389: Wrong location of admin tests in documentation

[Django]

#19389: Wrong location of admin tests in documentation
---+
 Reporter:  KJ |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 As tests for admin live in tests/regressiontests/admin_*, the following
 info in internals/contributing/writing-code/unit-tests:

 > The tests cover:
 >
 > * Models and the database API (tests/modeltests),
 > * Everything else in core Django code (tests/regressiontests),
 > * Contrib apps (django/contrib//tests).

 is misleading. There is a small file django/contrib/admin/tests.py, but
 inside of it no comment is made redirecting user to tests/regressiontests.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19327: Admin doesn't handle double login attempts

[Django]

#19327: Admin doesn't handle double login attempts
-+-
 Reporter:  KJ   |Owner:  KJ
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  sensitive_post_parameters, login   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by KJ):

 * cc: KJ (added)
 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 +1 for adupin's argumentation about the if statement.

 I think that tests for this ticket should be placed in admin_views, not in
 admin_custom_urls, so I've put one there and updated the pull request.
 Checking of error message is included. I didn't actually use adupin's
 patch because tests in admin_views are written in a different manner.

 BTW, I didn't write a test at first because I didn't notice that those are
 actually present for the admin. The documentation says tests for contrib
 apps live in django/contrib//tests - I'll create another ticket about
 that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19388: Datetime field can not show in firefox 12

[Django]

#19388: Datetime field can not show in firefox 12
-+--
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 2 |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  Firefox  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by anonymous):

 This is in windows XP sp3, and IE version is 8.
 Another machine Windows 7 with firefox 16 dosen't have this issue, why?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19388: Datetime field can not show in firefox 12

[Django]

#19388: Datetime field can not show in firefox 12
-+--
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 2 |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  Firefox  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by anonymous):

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


Comment:

 Then i update the firefox to 17, the issue still exsit

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19386: Comment template not work

[Django]

#19386: Comment template not work
-+--
 Reporter:  romankrv |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:
 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
-+--
Changes (by anonymous):

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


Comment:

 Please see TicketClosingReasons/UseSupportChannels (and the syntax for
 comments in Django templates).

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19388: Datetime field can not show in firefox 12

[Django]

#19388: Datetime field can not show in firefox 12
-+-
 Reporter:  anonymous|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Python 2 |Version:  1.4
 Severity:  Release blocker  |   Keywords:  Firefox
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 i have two datetime field.
 It should show 4 control, date/time for both field
 but it only show a date for the first field, only 1, not 4
 In firefox12

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19387: CookieStorage does not encode/decode SafeData properly

[Django]

#19387: CookieStorage does not encode/decode SafeData properly
--+
 Reporter:  bak1an|  Owner:  bak1an
 Type:  Bug   | Status:  new
Component:  contrib.messages  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 When i'm trying to send a Message to user with some SafeData inside (e.g.
 a link) and message is saved in CookieStorage i get just str back from
 storage. With SessionStorage everything works, which is expected because
 it does not converts messages to json and back.

 Here is a branch with tests and proposed solution:
 [https://github.com/bak1an/django/compare/cookie_storage cookie_storage]

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19386: Comment template not work

[Django]

#19386: Comment template not work
-+
 Reporter:  romankrv |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 If I comment some code in template like

 
 
 

 it code get work anyway
 I try to put here some broken code and it give me some error

 '''comment not work'''

 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19384: Managers can no longer be used on abstract models

[Django]

#19384: Managers can no longer be used on abstract models
-+-
 Reporter:  mhsparks |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mhsparks):

 Thanks for taking the time to look at this. We're using the abstract class
 manager to access partitioned versions of the model. Some context to try
 and explain further:

 Our app runs many similar fantasy sports and tipping games. In these users
 make a series of choices for a round and compete with others over a number
 of phases. We have implemented a partition manager that allows very large
 tables such as tips and league standings to be partitioned over separate
 tables based on round or phase rather than simply have round or phase as a
 foreign key.

 During start-up (model generation phase) N models will be created based on
 how the abstract base model has been defined. For example if a game has 40
 Rounds and the Tip model has been configured to partition by Round then
 Tip1 to Tip40 models will be created and the manager is then used to
 access these partitions, similarly if a game has 10 Phases LeagueStanding1
 to LeagueStanding10 models will be created and the LeagueStanding
 partitions manager used to access them.

 If we weren't using a model manager then we'd probably need to use a mixin
 class instead to implement similar behaviour in all models that need 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 https://groups.google.com/groups/opt_out.