Re: [Django] #18392: Use utf8mb4 encoding with MySQL 5.5

[Django]

#18392: Use utf8mb4 encoding with MySQL 5.5
-+-
 Reporter:  EmilStenstrom|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  utf8mb4 mysql|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kitsunde):

 * cc: kitsunde@… (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 https://groups.google.com/groups/opt_out.

Re: [Django] #18184: relocate algorithm identification code to hashers module

[Django]

#18184: relocate algorithm identification code to hashers module
-+-
 Reporter:  Eli Collins  |Owner:  nobody
     |   Status:  closed
 Type:   |  Version:  1.4
  Cleanup/optimization   |   Resolution:  fixed
Component:  contrib.auth | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:  hashers  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by CollinAnderson):

 Now, what I need is a way to customize the identify_hasher function.

-- 
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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
-+-
 Reporter:  julien   |Owner:  ramiro
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Ramiro Morales ):

 In [changeset:"f51eab796d087439eedcb768cdd312517780940e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f51eab796d087439eedcb768cdd312517780940e"
 Fixed #18072 -- Made more admin links use reverse() instead of hard-coded
 relative URLs.

 Thanks kmike for the report and initial patch for the changelist->edit
 object view link URL.

 Other affected links include the delete object one and object history
 one (in this case the change had been implemented in commit 5a9e127, this
 commit adds admin-quoting of the object PK in a way similar to a222d6e.)

 Refs #15294.
 }}}

-- 
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] #18072: ChangeList shouldn't use hardcoded urls

[Django]

#18072: ChangeList shouldn't use hardcoded urls
--+
 Reporter:  kmike |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Ramiro Morales ):

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


Comment:

 In [changeset:"f51eab796d087439eedcb768cdd312517780940e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f51eab796d087439eedcb768cdd312517780940e"
 Fixed #18072 -- Made more admin links use reverse() instead of hard-coded
 relative URLs.

 Thanks kmike for the report and initial patch for the changelist->edit
 object view link URL.

 Other affected links include the delete object one and object history
 one (in this case the change had been implemented in commit 5a9e127, this
 commit adds admin-quoting of the object PK in a way similar to a222d6e.)

 Refs #15294.
 }}}

-- 
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] f51eab: Fixed #18072 -- Made more admin links use reverse(...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f51eab796d087439eedcb768cdd312517780940e
  
https://github.com/django/django/commit/f51eab796d087439eedcb768cdd312517780940e
  Author: Ramiro Morales 
  Date:   2012-09-24 (Mon, 24 Sep 2012)

  Changed paths:
M django/contrib/admin/templates/admin/change_form.html
M django/contrib/admin/templates/admin/submit_line.html
M django/contrib/admin/templatetags/admin_modify.py
M django/contrib/admin/util.py
M django/contrib/admin/views/main.py
M tests/regressiontests/admin_changelist/tests.py
M tests/regressiontests/admin_custom_urls/fixtures/actions.json
M tests/regressiontests/admin_custom_urls/tests.py
M tests/regressiontests/admin_views/tests.py

  Log Message:
  ---
  Fixed #18072 -- Made more admin links use reverse() instead of hard-coded 
relative URLs.

Thanks kmike for the report and initial patch for the changelist->edit
object view link URL.

Other affected links include the delete object one and object history
one (in this case the change had been implemented in commit 5a9e127, this
commit adds admin-quoting of the object PK in a way similar to a222d6e.)

Refs #15294.



-- 
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] #19021: collectstatic should only copy files if they have changed or don't exist in destination

[Django]

#19021: collectstatic should only copy files if they have changed or don't 
exist in
destination
---+-
 Reporter:  dloewenherz|  Owner:  dloewenherz
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 When running `./manage.py collectstatic`, all files in all static
 directories are copied to the location specified by `STATICFILES_STORAGE`,
 regardless of whether they have already been copied or not.

 I propose that collectstatic should only copy files to the destination if
 they have changed or don't yet exist. I wrote my own solution which
 doesn't incorporate staticfiles, but I'd like to see this in Django
 proper. Without this feature, it can take ages to upload static media for
 a large project. It makes sense to only update those assets which have
 changed between deploys.

 I currently solve this problem by creating a file containing metadata of
 all the static media at the root of the destination. This file is a JSON
 object that contains file paths as keys and checksum as values. When an
 upload is started, the uploader checks to see if the file path exists as a
 key in the dictionary. If it does, it checks to see if the checksums have
 changed. If they haven't changed, the uploader skips the file. At the end
 of the upload, the checksum file is updated on the destination.

