Re: [Django] #21945: Overriding field in a ModelForm makes it required

2014-02-03 Thread Django
#21945: Overriding field in a ModelForm makes it required
---+--
 Reporter:  Siecje |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  1.6
 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 loic84):

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


Comment:

 Hi @Siecje, this is the expected behavior as described in
 https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overriding-
 the-default-fields:

 ''Fields defined declaratively are left as-is [...] (and) do not draw
 their attributes like max_length or required from the corresponding model.
 If you want to maintain the behavior specified in the model, you must set
 the relevant arguments explicitly when declaring the form field.''

 If you only intend to provide a custom widget, you may use the
 `Meta.widgets` attribute rather than redefining the 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.fad0e27b87c8643faf30908dcfa34b9b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21947: Test server returns HTTP 500 on static files when STATIC_ROOT is None

2014-02-03 Thread Django
#21947: Test server returns HTTP 500 on static files when STATIC_ROOT is None
-+-
 Reporter:  madmox   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  STATIC_ROOT  | Triage Stage:
  runserver test server  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by loic84):

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


Comment:

 Hi @madmox,  the default value for `STATIC_ROOT` has been changed from
 `''` to `None` as a result of #21581.

 This fix has been backported to the 1.6.x branch due to the severity of
 the issue, but we haven't made a new release yet, so the documentation
 applies to Django 1.6.2 which hasn't been released.

 I'm not sure how to best deal with this situation at Django's level,
 especially if a new release is not imminent. In the meantime, you may set
 `STATIC_ROOT` to any string value, but if you choose an empty string `''`
 I strongly recommend you refrain from using the `--clear` option.

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

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


[Django] #21948: Docs on extending admin templates should mention TEMPLATE_LOADERS

2014-02-03 Thread Django
#21948: Docs on extending admin templates should mention TEMPLATE_LOADERS
---+
 Reporter:  django@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The docs at https://docs.djangoproject.com/en/dev/ref/contrib/admin
 /#overriding-admin-templates should mention that you *must* set:

 {{{
 TEMPLATE_LOADERS = (
  'django.template.loaders.filesystem.Loader',
  ...
 )
 }}}

  and that `django.template.loaders.filesystem.Loader` must come before
 `django.template.loaders.app_directories.Loader`.

 This confused me for a long time, mainly because the default settings.py
 created with `django-admin.py startproject myproject` doesn't contain any
 of those settings.

 (P.S. you also need to set `TEMPLATE_DIRS` of course. This is mentioned in
 the docs linked above, but I think it could be clearer)

 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.04f783c2058053efaa6f43b0392a199d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21948: Docs on extending admin templates should mention TEMPLATE_LOADERS

2014-02-03 Thread Django
#21948: Docs on extending admin templates should mention TEMPLATE_LOADERS
---+--
 Reporter:  django@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.6
 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 anonymous):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Documentation
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.d06521697df187b52b8cd2080134b41f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #21947: Test server returns HTTP 500 on static files when STATIC_ROOT is None

2014-02-03 Thread Django
#21947: Test server returns HTTP 500 on static files when STATIC_ROOT is None
---+---
 Reporter:  madmox |  Owner:  nobody
 Type:  Bug| Status:  new
Component: |Version:  1.6
  contrib.staticfiles  |   Keywords:  STATIC_ROOT runserver test server
 Severity:  Normal |  Has patch:  0
 Triage Stage: |  UI/UX:  0
  Unreviewed   |
Easy pickings:  0  |
---+---
 I observed that my development server returned HTTP 500 status codes for
 all static files since I changed a bit of configuration in my settings.py
 file:

 settings.py file before modification:
 {{{
 ...
 if not DEBUG:
 STATIC_ROOT = os.environ.['DJANGO_STATIC_ROOT']
 ...
 }}}


 settings.py file after modification:
 {{{
 ...
 STATIC_ROOT = os.environ.get('DJANGO_STATIC_ROOT', None)
 ...
 }}}

 In my development environment, I don't set the 'DJANGO_STATIC_ROOT'
 environment variable since I only use the test server which is supposed to
 collect static files on the fly in the static dirs in the different apps.
 Here is the resulting exception and stack trace in the runserver window
 when I try to access a static file:

 {{{
 Traceback (most recent call last):
   File "/usr/lib/python3.3/wsgiref/handlers.py", line 137, in run
 self.result = application(self.environ, self.start_response)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/handlers.py", line 68, in __call__
 return super(StaticFilesHandler, self).__call__(environ,
 start_response)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/core/handlers/wsgi.py", line 206, in __call__
 response = self.get_response(request)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/handlers.py", line 58, in get_response
 return self.serve(request)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/handlers.py", line 51, in serve
 return serve(request, self.file_path(request.path), insecure=True)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/views.py", line 35, in serve
 absolute_path = finders.find(normalized_path)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/finders.py", line 238, in find
 for finder in get_finders():
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/finders.py", line 253, in get_finders
 yield get_finder(finder_path)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/utils/functional.py", line 32, in wrapper
 result = func(*args)
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/finders.py", line 265, in _get_finder
 return Finder()
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/site-
 packages/django/contrib/staticfiles/finders.py", line 60, in __init__
 if os.path.abspath(settings.STATIC_ROOT) == os.path.abspath(root):
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/posixpath.py",
 line 379, in abspath
 if not isabs(path):
   File "/home/madmox/.virtualenvs/django-dev/lib/python3.3/posixpath.py",
 line 64, in isabs
 return s.startswith(sep)
 AttributeError: 'NoneType' object has no attribute 'startswith'
 [04/Feb/2014 03:35:03] "GET /static/about/css/app.css HTTP/1.1" 500 59
 }}}

 This is a little bit unexpected since the documentation states the default
 value for STATIC_ROOT is None.

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

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


