Re: [Django] #15841: User model conflicts with CommentDetailsForm (was: User conflict with CommentDetailsForm)

[Django]

#15841: User model conflicts with CommentDetailsForm
--+
   Reporter:  admin@… |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  contrib.comments
Version:  1.3 | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by admin@…):

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


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

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

Re: [Django] #11834: Colorized technical_500_response: django code is green, user code is red.

[Django]

#11834: Colorized technical_500_response: django code is green, user code is 
red.
-+-
   Reporter:  buriy  |Owner:  buriy
   Type:  New|   Status:  assigned
  feature|Component:  User Experience
  Milestone: | Severity:  Normal
Version:  1.1| Keywords:  colorize 500 http500
 Resolution: |  prettify
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  1  |
-+-
Changes (by SmileyChris):

 * needs_better_patch:  0 => 1


Comment:

 (or perhaps you don't even need that `''` option taking a second look)

 In any case, we can't use a dictionary here for the color scheme because
 the order isn't guaranteed so marking as needs improvement.

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

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

Re: [Django] #11834: Colorized technical_500_response: django code is green, user code is red.

[Django]

#11834: Colorized technical_500_response: django code is green, user code is 
red.
-+-
   Reporter:  buriy  |Owner:  buriy
   Type:  New|   Status:  assigned
  feature|Component:  User Experience
  Milestone: | Severity:  Normal
Version:  1.1| Keywords:  colorize 500 http500
 Resolution: |  prettify
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-

Comment (by SmileyChris):

 I'm confused. Why would you need to disable this because you hit a Django
 bug? It still helps with readability of the traceback.

 If you really wanted to though, you can disable it by setting
 `TRACEBACK_COLOR_SCHEME = {'': ('#bbe',)}` (althought it would be nicer if
 you could just set it to `None` for no colouring).

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

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |Owner:  jkocherhans
  Honza_Kral |   Status:  assigned
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Replying to [comment:118 kmtracey]:
 > I experimented with this a bit today, and was able to use the doc to
 implement my particular need without too much difficulty so that is good.

 Thanks for experimenting with the patch, Karen!

 > One thing I thought was odd though was that my filter's `get_query_set`
 is called even if its `query_parameter_name` is not in request.GET, and as
 a result my `get_query_set` must be coded to handle that case properly
 (return the queryset unchanged). If it is not coded properly the result is
 that my filter limits the queryset used even when its "All" choice is the
 selected choice for it. I think it would be preferable to avoid calling
 the `get_query_set` for filters whose query parameters aren't in
 `request.GET`.

 Yes, that's good point. I'll try to normalise that.

 > There is no mention anywhere I could see of why `request` is passed into
 `get_choices` and `get_queryset`, nor is it used that I can see anywhere
 in the samples. For what kinds of filters might this be used?

 It is just there for your convenience in case you want to vary the list of
 choices or the list of results, for example, based on who is logged in.
 There's a note in the doc for `get_choices()` but not for
 `get_query_set()` yet. I'll try to improve the doc.

 > My particular use case is a slight modification of an existing admin
 filter: I want to filter by a related field, but I only want a subset of
 the existing values to appear in the choices. It was not hard to implement
 as a !ListFilter but after getting `get_query_set` wrong the first time it
 occurred to me it would be better if I could just override the
 `get_choices` method for the existing admin filter that already filtered
 the way I wanted. Unfortunately that existing admin filter isn't
 implemented as a !ListFilter so I can't do that, apparently I'd have to
 choose the scary-sounding alternate option of providing a tuple of field
 name and class inheriting from !FieldListFilter (which is noted as being
 internal and prone to refactoring). Is it not possible to unify things so
 that it is easy to both write completely new-and-different filters and
 ones that are minor tweaks to what admin already provides?

 In your use case it might make more sense to override the
 `django.contrib.admin.filterspecs.RelatedFieldListFilter._choices()`
 method. However you'll see that its code is quite opaque and not so fun to
 play with.

 Your remarks make me realise that we should perhaps do a bigger refactor
 of the filtering system. The "old" filters (which currently inherit from
 `FieldListFilter` in my patch) only take care of managing the query string
 and the options to be displayed on the admin UI, where
 `ChangeList.get_query_set()` actually does the filtering on the queryset.
 This makes sense since both the ChangeList and the filters know how fields
 work and how they're supposed to be filtered (e.g. by appending
 "`__isnull`" to the field name). However, `ChangeList.get_query_set()`
 cannot anticipate how the queryset will be filtered by a custom filter,
 and therefore it has to delegate the actual filtering to the custom
 `ListFilter` object.

 Also, currently the `ListFilter` only allows for one query string
 parameter, mostly for the sake of simplicity. However, some field filters
 allow for multiple ones, e.g. "`fieldname__exact`" or
 "`fieldname__isnull`" for `RelatedFieldListFilter`.

 So, to make things more consistent, we should perhaps delegate all that
 logic to the filters themselves, including the queryset filtering which is
 currently done by the `ChangeList` object for field names.

 I'm also going to try and make the field filters follow the new structure,
 for example by overriding `get_choices()` to return a list of option
 tuples, instead of having to directly yield the iteration items in
 `_choices()`. Hopefully this will be possible without too many ugly
 internal hacks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django 