-- 
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] #19020: Some contrib.formtools tests fail when Python hash value randomization is enabled

[Django]

#19020: Some contrib.formtools tests fail when Python hash value randomization 
is
enabled
--+
 Reporter:  metzen|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.formtools |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+
 The following tests in the contrib formtools application can fail when
 hash value randomization is enabled in the Python interpreter (2.7+).  As
 written, these test cases currently rely on the implicit order of items in
 a dictionary, which is unsupported.

  django.contrib.formtools.tests.!WizardTests.test_9473::
This test attempts to perform a regex to extract name/value pairs from
 an HTML string representing a list of  fields. The order of the
 attributes in the HTML is dependent on the sort order of the dictionary
 that originally represented them. Thus, a regex that expects the 'name'
 attribute to always directly precede the 'value' attribute will fail.

 
django.contrib.formtools.tests.wizard.cookiestorage.!TestCookieStorage.test_reset_cookie::
This test attempts to compare the result of JSON serialized dict to a
 literal string representation of that expected JSON. Since the order of
 the elements cannot be predicted, this comparison is prone to failure.

 (For more background on hash randomization:
 http://bugs.python.org/issue13703)

 Here's an example command line that produces the failures (note -R flag to
 enable hash randomization):

 {{{
 $ python -R ./runtests.py --settings test_sqlite \
   formtools.TestCookieStorage.test_reset_cookie \
   formtools.WizardTests.test_9473
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 FE
 ==
 ERROR: test_9473 (django.contrib.formtools.tests.WizardTests)
 --
 Traceback (most recent call last):
   File "/tmp/django/django/contrib/formtools/tests/__init__.py", line 442,
 in test_9473
 response = self.check_wizard_step(response, step_no)
   File "/tmp/django/django/contrib/formtools/tests/__init__.py", line 437,
 in check_wizard_step
 return self.client.post('/wizard2/', data)
   File "/tmp/django/django/test/client.py", line 429, in post
 response = super(Client, self).post(path, data=data,
 content_type=content_type, **extra)
   File "/tmp/django/django/test/client.py", line 263, in post
 return self.request(**r)
   File "/tmp/django/django/test/client.py", line 390, in request
 six.reraise(*exc_info)
   File "/tmp/django/django/core/handlers/base.py", line 115, in
 get_response
 response = callback(request, *callback_args, **callback_kwargs)
   File "/tmp/django/django/utils/decorators.py", line 25, in _wrapper
 return bound_func(*args, **kwargs)
   File "/tmp/django/django/utils/decorators.py", line 91, in _wrapped_view
 response = view_func(request, *args, **kwargs)
   File "/tmp/django/django/utils/decorators.py", line 21, in bound_func
 return func(self, *args2, **kwargs2)
   File "/tmp/django/django/contrib/formtools/wizard/legacy.py", line 101,
 in __call__
 request, f):
   File "/tmp/django/django/contrib/formtools/wizard/legacy.py", line 62,
 in _check_security_hash
 expected = self.security_hash(request, form)
   File "/tmp/django/django/contrib/formtools/wizard/legacy.py", line 177,
 in security_hash
 return form_hmac(form)
   File "/tmp/django/django/contrib/formtools/utils.py", line 21, in
 form_hmac
 value = bf.field.clean(bf.data) or ''
   File "/tmp/django/django/forms/fields.py", line 155, in clean
 self.validate(value)
   File "/tmp/django/django/forms/fields.py", line 127, in validate
 raise ValidationError(self.error_messages['required'])
 ValidationError: [u'This field is required.']

 ==
 FAIL: test_reset_cookie
 (django.contrib.formtools.tests.wizard.cookiestorage.TestCookieStorage)
 --
 Traceback (most recent call last):
   File
 "/tmp/django/django/contrib/formtools/tests/wizard/cookiestorage.py", line
 44, in test_reset_cookie
 self.assertEqual(unsigned_cookie_data,
 '{"step_files":{},"step":null,"extra_data":{},"step_data":{}}')
 AssertionError:
 u'{"step_files":{},"extra_data":{},"step_data":{},"step":null}' !=
 '{"step_files":{},"step":null,"extra_data":{},"step_data":{}}'

 --
 Ran 2 tests in 0.015s

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

-- 

Re: [Django] #16706: values_list on query set ordered by field added by QuerySet.extra() broken

[Django]

#16706: values_list on query set ordered by field added by QuerySet.extra() 
broken
-+-
 Reporter:  salfner@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (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 anonymous):

 The same code seems to work in Django 1.4.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.

[Django] #19019: UserAdmin.user_change_password does not log the change

[Django]

#19019: UserAdmin.user_change_password does not log the change
--+
 Reporter:  Tuttle|  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 I found myself missing the LogEntry added when the user password is
 changed through the admin. Calling self.log_change with save() would be
 nice.

-- 
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] 515fd6: Called parent __init__ in test logging handler

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 515fd6a5de2f1bf817fac9ced07d0485d594b510
  
https://github.com/django/django/commit/515fd6a5de2f1bf817fac9ced07d0485d594b510
  Author: Claude Paroz 
  Date:   2012-09-24 (Mon, 24 Sep 2012)

  Changed paths:
M tests/regressiontests/logging_tests/logconfig.py

  Log Message:
  ---
  Called parent __init__ in test logging handler



-- 
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] #18316: settings.configure() does not apply LOGGING_CONFIG