[Django] #21946: Calling get_object() on DeleteView resets the success_url

2014-02-03 Thread Django
#21946: Calling get_object() on DeleteView resets the success_url
---+
 Reporter:  django@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Generic views  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I was trying to do something with the object in the `def delete(self,
 request, *args, **kwargs)` method for a `DeleteView`, but found that
 calling `self.get_object()` *after* calling through to
 `super().delete(...)` causes problems:

 {{{
 class MyDeleteView(DeleteView):
 success_url = "/finish/"

 def delete(self, request, *args, **kwargs):
 response = super(MyDeleteView, self).delete(request, *args,
 **kwargs)
 object = self.get_object()
 # ... do something with object (or not)
 return response

 # urls.py:
 ...
 url(r'^thing/delete/(?P\d+)/, views.MyDeleteView.as_view(),
 name="thing_delete")
 ...

 }}}

 I'd expect this code to work, and that upon returning response you are
 redirected to `success_url` (i.e. `/finish/`). Instead, you are redirected
 back to the delete page, so if my `Thing` has a `pk=1`, then I would be
 redirected to `/thing/delete/1/`

 Now if I call `get_object()` *before* the call through to `super`
 everything works fine. It seems calling `get_object()` resets the
 `success_url`.

 I'm not sure if what I'm trying to do is not normal behaviour, but I'd
 have thought that trying to do something once an object has successfully
 been delete (i.e. only *after* the call to `super(...).delete(...)` has
 been made) should be OK.
 In this case, I'm trying to send an email saying `"Successfully deleted
 {object}"`

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

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


[Django] #21945: Overriding field in a ModelForm makes it required

2014-02-03 Thread Django
#21945: Overriding field in a ModelForm makes it required
---+
 Reporter:  Siecje |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have overriden the due_date field below and it becomes required. If I
 set required=False then it is not required but I get a validation error
 that it doesn't match a DateTime. However using widgets in the class Meta:
 works.


 {{{
 # due_date is a required field
 class AssignmentForm(forms.ModelForm):
due_date = forms.CharField(
widget=forms.TextInput(
attrs={'class': 'datepicker',
'data-date-format': '-mm-dd',
'placeholder': '-MM-DD'
}))

class Meta:
model = Assignment
fields = ['name', 'due_date']


 #due_date is not required
 class AssignmentForm(forms.ModelForm):

class Meta:
model = Assignment
fields = ['name', 'due_date']
widgets = {
'due_date': forms.TextInput(
attrs={
'class': 'datepicker',
'data-date-format': '-mm-dd',
'placeholder': '-MM-DD'
}
),}


 #models
 from django.db import models

 class Assignment(models.Model):
name = models.CharField(max_length=200)
due_date = models.DateTimeField(null=True, blank=True)

class Meta:
ordering = ['due_date']

def __unicode__(self):
return self.name
 }}}

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

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


Re: [Django] #21055: Error when implementing unknown language

2014-02-03 Thread Django
#21055: Error when implementing unknown language
--+--
 Reporter:  beck  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Translations  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by fernando.gutierrez@…):

 I think it is not related to one unknown language, probably related to two
 unknown languages and the way django tries to avoid sharing the
 translation object? This script fails for me in the third activate, it
 basically replicates what I am trying to do for a language chooser, were
 in one template I try to show the language name in it's own language:


 {{{
 from django.conf import settings
 gettext = lambda s: s
 settings.configure(
 CACHES = {
 'default': {
 'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
 }
 },
 LANGUAGES = (
 ('en', gettext('English')),
 ('zh-sg', gettext('Traditional Chinese (Singapore)')),
 ('zh-hk', gettext('Traditional Chinese (Hong Kong)')),
 )
 )

 from django.utils.translation.trans_real import activate, gettext
 activate('en')
 print(gettext('Hello, world.'))
 activate('zh-sg')
 print(gettext('Hello, world.'))
 activate('zh-hk')
 print(gettext('Hello, world.'))
 }}}

 Fails with:

 {{{
 $ python script.py
 Hello, world.
 Hello, world.
 Traceback (most recent call last):
   File "script.py", line 21, in 
 activate('zh-hk')
   File "/Users/***/.virtualenvs/cumutmp/lib/python2.7/site-
 packages/django/utils/translation/trans_real.py", line 194, in activate
 _active.value = translation(language)
   File "/Users/***/.virtualenvs/cumutmp/lib/python2.7/site-
 packages/django/utils/translation/trans_real.py", line 184, in translation
 current_translation = _fetch(language, fallback=default_translation)
   File "/Users/***/.virtualenvs/cumutmp/lib/python2.7/site-
 packages/django/utils/translation/trans_real.py", line 147, in _fetch
 res._info = res._info.copy()
 AttributeError: 'NoneType' object has no attribute '_info'
 }}}

 This is django 1.4.10 btw. (I've replaced my username with *)

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

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


Re: [Django] #21944: Add a warning for unsupported versions of the documentation

2014-02-03 Thread Django
#21944: Add a warning for unsupported versions of the documentation
--+
 Reporter:  timo  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  *.djangoproject.com   |  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 charettes):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.a5e3c41879802bd213c920c1677ff5b6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21943: Method parameters are garbled, no commas or spaces between them