Re: [Django] #11834: Colorized technical_500_response: django code is green, user code is red.

[Django]

#11834: Colorized technical_500_response: django code is green, user code is 
red.
-+-
   Reporter:  buriy  |Owner:  buriy
   Type:  New|   Status:  assigned
  feature|Component:  User Experience
  Milestone: | Severity:  Normal
Version:  1.1| Keywords:  colorize 500 http500
 Resolution: |  prettify
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-

Comment (by Alex):

 As someone who hits Django bugs often enough (if you aren't pushing the
 framework to the limit you're doing something wrong :D) I'd really want a
 way to disable this.

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

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

Re: [Django] #15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their Content-Type

[Django]

#15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their
Content-Type
-+-
   Reporter:  simon  |Owner:  jasonkotenko
   Type: |   Status:  reopened
  Uncategorized  |Component:  contrib.syndication
  Milestone:  1.3| Severity:  Normal
Version:  1.2| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by philip@…):

 * status:  closed => reopened
 * type:   => Uncategorized
 * resolution:  fixed =>
 * severity:   => Normal


Comment:

 The charset should be “utf-8” rather than “utf8”, since the latter isn't
 what's registered with IANA. See: http://www.w3.org/International/O-HTTP-
 charset.

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

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

Re: [Django] #11834: Colorized technical_500_response: django code is green, user code is red.

[Django]

#11834: Colorized technical_500_response: django code is green, user code is 
red.
-+-
   Reporter:  buriy  |Owner:  buriy
   Type:  New|   Status:  assigned
  feature|Component:  User Experience
  Milestone: | Severity:  Normal
Version:  1.1| Keywords:  colorize 500 http500
 Resolution: |  prettify
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-

Comment (by SmileyChris):

 From the group discussion:

 > The agreement between core devs and me (or at least how i get it) was
 > that we decided that this patch needs to be a part of larger "debug
 > page usability improvement suite".

 I'd be happy to just see just this in for now. We can iteratively improve
 the debug page, and getting colorization in would be a great start.

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

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

Re: [Django] #11834: Colorized technical_500_response: django code is green, user code is red.

[Django]

#11834: Colorized technical_500_response: django code is green, user code is 
red.
-+-
   Reporter:  buriy  |Owner:  buriy
   Type:  New|   Status:  assigned
  feature|Component:  User Experience
  Milestone: | Severity:  Normal
Version:  1.1| Keywords:  colorize 500 http500
 Resolution: |  prettify
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-
Changes (by SmileyChris):

 * needs_docs:  0 => 1
 * type:   => New feature
 * severity:   => Normal
 * needs_tests:  0 => 1
 * milestone:  1.3 =>


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

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

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

[noreply]

Author: adrian
Date: 2011-04-17 13:55:26 -0700 (Sun, 17 Apr 2011)
New Revision: 16037

Modified:
   django/trunk/docs/ref/class-based-views.txt
Log:
Fixed #15800 -- Fixed error in class-based-views docs. Thanks, Natim