[Django]

#18316: settings.configure() does not apply LOGGING_CONFIG
+
 Reporter:  luch@…  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (Other)|  Version:  1.4
 Severity:  Normal  |   Resolution:
 Keywords:  settings configure  | 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):

 * stage:  Design decision needed => Accepted


Comment:

 This is at least against documentation. Quoted from
 https://docs.djangoproject.com/en/dev/topics/logging/#configuring-logging:

 Logging is configured as soon as settings have been loaded (either
 manually using configure() or when at least one setting is accessed).
 Since the loading of settings is one of the first things that Django does,
 you can be certain that loggers are always ready for use in your project
 code.

 I think this should be fixed.

-- 
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] #14861: Importing settings in a module that contains a logging Handler causes circular import.

[Django]

#14861: Importing settings in a module that contains a logging Handler causes
circular import.
-+-
 Reporter:  donspaulding |Owner:  Claude
 Type:  Bug  |  Paroz 
Component:  Core (Other) |   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Claude Paroz ):

 * status:  new => closed
 * owner:   => Claude Paroz 
 * resolution:   => fixed


Comment:

 In [changeset:"fc69fff9ab5bba8a6cff3eaf51f02a3204b1c015"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fc69fff9ab5bba8a6cff3eaf51f02a3204b1c015"
 Fixed #14861 -- Moved logging config outside of Settings.__init__

 Thanks donspaulding for the report and simonpercivall for the
 initial patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] fc69ff: Fixed #14861 -- Moved logging config outside of Se...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fc69fff9ab5bba8a6cff3eaf51f02a3204b1c015
  
https://github.com/django/django/commit/fc69fff9ab5bba8a6cff3eaf51f02a3204b1c015
  Author: Claude Paroz 
  Date:   2012-09-24 (Mon, 24 Sep 2012)

  Changed paths:
M django/conf/__init__.py
M docs/topics/logging.txt
A tests/regressiontests/logging_tests/logconfig.py
M tests/regressiontests/logging_tests/tests.py

  Log Message:
  ---
  Fixed #14861 -- Moved logging config outside of Settings.__init__

Thanks donspaulding for the report and simonpercivall for the
initial patch.



-- 
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] #18903: Add forms validation for GB telephone numbers.

[Django]

#18903: Add forms validation for GB telephone numbers.
-+-
 Reporter:  g1smd|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  Telephone Number | Triage Stage:  Accepted
  Forms GB   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by g1smd):

 We think this is now 'Ready for Checkin' but will leave it to a third
 party to make that call officially.

-- 
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] #19018: m2m relationships with a through field don't respect types.

[Django]