2014-02-03 Thread Django
#21943: Method parameters are garbled, no commas or spaces between them
---+--
 Reporter:  mattvukas@…|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 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 timo):

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


Comment:

 This doesn't appear to be an issue with the 1.4 version of the docs and
 1.3 is no longer supported, so closing as "won't fix". If you care to
 investigate the issue and submit a pull request, we could merge it, but I
 think you will find it easiest just to use a newer version of the docs
 (and/or upgrade your version of Django to something that doesn't have
 security issues!) I've created ticket #21944 to add a warning to
 unsupported versions of the docs. Thank-you.

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

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


[Django] #21944: Add a warning for unsupported versions of the documentation

2014-02-03 Thread Django
#21944: Add a warning for unsupported versions of the documentation
+
   Reporter:  timo  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  *.djangoproject.com   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Like the yellow warning that floats at the top of the development version
 of the documentation (added in
 
https://github.com/django/djangoproject.com/commit/50bfb57e9e4a97fd95fa1abab9a1ad8d0f89f178),
 I'd like to add something similar (probably in red & white) for
 unsupported versions of the documentation to make users aware that they
 are using a version that has security flaws as well as to try to ward off
 tickets and pull requests for these versions. The message could be
 something like "This document is for an insecure version of Django that is
 no longer supported. Please upgrade to a newer 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.047526aeca89171b70b85b4b232f52a3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #21943: Method parameters are garbled, no commas or spaces between them

2014-02-03 Thread Django
#21943: Method parameters are garbled, no commas or spaces between them
---+
 Reporter:  mattvukas@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Went I went to this page in the Django 1.3 docs, the formatting appeared
 quite garbled:
 
https://docs.djangoproject.com/en/1.3/topics/auth/#django.contrib.auth.views.password_reset

 Some of the text was running off to the right, outside of the main white
 div. Also, all of the method headers appeared to be garbled. I've included
 one example below, which appears to be missing spaces or commas between
 the parameters:
 
'''password_reset(request[is_admin_sitetemplate_nameemail_template_namepassword_reset_formtoken_generatorpost_reset_redirectfrom_email])'''

 I had another developer at work confirm this on multiple browsers. Please
 get this fixed soon, 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.30dcb10d40ab6db4ffe67310af7ea993%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21939: Deprecate loading ssi/url tags from future (was: Reconsider "2.0" deprecation of ssi/url tags from future)

2014-02-03 Thread Django
#21939: Deprecate loading ssi/url tags from future
--+
 Reporter:  timo  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timo):

 * component:  Documentation => Template system
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 @jezdez -- sounds good to me. Should be relatively "easy pickings" by
 following the
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /submitting-patches/#deprecating-a-feature deprecating a feature] guide.

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

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


Re: [Django] #21939: Reconsider "2.0" deprecation of ssi/url tags from future

2014-02-03 Thread Django
#21939: Reconsider "2.0" deprecation of ssi/url tags from future
-+-
 Reporter:  timo |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
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
-+-

Comment (by jezdez):

 Looking back at the ticket I have to say, I think I still believed that a
 Django 2.0 would eventually be a API breaking release as Python 3. Now
 that we know how hostile that has been to Python I think we should
 reconsider this and use a proper deprecation roadmap.

 I also would rather not use those poor template tags for creating a
 precedence of deciding what 2.0 means -- it's a much bigger discussion and
 shouldn't bound to bad decisions of the past. Let's move the deprecation
 into 1.9 and be done with it.

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

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


Re: [Django] #21755: db.utils _route_db can raise AttributeError: 'NoneType' object has no attribute '_state'

2014-02-03 Thread Django
#21755: db.utils _route_db can raise AttributeError: 'NoneType' object has no
attribute '_state'
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (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 dcreech):

 Here is the stack trace:

 {{{
 ...
   File "C:\Python27\lib\site-packages\django\core\management\base.py",
 line 285, in execute
 output = self.handle(*args, **options)
   File "C:\Python27\lib\site-
 packages\django\contrib\auth\management\commands\createsuperuser.py", line
 116, in handle
 user_data[field_name] = field.clean(raw_value, None)
   File "C:\Python27\lib\site-
 packages\django\db\models\fields\__init__.py", line 255, in clean
 self.validate(value, model_instance)
   File "C:\Python27\lib\site-packages\django\db\models\fields\related.py",
 line 1199, in validate
 using = router.db_for_read(model_instance.__class__,
 instance=model_instance)
   File "C:\Python27\lib\site-packages\django\db\utils.py", line 250, in
 _route_db
 return hints['instance']._state.db or DEFAULT_DB_ALIAS
 AttributeError: 'NoneType' object has no attribute '_state'

 }}}

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

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