Modified: django/trunk/docs/ref/class-based-views.txt
===
--- django/trunk/docs/ref/class-based-views.txt 2011-04-17 20:51:19 UTC (rev 
16036)
+++ django/trunk/docs/ref/class-based-views.txt 2011-04-17 20:55:26 UTC (rev 
16037)
@@ -480,7 +480,7 @@
 
 **Mixins**
 
-* :class:`django.views.generic.forms.FormMixin`
+* :class:`django.views.generic.edit.FormMixin`
 * :class:`django.views.generic.detail.SingleObjectMixin`
 
 .. attribute:: success_url

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

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

[noreply]

Author: adrian
Date: 2011-04-17 13:51:19 -0700 (Sun, 17 Apr 2011)
New Revision: 16036

Modified:
   django/trunk/docs/ref/utils.txt
Log:
Fixed #15816 -- Changed docs/ref/utils.txt to refer to 
django.utils.datastructures instead of just SortedDict. The other stuff is 
still undocumented, which is probably a good thing

Modified: django/trunk/docs/ref/utils.txt
===
--- django/trunk/docs/ref/utils.txt 2011-04-17 20:46:48 UTC (rev 16035)
+++ django/trunk/docs/ref/utils.txt 2011-04-17 20:51:19 UTC (rev 16036)
@@ -98,11 +98,11 @@
 cache, this just means that we have to build the response once to get at
 the Vary header and so at the list of headers to use for the cache key.
 
-SortedDict
-==
+``django.utils.datastructures``
+===
 
 .. module:: django.utils.datastructures
-   :synopsis: A dictionary that keeps its keys in the order in which they're 
inserted.
+   :synopsis: Data structures that aren't in Python's standard library.
 
 .. class:: SortedDict
 

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

[Changeset] r16035 - django/trunk/docs/releases

[noreply]

Author: adrian
Date: 2011-04-17 13:46:48 -0700 (Sun, 17 Apr 2011)
New Revision: 16035

Modified:
   django/trunk/docs/releases/1.3.txt
Log:
Fixed #15821 -- Removed incorrect link from docs/releases/1.3.txt

Modified: django/trunk/docs/releases/1.3.txt
===
--- django/trunk/docs/releases/1.3.txt  2011-04-17 20:45:06 UTC (rev 16034)
+++ django/trunk/docs/releases/1.3.txt  2011-04-17 20:46:48 UTC (rev 16035)
@@ -353,8 +353,8 @@
 
 Prior to Django 1.2.5, the Django administrative interface allowed
 filtering on any model field or relation -- not just those specified
-in ``list_filter`` -- via query string manipulation. Due to `security
-issues`_ reported to us, however, query string lookup arguments in the
+in ``list_filter`` -- via query string manipulation. Due to security
+issues reported to us, however, query string lookup arguments in the
 admin must be for fields or relations specified in ``list_filter`` or
 ``date_hierarchy``.
 

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

[Changeset] r16034 - in django/trunk: django/conf django/conf/project_template docs/howto docs/ref docs/topics

[noreply]

Author: adrian
Date: 2011-04-17 13:45:06 -0700 (Sun, 17 Apr 2011)
New Revision: 16034

Modified:
   django/trunk/django/conf/global_settings.py
   django/trunk/django/conf/project_template/settings.py
   django/trunk/docs/howto/initial-data.txt
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/topics/install.txt
Log:
Fixed #15822 -- Removed references to the v1 postgresql backend (which has been 
removed). Thanks for the patch, aaugustin

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2011-04-17 14:27:53 UTC (rev 
16033)
+++ django/trunk/django/conf/global_settings.py 2011-04-17 20:45:06 UTC (rev 
16034)
@@ -143,7 +143,7 @@
 
 # Database connection info.
 # Legacy format
-DATABASE_ENGINE = ''   # 'postgresql_psycopg2', 'postgresql', 'mysql', 
'sqlite3' or 'oracle'.
+DATABASE_ENGINE = ''   # 'postgresql_psycopg2', 'mysql', 'sqlite3' or 
'oracle'.
 DATABASE_NAME = '' # Or path to database file if using sqlite3.
 DATABASE_USER = '' # Not used with sqlite3.
 DATABASE_PASSWORD = '' # Not used with sqlite3.