#19018: m2m relationships with a through field don't respect types.
-+-
 Reporter:  justinlilly  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 ptone):

 So looking at this mostly for my own edification.

 A higher level place this could be checked would be
 `db.models.where.Constraint.process`

 otherwise: `db.models.fields.related.RelatedField.get_db_prep_lookup` and
 `db.models.fields.related.RelatedField._pk_trace`

 seem like the best places to tackle this.

 However unless a patch is pretty quick, it seems worth improving the docs,
 at least in the interim, to clarify that lookup values for model instances
 will always be converted to a simple pk value for database lookups.

-- 
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] #19018: m2m relationships with a through field don't respect types.

[Django]

#19018: m2m relationships with a through field don't respect types.
-+-
 Reporter:  justinlilly  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 Alex):

 Everything you just said is correct, it's not just your belief :)

-- 
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] #19018: m2m relationships with a through field don't respect types.

[Django]

#19018: m2m relationships with a through field don't respect types.
-+-
 Reporter:  justinlilly  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 carljm):

 (Also not specific to `__in` queries, same is true of a simple `__exact`
 match on an FK field).

-- 
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] #19018: m2m relationships with a through field don't respect types.

[Django]

#19018: m2m relationships with a through field don't respect types.
-+-
 Reporter:  justinlilly  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 carljm):

 I don't believe this bug is specific to m2ms or through models at all. In
 general, currently you can pass any iterable of instances of any model to
 any `__in` query and the ORM will happily use the PKs of the models you
 give it, without checking whether they are an instance of the right model
 class (or a subclass, or raw PK values which is also supported).

-- 
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] #19018: m2m relationships with a through field don't respect types.

[Django]

#19018: m2m relationships with a through field don't respect types.
-+-
 Reporter:  justinlilly  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Alex):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19018: m2m relationships with a through field don't respect types.

[Django]

#19018: m2m relationships with a through field don't respect types.
-+-
 Reporter:  justinlilly  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by justinlilly):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #19018: m2m relationships with a through field don't respect types.

[Django]

#19018: m2m relationships with a through field don't respect types.
--+
 Reporter:  justinlilly   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I ran into an issue today in which an empty list was returned from a
 Queryset when it should have been a blatant failure.

 Given the models in
 
https://github.com/django/django/blob/master/tests/modeltests/m2m_through/models.py

 The following returns an empty queryset:

 {{{#!python
   Group.objects.filter(members__in=[Friendship(pk=9)])
 }}}

-- 
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] #18993: Default django logging to StreamHandler (when DEBUG=True)

[Django]

#18993: Default django logging to StreamHandler (when DEBUG=True)
--+--
 Reporter:  claudep   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by ptone):

 This looks like a solid approach, and is cleaner than my idea on IRC of
 just using .update() on the global settings with the user settings version
 of the config (which would be another way of merging the two).

 I think this happens as early as we are likely to get it to happen in
 Django, so the following point is minor.  Perhaps a note in the docs that
 disable_existing_loggers is absolute, so that if its used to disable
 DJango's default logging, it will also disable any already loaded loggers
 from other libraries.

 FWIW I do agree the default logging config should live outside of the
 global settings

-- 
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] #14861: Importing settings in a module that contains a logging Handler causes circular import.

[Django]

#14861: Importing settings in a module that contains a logging Handler causes
circular import.
--+
 Reporter:  donspaulding  |Owner:
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 OK, I can commit it without the admonition, then we'll see if any further
 issue is raised, we can always add it later.

-- 
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] #19017: If command is called from code, it does not change locale to previous state

[Django]

#19017: If command is called from code, it does not change locale to previous 
state
-+-
 Reporter:  andrey@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Same response that I gave for #19016, only security or crasher bugs in
 stable releases, sorry.

-- 
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] #19016: Test fixes for different locale

[Django]

#19016: Test fixes for different locale
---+--
 Reporter:  andrey@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admindocs  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by claudep):

 No, only security or crasher bugs are candidate to be fixed in a stable
 release.

-- 
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] #16211: using negated F()-expression in update query

[Django]

#16211: using negated F()-expression in update query
-+-
 Reporter:  wdoekes  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by twoolie):

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