Re: [Django] #21755: db.utils _route_db can raise AttributeError: 'NoneType' object has no attribute '_state'

2014-02-03 Thread Django
#21755: db.utils _route_db can raise AttributeError: 'NoneType' object has no
attribute '_state'
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (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 cjerdonek):

 @davidc, for future reference, can you include the stack trace you are
 getting?  The stack trace I included in my original post references the
 username field (in the line, `username =
 self.username_field.clean(raw_value, None)`), so it looks like there is
 another place in Django's code base that is passing `None` as the model
 instance.

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

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


Re: [Django] #16192: Make unique_together error messages in ModelForms customizable

2014-02-03 Thread Django
#16192: Make unique_together error messages in ModelForms customizable
-+-
 Reporter:  leahculver   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by loic84):

 * cc: loic@… (added)
 * has_patch:  0 => 1
 * version:  1.6 => master


Comment:

 @glynjackson, I've had a go at this, could you please check if it solves
 your issue?

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

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

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


[Django] #21942: document Form.clean() in "Forms API" docs

2014-02-03 Thread Django
#21942: document Form.clean() in "Forms API" docs
--+
 Reporter:  cjerdonek |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.6
 Severity:  Normal|   Keywords:  forms,clean,validation
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Currently, the "Forms API" section of the Django docs (and in particular
 the [https://docs.djangoproject.com/en/dev/ref/forms/api/#using-forms-to-
 validate-data "Using forms to validate data"] section of that page), does
 not document `Form.clean()`, though the `Form.add_error()` documentation
 in that page references it.

 There is some documentation about `Form.clean()` in the
 [https://docs.djangoproject.com/en/dev/ref/forms/validation/ "Form and
 field validation"] page, so perhaps the Forms API docs can link there for
 its information (and/or vice versa).

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

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


Re: [Django] #21942: document Form.clean() in "Forms API" docs

2014-02-03 Thread Django
#21942: document Form.clean() in "Forms API" docs
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
  forms,clean,validation |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by cjerdonek):

 * cc: chris.jerdonek@… (added)
 * needs_better_patch:   => 0
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.cb6a0fd84b635f06ab9806cf11e5719f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21941: document kwargs parameter to url()

2014-02-03 Thread Django
#21941: document kwargs parameter to url()
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  url,kwargs   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by cjerdonek):

 * cc: chris.jerdonek@… (added)
 * needs_better_patch:   => 0
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a23bf061d83a6360186730e316a63585%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #21941: document kwargs parameter to url()

2014-02-03 Thread Django
#21941: document kwargs parameter to url()
--+
 Reporter:  cjerdonek |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.6
 Severity:  Normal|   Keywords:  url,kwargs
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Currently, the documentation of the
 [https://docs.djangoproject.com/en/dev/ref/urls/#url url()] function does
 not document the `kwargs` parameter.  This issue is to document that
 parameter.  The documentation should be sure to cover the cases of both
 function views and class-based views.

 I believe step (4) of the
 [https://docs.djangoproject.com/en/dev/topics/http/urls/#how-django-
 processes-a-request "How Django processes a request"] section should also
 be updated in this regard:

   "Once one of the regexes matches, Django imports and calls the given
 view, which is a simple Python function (or a class based view). The view
 gets passed an HttpRequest as its first argument and any values captured
 in the regex as remaining arguments."

 I don't know if the kwargs parameter is documented somewhere else in the
 docs.

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

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


[Django] #21940: Consistent contribute_to_class's virtual_only

2014-02-03 Thread Django
#21940: Consistent contribute_to_class's virtual_only
---+
 Reporter:  Kronuz |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I needed to create a field like class for my django project and I wanted
 it to be a virtual field... `virtual_only` is there for that reason, but
 my field was inheriting from `FileField`, and
 `FileField.contribute_to_class()` doesn't take `virtual_only` and so it
 doesn't passes it to `Field.contribute_to_class()`. I believe passing
 `virtual_only` attribute should be consistent across the source code. I'm
 attaching a simple patch to fix this. One warning would be for custom
 fields made by users which have their own `contribute_to_class` (those
 will need to be changed to properly receive the `virtual_only` parameter
 as optional.)

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

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


Re: [Django] #21939: Reconsider "2.0" deprecation of ssi/url tags from future

2014-02-03 Thread Django
#21939: Reconsider "2.0" deprecation of ssi/url tags from future
-+-
 Reporter:  timo |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
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
-+-

Comment (by aaugustin):

 There would be no 1.9 then ;-)

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

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


Re: [Django] #21939: Reconsider "2.0" deprecation of ssi/url tags from future

2014-02-03 Thread Django
#21939: Reconsider "2.0" deprecation of ssi/url tags from future
-+-
 Reporter:  timo |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
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
-+-