Modified: django/trunk/django/conf/project_template/settings.py
===
--- django/trunk/django/conf/project_template/settings.py   2011-04-17 
14:27:53 UTC (rev 16033)
+++ django/trunk/django/conf/project_template/settings.py   2011-04-17 
20:45:06 UTC (rev 16034)
@@ -11,7 +11,7 @@
 
 DATABASES = {
 'default': {
-'ENGINE': 'django.db.backends.', # Add 'postgresql_psycopg2', 
'postgresql', 'mysql', 'sqlite3' or 'oracle'.
+'ENGINE': 'django.db.backends.', # Add 'postgresql_psycopg2', 'mysql', 
'sqlite3' or 'oracle'.
 'NAME': '',  # Or path to database file if using 
sqlite3.
 'USER': '',  # Not used with sqlite3.
 'PASSWORD': '',  # Not used with sqlite3.

Modified: django/trunk/docs/howto/initial-data.txt
===
--- django/trunk/docs/howto/initial-data.txt2011-04-17 14:27:53 UTC (rev 
16033)
+++ django/trunk/docs/howto/initial-data.txt2011-04-17 20:45:06 UTC (rev 
16034)
@@ -136,18 +136,18 @@
 --
 
 There's also a hook for backend-specific SQL data. For example, you
-can have separate initial-data files for PostgreSQL and MySQL. For
+can have separate initial-data files for PostgreSQL and SQLite. For
 each app, Django looks for a file called
 ``/sql/..sql``, where  is
 your app directory,  is the model's name in lowercase
 and  is the last part of the module name provided for the
 :setting:`ENGINE` in your settings file (e.g., if you have defined a
 database with an :setting:`ENGINE` value of
-``django.db.backends.postgresql``, Django will look for
-``/sql/.postgresql.sql``).
+``django.db.backends.sqlite3``, Django will look for
+``/sql/.sqlite3.sql``).
 
 Backend-specific SQL data is executed before non-backend-specific SQL
 data. For example, if your app contains the files ``sql/person.sql``
-and ``sql/person.postgresql.sql`` and you're installing the app on
-PostgreSQL, Django will execute the contents of
-``sql/person.postgresql.sql`` first, then ``sql/person.sql``.
+and ``sql/person.sqlite3.sql`` and you're installing the app on
+SQLite, Django will execute the contents of
+``sql/person.sqlite.sql`` first, then ``sql/person.sql``.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2011-04-17 14:27:53 UTC (rev 16033)
+++ django/trunk/docs/ref/settings.txt  2011-04-17 20:45:06 UTC (rev 16034)
@@ -394,7 +394,6 @@
 The database backend to use. The built-in database backends are:
 
 * ``'django.db.backends.postgresql_psycopg2'``
-* ``'django.db.backends.postgresql'``
 * ``'django.db.backends.mysql'``
 * ``'django.db.backends.sqlite3'``
 * ``'django.db.backends.oracle'``
@@ -498,8 +497,8 @@
 string is passed directly through to the database, so its format is
 backend-specific.
 
-Supported for the PostgreSQL_ (``postgresql``, ``postgresql_psycopg2``) and
-MySQL_ (``mysql``) backends.
+Supported for the PostgreSQL_ (``postgresql_psycopg2``) and MySQL_ (``mysql``)
+backends.
 
 .. _PostgreSQL: http://www.postgresql.org/docs/8.2/static/multibyte.html
 .. _MySQL: http://dev.mysql.com/doc/refman/5.0/en/charset-database.html

Modified: django/trunk/docs/topics/install.txt
===
--- django/trunk/docs/topics/install.txt2011-04-17 14:27:53 UTC (rev 
16033)
+++ django/trunk/docs/topics/install.txt2011-04-17 20:45:06 UTC (rev 
16034)
@@ -92,9 +92,7 @@
 In addition to a database backend, you'll need to make sure your Python
 database bindings are installed.
 
-* If 

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |Owner:  jkocherhans
  Honza_Kral |   Status:  assigned
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by kmtracey):

 I experimented with this a bit today, and was able to use the doc to
 implement my particular need without too much difficulty so that is good.

 One thing I thought was odd though was that my filter's `get_query_set` is
 called even if its `query_parameter_name` is not in request.GET, and as a
 result my `get_query_set` must be coded to handle that case properly
 (return the queryset unchanged). If it is not coded properly the result is
 that my filter limits the queryset used even when its "All" choice is the
 selected choice for it. I think it would be preferable to avoid calling
 the `get_query_set` for filters whose query parameters aren't in
 `request.GET`.

 There is no mention anywhere I could see of why `request` is passed into
 `get_choices` and `get_queryset`, nor is it used that I can see anywhere
 in the samples. For what kinds of filters might this be used?

 My particular use case is a slight modification of an existing admin
 filter: I want to filter by a related field, but I only want a subset of
 the existing values to appear in the choices. It was not hard to implement
 as a !ListFilter but after getting `get_query_set` wrong the first time it
 occurred to me it would be better if I could just override the
 `get_choices` method for the existing admin filter that already filtered
 the way I wanted. Unfortunately that existing admin filter isn't
 implemented as a !ListFilter so I can't do that, apparently I'd have to
 choose the scary-sounding alternate option of providing a tuple of field
 name and class inheriting from !FieldListFilter (which is noted as being
 internal and prone to refactoring). Is it not possible to unify things so
 that it is easy to both write completely new-and-different filters and
 ones that are minor tweaks to what admin already provides?

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

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