Comment:

 charettes: requested changes have been made. Should now be ready for
 checkin.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #19017: If command is called from code, it does not change locale to previous state

[Django]

#19017: If command is called from code, it does not change locale to previous 
state
-+-
 Reporter:  andrey@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gugu):

 Can somebody fix it in 1.4 branch?

-- 
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] #19016: Test fixes for different locale

[Django]

#19016: Test fixes for different locale
---+--
 Reporter:  andrey@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admindocs  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by gugu):

 Do you plan to fix it in 1.4?

-- 
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] #19017: If command is called from code, it does not change locale to previous state

[Django]

#19017: If command is called from code, it does not change locale to previous 
state
-+-
 Reporter:  andrey@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Duplicate of #17947 (already fixed). Thanks for the report, but try to
 look at latest code before submitting ticket and patch, this will save you
 time!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #18948: setting DEBUG to False change behavior of i18n

[Django]

#18948: setting DEBUG to False change behavior of i18n
--+--
 Reporter:  lanyjie   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Translations  |  Version:  1.4
 Severity:  Normal|   Resolution:  worksforme
 Keywords:  i18n integration  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by lanyjie):

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


Comment:

 @claudep: indeed, after providing 404.html everything worked just fine.
 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] #19016: Test fixes for different locale

[Django]

#19016: Test fixes for different locale
---+--
 Reporter:  andrey@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admindocs  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 Duplicate of #18240 (already fixed). Thanks 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] #19017: If command is called from code, it does not change locale to previous state

[Django]

#19017: If command is called from code, it does not change locale to previous 
state
+
 Reporter:  andrey@…|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 Currently code is:

 {{{
 except CommandError, e:
  if show_traceback:
  traceback.print_exc()
  else:
  self.stderr.write(smart_str(self.style.ERROR('Error:
 %s\n' % e)))
  sys.exit(1)
 if saved_lang is not None:
 translation.activate(saved_lang)
 }}}

 So if command raises exception, translation is not restored

-- 
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] #19016: Test fixes for different locale

[Django]

#19016: Test fixes for different locale
---+
 Reporter:  andrey@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admindocs  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 Tests are failing now with different locales. Some tests depends on
 english texts. I fixed 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.

[django/django] e72e22: Replaced a deprecated assertEquals

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e72e22e518a730cd28cd68c9374fa79a45e27a9c
  
https://github.com/django/django/commit/e72e22e518a730cd28cd68c9374fa79a45e27a9c
  Author: Claude Paroz 
  Date:   2012-09-24 (Mon, 24 Sep 2012)

  Changed paths:
M tests/regressiontests/utils/html.py

  Log Message:
  ---
  Replaced a deprecated assertEquals



-- 
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] 6eda8d: Enlarged exception catching when testing for GDAL ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6eda8d784a128309a67540fb0a62373667958daa
  
https://github.com/django/django/commit/6eda8d784a128309a67540fb0a62373667958daa
  Author: Claude Paroz 
  Date:   2012-09-24 (Mon, 24 Sep 2012)

  Changed paths:
M django/contrib/gis/gdal/__init__.py

  Log Message:
  ---
  Enlarged exception catching when testing for GDAL presence

Other import errors than ImportError can happen during import of
GDAL files (e.g. OGRException). Some further auditing may be needed
if we want to restrict the catched exceptions at a later stage.
Thanks Ramiro Morales for raising the issue.



-- 
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] #19015: Slovenian L10N - date field validation does not work for hidden fields

[Django]

#19015: Slovenian L10N - date field validation does not work for hidden fields
-+-
 Reporter:  bmihelac |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.localflavor  |  Version:  1.4
 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 bmihelac):

 Patch for slovenian language is available:
 https://github.com/django/django/pull/390

-- 
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] #19015: Slovenian L10N - date field validation does not work for hidden fields (was: Slovenian l10n does not work with hidden fields)

[Django]

#19015: Slovenian L10N - date field validation does not work for hidden fields
-+-
 Reporter:  bmihelac |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.localflavor  |  Version:  1.4
 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 bmihelac):

 * needs_docs:   => 0
 * needs_better_patch:   => 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 https://groups.google.com/groups/opt_out.

[Django] #19015: Slovenian l10n does not work with hidden fields