Comment (by claudep):

 We might also choose 2.0 as the Django version where we drop Python 2
 support.

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

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


Re: [Django] #21755: db.utils _route_db can raise AttributeError: 'NoneType' object has no attribute '_state'

2014-02-03 Thread Django
#21755: db.utils _route_db can raise AttributeError: 'NoneType' object has no
attribute '_state'
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (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 davidc):

 I am running into the same problem for a foreign key in the
 `REQUIRED_FIELDS` of my custom user model. It does not have to be the
 `USERNAME_FIELD`. I think this would be much more common. In my case I
 need all users to have a department.

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

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


Re: [Django] #21882: Early modification bug in Django 1.6. with mark_safe + ugettext_lazy

2014-02-03 Thread Django
#21882: Early modification bug in Django 1.6. with mark_safe + ugettext_lazy
-+-
 Reporter:  nealtodd |Owner:  bmispelon
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.6
  Internationalization   |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  mark_safe|  Needs documentation:  0
  ugettext_lazy  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * has_patch:  0 => 1


Comment:

 Well, this turned out to be more complicated than what I originally
 thought.

 Calling `force_text` inside the function works but only because it removes
 the lazy property of the string which is not really what you want.

 What's needed instead is a way to mark `Promise` objects as safe but while
 still delaying their evaluation.
 I achieved this by creating subclasses of both `Promise` and `SafeData`
 and the result seems to be working (all the test pass and the regression
 test I added is fixed).

 Here's the pull request: https://github.com/django/django/pull/2234/files
 Reviews welcome.

 Hopefully this should make it into the upcoming 1.6.2 release, provided I
 can get another set of eyes on the patch to make sure it's not doing
 anything too crazy.

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

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


Re: [Django] #16192: Make unique_together error messages in ModelForms customizable

2014-02-03 Thread Django
#16192: Make unique_together error messages in ModelForms customizable
-+-
 Reporter:  leahculver   |Owner:  nobody
 Type:  New feature  |   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 glynjackson):

 More attention please! Are there any plans for this yet? I'm not confident
 enough yet to submit a patch but would like to work on this with someone.

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

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


Re: [Django] #16192: Make unique_together error messages in ModelForms customizable

2014-02-03 Thread Django
#16192: Make unique_together error messages in ModelForms customizable
-+-
 Reporter:  leahculver   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (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 glynjackson):

 * version:  1.3 => 1.6


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

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


Re: [Django] #21939: Reconsider "2.0" deprecation of ssi/url tags from future

2014-02-03 Thread Django
#21939: Reconsider "2.0" deprecation of ssi/url tags from future
-+-
 Reporter:  timo |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
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
-+-

Comment (by aaugustin):

 I think 2.0 is simply the version after 1.9. Unless someone says
 otherwise, this is going to happen ;-)

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

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


[django/django] e7e343: Fixed #21934 -- Added unicode support in GoogleMap...

2014-02-03 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e7e3435b4d0d409aa98a66d2d7961f7541d19f9f
  
https://github.com/django/django/commit/e7e3435b4d0d409aa98a66d2d7961f7541d19f9f
  Author: David Fischer 
  Date:   2014-02-03 (Mon, 03 Feb 2014)

  Changed paths:
M django/contrib/gis/maps/google/gmap.py
M django/contrib/gis/maps/google/overlays.py
M django/contrib/gis/maps/google/zoom.py
A django/contrib/gis/tests/maps/tests.py
A gis/tests/maps/__init__.py b/django/contrib/gis/tests/maps/__init__.py

  Log Message:
  ---
  Fixed #21934 -- Added unicode support in GoogleMap class


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52efb35d8c1cf_7a1256fd4c794e0%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.


[django/django] 6e0f1b: Moved a GoogleMap test

2014-02-03 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6e0f1bc06df87453875e639f66cb608bcb393429
  
https://github.com/django/django/commit/6e0f1bc06df87453875e639f66cb608bcb393429
  Author: Claude Paroz 
  Date:   2014-02-03 (Mon, 03 Feb 2014)

  Changed paths:
M django/contrib/gis/tests/geoadmin/tests.py
M django/contrib/gis/tests/maps/tests.py

  Log Message:
  ---
  Moved a GoogleMap test


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52efb4303a051_32f4893d48865ed%40hookshot-fe4-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21934: Missing import statements (e.g. unicode literals) in contrib.gis

2014-02-03 Thread Django
#21934: Missing import statements (e.g. unicode literals) in contrib.gis
+
 Reporter:  david.fischer.ch@…  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  unicode,i18n| Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"e7e3435b4d0d409aa98a66d2d7961f7541d19f9f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e7e3435b4d0d409aa98a66d2d7961f7541d19f9f"
 Fixed #21934 -- Added unicode support in GoogleMap class
 }}}

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

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


Re: [Django] #7623: Multi-table inheritance does not allow linking new instance of child model to existing parent model instance.