Re: [Django] #14186: Adding GDirections wrapper to overlays.py

[Django]

#14186: Adding GDirections wrapper to overlays.py
--+
   Reporter:  maraujop|Owner:  maraujop
   Type:  Uncategorized   |   Status:  new
  Milestone:  1.3 |Component:  GIS
Version:  SVN | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Design decision needed  |Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by maraujop):

 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 As GeoDjango is moving or has moved to the new Google API v3. This is
 probably unnecessary anymore, as GDirections doesn't exist anymore and
 directions handling is done completely different.

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

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

Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
-+-
   Reporter:  Hawkeye|Owner:  brunobraga
   Type:  New|   Status:  assigned
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Ready for  |Has patch:  1
  checkin|  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jacob):

 * stage:  Accepted => 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16033 - django/branches/releases/1.3.X/docs/internals

[noreply]

Author: jacob
Date: 2011-04-17 07:27:53 -0700 (Sun, 17 Apr 2011)
New Revision: 16033

Modified:
   django/branches/releases/1.3.X/docs/internals/contributing.txt
Log:
[1.3.X] Updated the contributing document to accurately reflect our security 
process.

Backport of [16032] from trunk.

Modified: django/branches/releases/1.3.X/docs/internals/contributing.txt
===
--- django/branches/releases/1.3.X/docs/internals/contributing.txt  
2011-04-17 14:13:19 UTC (rev 16032)
+++ django/branches/releases/1.3.X/docs/internals/contributing.txt  
2011-04-17 14:27:53 UTC (rev 16033)
@@ -104,19 +104,19 @@
   fix is forthcoming. We'll give a rough timeline and ask the reporter
   to keep the issue confidential until we announce it.
 
-* Halt all other development as long as is needed to develop a fix,
-  including patches against the current and two previous releases.
+* Focus on developing a fix as quickly as possible and produce patches
+  against the current and two previous releases.
 
 * Determine a go-public date for announcing the vulnerability and the fix.
   To try to mitigate a possible "arms race" between those applying the
   patch and those trying to exploit the hole, we will not announce
   security problems immediately.
 
-* Pre-notify everyone we know to be running the affected version(s) of
-  Django. We will send these notifications through private e-mail
-  which will include documentation of the vulnerability, links to the
-  relevant patch(es), and a request to keep the vulnerability
-  confidential until the official go-public date.
+* Pre-notify third-party distributors of Django ("vendors"). We will send
+  these vendor notifications through private email which will include
+  documentation of the vulnerability, links to the relevant patch(es), and 
a
+  request to keep the vulnerability confidential until the official
+  go-public date.
 
 * Publicly announce the vulnerability and the fix on the pre-determined
   go-public date. This will probably mean a new release of Django, but

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