[Django]

#19015: Slovenian l10n does not work with hidden fields
-+
 Reporter:  bmihelac |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.localflavor  |Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 When DateInput has HiddenInput widget, it renders value by converting date
 to string This produces iso-8601 (-MM-DD) format.

 Because iso-8601 format is not stated in slovenian flavor
 DATE_INPUT_FORMATS,  validation will fail if USE_L10N=True and hidden date
 field exists.

 This issue applies to some other locales as well:

 {{{
 ack --py --files-without-matches  '%Y-%m-%d' conf/locale/
 }}}

-- 
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] #19014: PASSWORD_HASHERS missed in "Full list of settings"

[Django]

#19014: PASSWORD_HASHERS missed in "Full list of settings"
---+
 Reporter:  jedie  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 PASSWORD_HASHERS not in the list of settings, here:
 https://docs.djangoproject.com/en/dev/ref/settings/

-- 
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] #18993: Default django logging to StreamHandler (when DEBUG=True)

[Django]

#18993: Default django logging to StreamHandler (when DEBUG=True)
--+--
 Reporter:  claudep   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by claudep):

 After some thinking, I think there is a small flaw in the current Django
 logging config system. The LOGGING config in global_settings.py is
 overriden by any custom settings LOGGING. When we update LOGGING in
 global_settings, any upgraded project cannot take advantage of newer
 features in the LOGGING config.

 My proposal would be:
 * Add DEFAULT_LOGGING in global_settings.py (with current LOGGING as
 content). This is *not* supposed to be overriden by project's settings.py
 (we can even imagine put it somewhere else, django.utils.log comes to
 mind). By default, global_settings.py LOGGING would be empty. We can still
 let the current content in project template LOGGING.
 * When configuring LOGGING (`django.conf.__init__.py`), first feed
 DEFAULT_LOGGING to the config function, then, if LOGGING is not empty,
 feed LOGGING to the config system.

 Here are the possible scenarios:
 * If the user has set `disable_existing_loggers` to True in his project's
 LOGGING, nothing has changed for him. He's still in complete control of
 logging in his project.
 * If the user has no LOGGING in his settings, the situation is unchanged,
 Django default logging is configured.
 * If the user has set `disable_existing_loggers` to False in LOGGING
 (which is currently the default in the project template), then Django
 default logging is configured, and the user custom LOGGING is *added* to
 the Django default configuration.

 This latest point is where we really gain from the current situation. We
 don't have to fiddle any more with the logging setup code.

 I may be missing something in my reasoning. Comments welcome!

-- 
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] #18990: 'manage.py loaddata' does not report if the loading file does not exist

[Django]

#18990: 'manage.py loaddata' does not report if the loading file does not exist
-+-
 Reporter:  sergzach |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  loaddata |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_tests:  0 => 1


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

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

Re: [Django] #18993: Default django logging to StreamHandler (when DEBUG=True)

[Django]

#18993: Default django logging to StreamHandler (when DEBUG=True)
--+--
 Reporter:  claudep   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by ptone):

 * needs_docs:  0 => 1


Comment:

 I still think that the logging config injection here:

 https://code.djangoproject.com/attachment/ticket/18993/18993-2.diff#L9

 is a bad idea.  While it does provide the more visible logging for
 migrated projects - any warnings that a developer really should know
 about, should be proper warnings.warn, not logging.warning. I think that
 if a user deletes the relevant boilerplate logging config bits from their
 settings.py, the logging behavior should not just magically reappear in
 their console - only going away if they explicitly set the handler to
 nullhandler.

-- 
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] #10809: mod_wsgi authentication handler

[Django]

#10809: mod_wsgi authentication handler
-+-
 Reporter:  baumer1122   |Owner:  ptone
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mod_wsgi | 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 ptone):

 * status:  assigned => new
 * owner:  davidfischer => ptone
 * stage:  Accepted => Ready for checkin


Comment:

 I've just spent some time reviewing and updating this patch.

 With mod_python being removed in 1.5 - it seems good to get this into a
 release

 I made some minor revisions to the docs, updated to be py3 compatible, and
 caught a small error in the test.

 I believe this to be RFC, but welcome final reviews.

 https://github.com/django/django/pull/389

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