2014-02-03 Thread Django
#7623: Multi-table inheritance does not allow linking new instance of child 
model
to existing parent model instance.
-+-
 Reporter:  brooks.travis@…  |Owner:
 Type:  Bug  |  elektrrrus
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  model-inheritance,   | Triage Stage:  Accepted
  multi-table-inheritance|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by juan64645@…):

 Hello! I am new in django. I have a problem like this.
 I want to do something like this(in inheritance multi-table):

 in view.py

 restaurant = Restaurant(place_ptr=place)
 restaurant.save()

 assuming that the attributes of restaurant hold null=True.
 but Restaurant(place_ptr=place) returns nothing.

 My vercion of django is 1.5
 They say about this? Is there any alternative?
 That is not to create a new restaurant and it was clear the place, because
 it is very ugly.

 From already thank you very much!

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

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


Re: [Django] #21933: UnicodeDecodeError when writing unicode to stdout of management command

2014-02-03 Thread Django
#21933: UnicodeDecodeError when writing unicode to stdout of management command
---+--
 Reporter:  synotna|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.6
 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 claudep):

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


Comment:

 Your `output` attribute in the above code example should be prefixed by
 `u`.

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

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


[Django] #21939: Reconsider "2.0" deprecation of ssi/url tags from future

2014-02-03 Thread Django
#21939: Reconsider "2.0" deprecation of ssi/url tags from future
+
   Reporter:  timo  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In #18037, it was decided to add this to the deprecation timeline under
 2.0: "`ssi` and `url` template tags will be removed from the `future`
 template tag library (used during the 1.3/1.4 deprecation period)."

 At this time, it appears unlikely (from the discussion I've come across)
 that Django will have a "2.0" in the sense of a major backwards
 incompatible release in the foreseeable future. Thus, I think having this
 on the deprecation timeline may create some confusion. If we want to keep
 it, I think we should at least add some clarifying text as to what "2.0"
 means.

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

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


Re: [Django] #21920: Please document mod_python support drop in release notes

2014-02-03 Thread Django
#21920: Please document mod_python support drop in release notes
--+
 Reporter:  anonymous |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.5
 Severity:  Normal|   Resolution:  wontfix
 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 timo):

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


Comment:

 I'm made the change to the deprecation timeline and added better links to
 the release notes in the commit above. Closing this ticket as "won't fix"
 since we are technically not addressing what's in the summary/description
 of the ticket.

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

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


[django/django] d4a501: Reordered deprecation timeline and added back old ...

2014-02-03 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d4a5019bef116028edb6e66eac9156da96a3d704
  
https://github.com/django/django/commit/d4a5019bef116028edb6e66eac9156da96a3d704
  Author: Tim Graham 
  Date:   2014-02-03 (Mon, 03 Feb 2014)

  Changed paths:
M docs/internals/deprecation.txt
M docs/releases/1.4.txt
M docs/releases/1.5.txt
M docs/releases/1.6.txt
M docs/releases/1.7.txt

  Log Message:
  ---
  Reordered deprecation timeline and added back old info; refs #21920.


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52ef9a7d91aaf_a2312fbd44158b7%40hookshot-fe9-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21920: Please document mod_python support drop in release notes

2014-02-03 Thread Django
#21920: Please document mod_python support drop in release notes
--+
 Reporter:  anonymous |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.5
 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
--+

Comment (by Tim Graham ):

 In [changeset:"d4a5019bef116028edb6e66eac9156da96a3d704"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d4a5019bef116028edb6e66eac9156da96a3d704"
 Reordered deprecation timeline and added back old info; refs #21920.
 }}}

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

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


Re: [Django] #21934: Missing import statements (e.g. unicode literals) in contrib.gis

2014-02-03 Thread Django
#21934: Missing import statements (e.g. unicode literals) in contrib.gis
+
 Reporter:  david.fischer.ch@…  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  unicode,i18n| Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by david.fischer.ch@…):

 Please find this new commit https://github.com/davidfischer-
 ch/django/commit/4f810ee43d2cfe0af9dc0076fb1b0c5754e9d65f.

 I destroyed my previous fork to start from scratch.

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

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


Re: [Django] #21934: Missing import statements (e.g. unicode literals) in contrib.gis (was: Missing import statements (e.g. unicode literals))

2014-02-03 Thread Django
#21934: Missing import statements (e.g. unicode literals) in contrib.gis
+
 Reporter:  david.fischer.ch@…  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  unicode,i18n| Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by timo):

 * status:  closed => new
 * needs_better_patch:  0 => 1
 * component:  Uncategorized => GIS
 * has_patch:  0 => 1
 * resolution:  needsinfo =>
 * stage:  Unreviewed => Accepted


Comment:

 I believe this references [https://github.com/django/django/pull/1797 this
 PR].

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

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


Re: [Django] #21920: Please document mod_python support drop in release notes

2014-02-03 Thread Django
#21920: Please document mod_python support drop in release notes
--+
 Reporter:  anonymous |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.5
 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 timo):

 * status:  new => assigned
 * owner:  nobody => timo
 * type:  Uncategorized => Cleanup/optimization


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

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


Re: [Django] #21934: Missing import statements (e.g. unicode literals)

2014-02-03 Thread Django
#21934: Missing import statements (e.g. unicode literals)
+--
 Reporter:  david.fischer.ch@…  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Uncategorized   |  Version:  master
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  unicode,i18n| 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):

 * resolution:  invalid => needsinfo