[Changeset] r16032 - django/trunk/docs/internals

[noreply]

Author: jacob
Date: 2011-04-17 07:13:19 -0700 (Sun, 17 Apr 2011)
New Revision: 16032

Modified:
   django/trunk/docs/internals/contributing.txt
Log:
Updated the contributing document to accurately reflect our security process.

Modified: django/trunk/docs/internals/contributing.txt
===
--- django/trunk/docs/internals/contributing.txt2011-04-17 04:52:31 UTC 
(rev 16031)
+++ django/trunk/docs/internals/contributing.txt2011-04-17 14:13:19 UTC 
(rev 16032)
@@ -104,19 +104,19 @@
   fix is forthcoming. We'll give a rough timeline and ask the reporter
   to keep the issue confidential until we announce it.
 
-* Halt all other development as long as is needed to develop a fix,
-  including patches against the current and two previous releases.
+* Focus on developing a fix as quickly as possible and produce patches
+  against the current and two previous releases.
 
 * Determine a go-public date for announcing the vulnerability and the fix.
   To try to mitigate a possible "arms race" between those applying the
   patch and those trying to exploit the hole, we will not announce
   security problems immediately.
 
-* Pre-notify everyone we know to be running the affected version(s) of
-  Django. We will send these notifications through private email
-  which will include documentation of the vulnerability, links to the
-  relevant patch(es), and a request to keep the vulnerability
-  confidential until the official go-public date.
+* Pre-notify third-party distributors of Django ("vendors"). We will send
+  these vendor notifications through private email which will include
+  documentation of the vulnerability, links to the relevant patch(es), and 
a
+  request to keep the vulnerability confidential until the official
+  go-public date.
 
 * Publicly announce the vulnerability and the fix on the pre-determined
   go-public date. This will probably mean a new release of Django, but

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |Owner:  jkocherhans
  Honza_Kral |   Status:  assigned
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by guandalino):

 * cc: guandalino (added)


Comment:

 cc add

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

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

Re: [Django] #9076: Inline forms can result in a "Please correct the errors below." message with no errors listed.

[Django]

#9076: Inline forms can result in a "Please correct the errors below." message
with no errors listed.
+
   Reporter:  coady |Owner:  nobody
   Type:  Bug   |   Status:  reopened
  Milestone:|Component:  Forms
Version:  1.0   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by julien):

 * has_patch:  1 => 0
 * type:   => Bug
 * severity:   => Normal


Comment:

 Unchecking the "Has patch" flag since there effectively is no patch for
 the new issues reported after this ticket was "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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9084: File-based session does not store any data on Windows

[Django]

#9084: File-based session does not store any data on Windows
+
   Reporter:  mizutori  |Owner:
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.sessions
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+
Changes (by julien):

 * needs_better_patch:  0 => 1
 * type:   => Bug
 * severity:   => Normal


Comment:

 Patch needs improvement as per Malcolm's comments.

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

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

Re: [Django] #9089: urlencode should support MutliValueDict

[Django]

#9089: urlencode should support MutliValueDict
---+
   Reporter:  guettli  |Owner:  gptvnt
   Type:  New feature  |   Status:  assigned
  Milestone:   |Component:  Core (Other)
Version:  1.0  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+
Changes (by julien):

 * needs_better_patch:  0 => 1
 * type:   => New feature
 * severity:   => Normal


Comment:

 Patch needs improvement as per gptvnt's comment.

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

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

Re: [Django] #9245: Using choices in a mode field forces use of TypedChoiceField in a form field

[Django]

#9245: Using choices in a mode field forces use of TypedChoiceField in a form
field
+
   Reporter:  Tarken|Owner:  badri
   Type:  Bug   |   Status:  reopened
  Milestone:|Component:  Forms
Version:  1.0   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+
Changes (by julien):

 * needs_better_patch:  0 => 1
 * type:   => Bug
 * severity:   => Normal


Comment:

 The tests would need to be rewritten using unittests since this is now
 Django's preferred 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9345: Various string consistency fixes

[Django]

#9345: Various string consistency fixes
-+-
   Reporter:  Semmel |Owner:  nobody
   Type:  Uncategorized  |   Status:  closed
  Milestone: |Component:  Uncategorized
Version:  1.0| Severity:  Normal
 Resolution:  wontfix| Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * status:  new => closed
 * resolution:   => wontfix
 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 Wontfixing since "email" (without hyphen) is now the new preferred way as
 of r15967.

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

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

Re: [Django] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

[Django]

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
-+-
   Reporter:  ikelly |Owner:  mtredinnick
   Type: |   Status:  assigned
  Cleanup/optimization   |Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * type:   => Cleanup/optimization
 * severity:   => Normal


Comment:

 The tests would need to be rewritten using unittests since this is now
 Django's preferred 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9403: _set_content needs to perform the same _is_string check as the Constructor

[Django]

#9403: _set_content needs to perform the same _is_string check as the 
Constructor
-+-
   Reporter:  magneto|Owner:  nobody
   Type:  Uncategorized  |   Status:  new
  Milestone: |Component:  HTTP handling
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  1
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * type:   => Uncategorized
 * severity:   => Normal
 * needs_tests:  0 => 1


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

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

Re: [Django] #9588: provide **kwargs argument to GenericInlineModelAdmin.get_formset

[Django]

#9588: provide **kwargs argument to GenericInlineModelAdmin.get_formset
-+-
   Reporter:  lakin@…|Owner:  brosner
   Type:  New|   Status:  assigned
  feature|Component:  contrib.contenttypes
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * type:   => New feature
 * severity:   => Normal
 * needs_tests:  0 => 1


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

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

Re: [Django] #9583: FormWizard hash field name should be customisable.

[Django]

#9583: FormWizard hash field name should be customisable.
---+---
   Reporter:  Ratty|Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  Forms
Version:  1.0  | Severity:  Normal
 Resolution:   | Keywords:  FormWizard hash
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  1|  Needs tests:  1
Patch needs improvement:  0|
---+---
Changes (by julien):

 * needs_docs:  0 => 1
 * type:   => New feature
 * severity:   => Normal
 * needs_tests:  0 => 1


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

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

Re: [Django] #10146: Support for contrib/markdown extension_configs in settings.py

[Django]

#10146: Support for contrib/markdown extension_configs in settings.py
-+-
   Reporter:  bdejong|Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  contrib.markup
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  markdown config
 Resolution: |  extensions extension_configs
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  1
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * needs_tests:  0 => 1


Comment:

 Could someone write tests for this? Also, all changes would need to be
 combined in one single diff 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
-+-
   Reporter:  bhagany|Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  HTTP handling
  Milestone: | Severity:  Normal
Version:  1.0| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * needs_tests:  0 => 1


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

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

Re: [Django] #10609: Permissions on admin actions

[Django]

#10609: Permissions on admin actions
---+-
   Reporter:  leitjohn |Owner:  leitjohn
   Type:  New feature  |   Status:  assigned
  Milestone:   |Component:  contrib.admin
Version:  1.1-beta-1   | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  1|  Needs tests:  1
Patch needs improvement:  0|
---+-
Changes (by julien):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1


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

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

Re: [Django] #10743: Support lookup separators in ModelAdmin.list_display

[Django]

#10743: Support lookup separators in ModelAdmin.list_display
-+-
   Reporter:  mrts   |Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  contrib.admin
  Milestone:  1.4| Severity:  Normal
Version:  SVN| Keywords:  efficient-admin,
 Resolution: |  list_display
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1


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

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

Re: [Django] #10810: FormWizard validates the last form twice

[Django]

#10810: FormWizard validates the last form twice
+-
   Reporter:  Qrilka|Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.formtools
Version:  SVN   | Severity:  Normal
 Resolution:| Keywords:  wizard validation
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+-
Changes (by julien):

 * needs_better_patch:  0 => 1


Comment:

 I don't think we should just close this ticket. If no easy way-around can
 be found then at least a note should be added to the doc.

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

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

Re: [Django] #10827: django.auth create_permissions must clear the content type cache before creating permissions

[Django]

#10827: django.auth create_permissions must clear the content type cache before
creating permissions
+
   Reporter:  seanl |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.auth