Comment:

 I wouldn't call that bug "invalid". It's true that we I dropped the ball
 mid-way with regard to unicode_literals while porting to Python 3.

 I stopped when I reached code that wasn't well tested, mostly in
 django.contrib.gis, because adding unicode_literals created actual bugs.
 Adding unicode_literals to every file isn't an option. It would trigger a
 slew of regressions.

 That said, we should continue adding unicode_literals when we have the
 opportunity, which means, when we add tests.

 Re-closing "needsinfo", please provide the stack trace for the problem you
 encountered and 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/084.7f195c5db23923c50c9364c479a73247%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21920: Please document mod_python support drop in release notes

2014-02-03 Thread Django
#21920: Please document mod_python support drop in release notes
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.5
 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
---+

Comment (by aaugustin):

 Yes, reworking the deprecation timeline is the most sensible way forward.

 We removed obsolete info because it was at the top. If we reverse the
 order, there's no problem with keeping the entire history. The relevant
 info will be in the first three sections.

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

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


Re: [Django] #21934: Missing import statements (e.g. unicode literals)

2014-02-03 Thread Django
#21934: Missing import statements (e.g. unicode literals)
+--
 Reporter:  david.fischer.ch@…  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Uncategorized   |  Version:  master
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  unicode,i18n| 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:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 "Use `from __future__ import unicode_literals`" is a suggested practice.
 It's a *good* suggested practice, a a helpful suggested practice for
 maintenance purposes, but It's entirely possible to write working code
 that doesn't use the unicode literals import. Django has a lot of legacy
 code that has been tested and works fine (as far as our tests reveal)
 without these imports existing.

 "Just Add unicode_literals" isn't a magic bug fixing strategy - and even
 if it was, we'd need a test that demonstrates the problem that it solves.

 If you're getting a stack trace, then there's either a bug in your code,
 or there's a bug in Django. Unfortunately, instead of showing us some
 sample code that causes a problem, or showing us the actual stack trace
 you've received, you've chosen to complain about absolute adherence to a
 suggested coding guideline (and I'll note that the link you provide is
 about using unicode in your own code, not Django's internal coding
 standards).

 Closing as invalid because there's nothing actionable here.

 If you want to provide sample code that crashes, or a specific test case
 where unicode_literals will fix the problem -- 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/084.566d0b53f53d546da9aaaf248a29ae6c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21920: Please document mod_python support drop in release notes

2014-02-03 Thread Django
#21920: Please document mod_python support drop in release notes
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.5
 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
---+

Comment (by timo):

 As I alluded to above, I think we may not want to make removals like
 [ddd3926280725fc4cedd1c511a95a57db7dde488] if we aren't also removing the
 corresponding release notes. Otherwise, the link to "deprecation plan" in
 the sentence from the release notes "We’ve also dropped some features,
 which are detailed in our deprecation plan" leads to a deprecation plan
 which doesn't include the notes for that version. To be most helpful, I
 think we should also link to the specific section of the deprecation plan
 for each version. Switching the ordering of the deprecation timeline to
 descending order (oldest release last) like we do for the release notes
 should help keep more irrelevant things out of the way. Any objections to
 these changes?

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

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


Re: [Django] #16246: Small problems with new generic IP address field tests on Postgres 8.4

2014-02-03 Thread Django
#16246: Small problems with new generic IP address field tests on Postgres 8.4
---+
 Reporter:  ramiro |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.4-rc-1
 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 eATBZLYSmjnuQBbqS):

 * version:  master => 1.4-rc-1


Comment:

 http://reglenna.com/doc/#yw12>morea€¦ ativan withdrawal
 insomnia - ativan addiction substance abuse

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

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


[Django] #21938: Improve docs/ref/views.txt