Version:  SVN   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  0 |
+
Changes (by julien):

 * needs_tests:  0 => 1


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

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

Re: [Django] #13559: Need a contextprocessor for current site

[Django]

#13559: Need a contextprocessor for current site
---+-
   Reporter:  tonnzor  |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:  1.3  |Component:  contrib.sites
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+-

Comment (by julien):

 See also #10944 which suggests adding a template tag and a method to the
 Site class for this.

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

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

Re: [Django] #10944: Site app should be able to make absolute URLs.

[Django]

#10944: Site app should be able to make absolute URLs.
---+-
   Reporter:  jdunck   |Owner:  laurentluce
   Type:  New feature  |   Status:  assigned
  Milestone:   |Component:  contrib.sites
Version:  1.0  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+-
Changes (by julien):

 * type:   => New feature
 * severity:   => Normal


Comment:

 See also #13559 which suggests adding a context processor for this.

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

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

Re: [Django] #15842: Silent Failure of InlineAdmin Class With a DateTimeField on the Model if Only a "time with timezone" Column in the Database

[Django]

#15842: Silent Failure of InlineAdmin Class With a DateTimeField on the Model if
Only a "time with timezone" Column in the Database
-+-
   Reporter: |Owner:  nobody
  vincitveritas  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by vincitveritas):

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

[Django] #15842: Silent Failure of InlineAdmin Class With a DateTimeField on the Model if Only a "time with timezone" Column in the Database

[Django]

#15842: Silent Failure of InlineAdmin Class With a DateTimeField on the Model if
Only a "time with timezone" Column in the Database
---+-
 Reporter:  vincitveritas  | Owner:  nobody
 Type:  Bug|Status:  new
Milestone: | Component:  Database layer (models, ORM)
  Version:  1.2|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+-
 Ok, this is definitely an edge case, but I ran into this when trying to
 update a model to add another DateTimeField in one of my projects with an
 existing database in place. I tried to manually create the db column
 (postgres), but inadvertently did a "time with timezone" column type
 instead of "timestamp with timezone". I then went to test the code change
 on the site's admin. Everything seemed fine, until I actually entered a
 date and time for the field. The next time I loaded up the admin change
 page, the inline for that particular inlinemodeladmin just wasn't there.
 So, I went into the shell and deleted the value from the field and saved.
 Then, I reloaded the admin change page. Et voila, the inline returned.
 After much head scratching, I realized what I had done and dropped the
 incorrectly typed column from the db table and re-created it with the
 correct type. I was then able to set the value and the inline showed up as
 expected.

 What concerns me is that no error was raised by the mismatch between the
 DateTimeField declaration in the model definition and the incorrectly-
 typed db column, only the disappearing inlinemodeladmin. Something just
 doesn't seem right there.

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

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

[Django] #15841: User conflict with CommentDetailsForm

[Django]

#15841: User conflict with CommentDetailsForm
-+-
 Reporter:  admin@…  | Owner:  nobody
 Type:  Bug  |Status:  new
Milestone:   | Component:  contrib.comments
  Version:  1.3  |  Severity:  Normal
 Keywords:   |  Triage Stage:  Unreviewed
Has patch:  0|
-+-
 User.email defined as "blank = True", but CommentDetailsForm.email is
 required. This results violation of form validation when authorized user
 without email posts comment.

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

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

Re: [Django] #15793: Filebased email backend should save emails using the ".eml" standard extension

[Django]

#15793: Filebased email backend should save emails using the ".eml" standard
extension
-+-
   Reporter:  Kronuz |Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  Core (Mail)
  Milestone: | Severity:  Normal
Version: | Keywords:
 Resolution: |Has patch:  1
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 Ubuntu with default settings opens .eml files in Evolution too.

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

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

Re: [Django] #15793: Filebased email backend should save emails using the ".eml" standard extension

[Django]

#15793: Filebased email backend should save emails using the ".eml" standard
extension
-+-
   Reporter:  Kronuz |Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  Core (Mail)
  Milestone: | Severity:  Normal
Version: | Keywords:
 Resolution: |Has patch:  1
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 Ubuntu with default settings opens .eml files in Evolution too.

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

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