2014-02-03 Thread Django
#21938: Improve docs/ref/views.txt
+
   Reporter:  timo  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  1.6
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 As noted in [https://github.com/django/django/pull/2231 this PR], the
 "Built-in views" page isn't very useful. We should expand this page into a
 proper reference guide for the functions in `django.views`, probably
 moving some content from `topics/http/views.txt`.

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

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


[Django] #21937: Add forms_valid for the mixin to work with django-extra-view's UpdateWithInlinesView

2014-02-03 Thread Django
#21937: Add forms_valid for the mixin to work with django-extra-view's
UpdateWithInlinesView
+---
 Reporter:  david.fischer.ch@…  |  Owner:  nobody
 Type:  New feature | Status:  new
Component:  contrib.messages|Version:  master
 Severity:  Normal  |   Keywords:  extra-views,mixin
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+---
 For my own purposes I am using on of the mixins of the project called
 django-extra-views.

 This mixin uses a method called forms_valid that was missing to allow
 using the messages framework too.

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

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


[Django] #21936: Add delete message mixin

2014-02-03 Thread Django
#21936: Add delete message mixin
+
 Reporter:  david.fischer.ch@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  contrib.messages|Version:  master
 Severity:  Normal  |   Keywords:  mixin
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 Add a mixin to show a message on successful object deletion.

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

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


[Django] #21935: Add the object to data used for the message

2014-02-03 Thread Django
#21935: Add the object to data used for the message
+
 Reporter:  david.fischer.ch@…  |  Owner:  nobody
 Type:  New feature | Status:  new
Component:  contrib.messages|Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 It would be interesting to add the object into the cleaned_data dictionary
 to allow displaying a success message with some values taken from the
 object's attributes.

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

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


[Django] #21934: Missing import statements (e.g. unicode literals)

2014-02-03 Thread Django
#21934: Missing import statements (e.g. unicode literals)
+--
 Reporter:  david.fischer.ch@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Uncategorized   |Version:  master
 Severity:  Normal  |   Keywords:  unicode,i18n
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 There are a lot of source files that does not start with :

 {{{
 from __future__ import unicode_literals
 }}}

 I am developing a website that uses the GeoDjango framework to display
 Google-based maps with french markers.
 With the current release of the framework my website crashes with a bad
 stack trace.

 I haven't a lot of time to contribute to this project. So I do not want to
 spend hours only to develop unit-tests that prove my small contribution
 make it work.

 I already tried to contribute to this project, I spent few minutes to fix
 this issue and then hours to implement the unit-test that anyone can run
 before / after the modifications to see that this will fix the issue.

 Please, follow your own guildelines !!

 https://docs.djangoproject.com/en/dev/ref/unicode/

 ... And add more accents to the strings in the unit-tests.

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

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


[Django] #21933: UnicodeDecodeError when writing unicode to stdout of management command

2014-02-03 Thread Django
#21933: UnicodeDecodeError when writing unicode to stdout of management command
---+
 Reporter:  synotna|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In a management command, if you include unicode characters when writing to
 stdout (with self.stdout.write) you will get a UnicodeDecodeError

 This happens even if the system locale is utf-8, and self.stdout.encoding
 is utf-8, and you .decode(self.stdout.encoding,'replace')

 A workaround is to always .decode() to ascii, and if that is what should
 be done it should be documented at
 https://docs.djangoproject.com/en/dev/howto/custom-management-commands/


 /myapp/management/commands/unicode_test.py
 {{{
 # -*- coding: utf-8 -*-
 from django.core.management.base import BaseCommand

 class Command(BaseCommand):
 args = ''
 help = 'Do something'

 def handle(self, *args, **options):
 output = 'Σάββα▒^▒ο'
 self.stdout.write('Output: {}'.format(output))
 }}}

 {{{
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/tech/.pyenv/versions/esldj-all-in-one-2.7.6/lib/python2.7
 /site-packages/django/core/management/__init__.py", line 399, in
 execute_from_command_line
 utility.execute()
   File "/home/tech/.pyenv/versions/esldj-all-in-one-2.7.6/lib/python2.7
 /site-packages/django/core/management/__init__.py", line 392, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/tech/.pyenv/versions/esldj-all-in-one-2.7.6/lib/python2.7
 /site-packages/django/core/management/base.py", line 242, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/tech/.pyenv/versions/esldj-all-in-one-2.7.6/lib/python2.7
 /site-packages/django/core/management/base.py", line 285, in execute
 output = self.handle(*args, **options)
   File "/home/tech/esldj/all-in-
 one/go4/management/commands/unicode_test.py", line 10, in handle
 self.stdout.write('Output: {}'.format(output))
   File "/home/tech/.pyenv/versions/esldj-all-in-one-2.7.6/lib/python2.7
 /site-packages/django/core/management/base.py", line 65, in write
 if ending and not msg.endswith(ending):
 }}}

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

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


Re: [Django] #21920: Please document mod_python support drop in release notes

2014-02-03 Thread Django
#21920: Please document mod_python support drop in release notes
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.5
 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
---+

Comment (by anonymous):

 Man, I'm not complaining about my code being broken.

 I'm merely saying that mod_python removal would be a nice addition to 1.5
 release notes, to improve the overall quality of the documentation (the
 section that bug was filled in).

 This is my last try. I won't argue more. Have it your way.

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

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


[Django] #21932: urlise filter not working with links in other tags

2014-02-03 Thread Django
#21932: urlise filter not working with links in other tags
---+---
 Reporter:  smortus@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Template   |Version:  master
  system   |   Keywords:  django,template,filter,urlize
 Severity:  Normal |  Has patch:  0
 Triage Stage:  Unreviewed |  UI/UX:  0
Easy pickings:  0  |
---+---
 >>> from django.template.defaultfilters import urlize

 >>> urlize("http://s.com/topic/110/boltalka/;)
 u'http://s.com/topic/110/boltalka/;
 rel="nofollow">http://s.com/topic/110/boltalka/'

 >>> urlize("http://s.com/topic/110/boltalka/")
 u'http://s.com/topic/110/boltalka/'

 BUT (with spaces)!

 >>> urlize(" http://s.com/topic/110/boltalka/ ")
 u' http://s.com/topic/110/boltalka/;
 rel="nofollow">http://s.com/topic/110/boltalka/ '


 This can be useful with js wysiwys editor (CKEditor, 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.e0a3f543f2fffb60be7d38488500b5be%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.