Re: [Django] #19: Automatically generate JavaScript form validation

[Django]

#19: Automatically generate JavaScript form validation
-+-
 Reporter:  adrian   |Owner:  adrian
 Type:  enhancement  |   Status:  closed
Component:  Validators   |  Version:  new-admin
 Severity:  minor|   Resolution:  wontfix
 Keywords:  validators   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * easy:   => 0


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

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

Re: [Django] #19485: can't run default project in python3

[Django]

#19485: can't run default project in python3
-+
 Reporter:  aliva|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by charettes):

 I reproduced on master.

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

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

Re: [Django] #19485: can't run default project in python3

[Django]

#19485: can't run default project in python3
-+
 Reporter:  aliva|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by anonymous):

 aliva, Python 3.0 it is not compatible with Django 1.4 yet.

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

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

Re: [Django] #19485: can't run default project in python3

[Django]

#19485: can't run default project in python3
-+
 Reporter:  aliva|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by charettes):

 * severity:  Normal => Release blocker


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

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

Re: [Django] #19485: can't run default project in python3

[Django]

#19485: can't run default project in python3
--+
 Reporter:  aliva |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Python 3  |  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):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 The full traceback:
 {{{
 Traceback (most recent call last):
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/core/management/base.py", line 222, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/core/management/base.py", line 252, in execute
 output = self.handle(*args, **options)
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/core/management/commands/runserver.py", line 70, in handle
 self.run(*args, **options)
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/core/management/commands/runserver.py", line 79, in run
 autoreload.main(self.inner_run, args, options)
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/utils/autoreload.py", line 174, in main
 reloader(wrapped_main_func, args, kwargs)
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/utils/autoreload.py", line 141, in python_reloader
 reloader_thread()
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/utils/autoreload.py", line 122, in reloader_thread
 if code_changed():
   File "/home/simon/.virtualenvs/34057b31-241e-
 4e1d-b023-400bd276f426/lib/python3.2/site-
 packages/django/utils/autoreload.py", line 60, in code_changed
 for filename in filter(None, filenames) + _error_files:
 TypeError: unsupported operand type(s) for +: 'filter' and 'list'
 }}}

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

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

Re: [Django] #19482: django.contrib.localflavor in INSTALLED_APPS raises DeprecationWarning

[Django]

#19482: django.contrib.localflavor in INSTALLED_APPS raises DeprecationWarning
-+-
 Reporter:  andreas_pelme|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:
 Severity:  Normal   |  1.5-beta-1
 Keywords:  localflavor  |   Resolution:
Has patch:  0| Triage Stage:  Design
  Needs tests:  0|  decision needed
Easy pickings:  1|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by charettes):

 * cc: charette.s@… (added)
 * needs_better_patch:   => 0
 * component:  Uncategorized => Documentation
 * needs_tests:   => 0
 * version:  master => 1.5-beta-1
 * keywords:   => localflavor
 * needs_docs:   => 0
 * stage:  Unreviewed => Design decision needed


Comment:

 The [https://docs.djangoproject.com/en/dev/ref/contrib/localflavor
 /#internationalization-of-localflavor documentation] should be updated to
 point out you don't have to have to include `django.contrib.localflavor`
 in `INSTALLED_APPS`.

 However I noticed that some [https://github.com/django/django-localflavor-
 ca localflavor apps] are still missing a locale folder which might result
 in no translations at all.

 Was there a plan to extract catalogs from
 `django/contrib/localflavor/locale/` to their specific ''localflavor''
 app? We could easily do this using the embedded
 
[https://github.com/django/django/blob/master/django/contrib/localflavor/locale/fr/LC_MESSAGES/django.po#L2352
 location string]. I volunteer to generate patches for this given it's
 accepted.

 Should we mark this as '''Release blocker'''? It's kind of a regresssion
 since you either get a warning you can't get rid off or install a
 standalone app that has potentially no translations.

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

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

Re: [Django] #6195: Allow caching of the javascript translation library by the client browser

[Django]

#6195: Allow caching of the javascript translation library by the client browser
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  i18 javascript   |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * cc: charette.s@… (added)


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

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

Re: [Django] #19401: 'swapped' checking does not account for case insensitivity

[Django]

#19401: 'swapped' checking does not account for case insensitivity
-+-
 Reporter:  chris@…  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 As suggested on github we could just use a `cached_property` instead.

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

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

Re: [Django] #14891: use_for_related_fields=False is not honored by reverse FK or M2M related managers

[Django]

#14891: use_for_related_fields=False is not honored by reverse FK or M2M related
managers
-+-
 Reporter:  sdksho@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  Manager  |  decision needed
  ManyToManyField|  Needs documentation:  0
  use_for_related_fields |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by charettes):

 * cc: charette.s@… (added)


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

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

Re: [Django] #18651: Assignment tags should allow optional assignments

[Django]

#18651: Assignment tags should allow optional assignments
-+--
 Reporter:  mitar|Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by tim_heap):

 After discussing with people in #django-dev, the following was proposed:

 * Merge these changes in to `simple_tag`.
 * Start `assignment_tag` on the deprecation path.

 For example:

 {{{
 @register.simple_tag()
 def plain_output():
 """
 Use as `{% plain_output %}`. Prints 'bar'
 """
 return 'bar'


 @register.simple_tag(assignable=True)
 def optional_assignment():
 """
 Use as either:

 * `{% optional_assignment %}` - prints 'bar'
 * `{% optional_assignment as foo %}` - assigns 'bar' to 'foo'
 """
 return 'bar'


 @register.simple_tag(assignable=True, default_name='foo')
 def default_assignment():
 """
 Use as either:

 * `{% default_assignment %}` - assigns 'bar' to 'foo'
 * `{% default_assignment as foo %}` - assigns 'bar' to 'foo'
 """
 return 'bar'
 }}}

 This has the down side of being unable to force assignment, as you
 currently can with `assignment_tag`. I do not see this being a problem
 though, as I can not think of a reasonable example where outputting a
 variable is so harmful that the possibility of it happening should be
 guarded against explicitly in the tag. If you really need this case, write
 a completely custom tag.

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

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

[Django] #19485: can't run default project in python3

[Django]

#19485: can't run default project in python3
+
 Reporter:  aliva   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Python 3|Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I have updated to master. now I can't run the default project :)

 This is What I do

 {{{#!bash
 python3 django-admin.py startproject djtest
 cd djtest
 python3 manage.py runserver

 TypeError: unsupported operand type(s) for +: 'filter' and 'list'
 Validating models...

 Unhandled exception in thread started by 
 }}}

 python2 works fine.

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

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

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Alex):

 Yes, this is clearly going to be non-trivial under any circumstances, for
 example `field__in` can no longer generate a SQL `IN` clause, it needs to
 be a chain of `OR`s.

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

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

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I am somewhat interested in the idea of doing the "ON ..." clause
 generation in the field. This would allow for a lot of freedom in what the
 join clause would be and would be fairly straightforward to implement. As
 of commit of #10790 the get_extra_join_sql() already allows adding custom
 stuff to the join clause, but not altering it totally.

 It seems that for generic foreign keys we will need the ability to
 generate fully custom ON clauses for multicolumn foreign key support (see
 #373, comment 111). And, this SQL will need to be backend specific.

 For now I see two basic approaches:
   - Just change the lhscol, rhscol in query datastructures to lists, that
 is lhscols, rhscols. Deal with the generic foreign key in some other way
 (basically, add a hack for it).
   - Generate the SQL in the field (get_join_clause() or somesuch). This
 might need to just postpone the clause creation to the used connection.
 This way generic foreign keys wouldn't be a special case for the compiler,
 and it would be possible to implement exotic join clauses in custom fields
 (time range join restrictions for example).

 I guess we can't implement the ForeignKey(to_field=a list of fields) just
 yet, there are some complications along that path - mainly how do we
 represent the ForeignKey in the model._meta as it doesn't have just a
 single backing field. I guess #373 will need to answer that part.

 Good ideas welcome. Testing different things will likely be a good
 solution here.

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

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

Re: [Django] #19441: No Postgres _like index when unique=True

[Django]

#19441: No Postgres _like index when unique=True
-+-
 Reporter:  dyve |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  postgresql   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Accepted => Ready for checkin


Comment:

 It seems that getting the LIKE index when db_index = True for unique field
 is correct.

 I tested the patch on top of 1.5 for the indexes tests. This looks ready
 for commit to me.

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

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

Re: [Django] #19197: BaseDatabaseOperations: convert_values raise error on None data type conversions

[Django]

#19197: BaseDatabaseOperations: convert_values raise error on None data type
conversions
-+-
 Reporter:  maxi |Owner:
 Type:  Bug  |  maxirobaina@…
Component:  Database layer   |   Status:  closed
  (models, ORM)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"1caa483914edf851137b3c1e39f4364772bd46c9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1caa483914edf851137b3c1e39f4364772bd46c9"
 [1.5.x] Fixed #19197 -- fixed convert_values() for nullable numeric fields

 Cleaned up the implementation of base convert_values() a little, and
 made sure it accepts None as a value for numeric fields.

 There are no tests attached. The reason is that not all of the
 convert_values() accept None as a value for numeric fields (for example
 sqlite3.convert_values()).

 The reason the base convert_values() needs to accept None is that this
 situation might arise in custom compilers for 3rd party backends. It
 is easy to keep the convert_values() working, so lets do that.

 Backpatch of 12a96bfa263d514884ef11009913b2f8bb163472
 }}}

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

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

[django/django] 1caa48: [1.5.x] Fixed #19197 -- fixed convert_values() for...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 1caa483914edf851137b3c1e39f4364772bd46c9
  
https://github.com/django/django/commit/1caa483914edf851137b3c1e39f4364772bd46c9
  Author: Anssi Kääriäinen 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/db/backends/__init__.py

  Log Message:
  ---
  [1.5.x] Fixed #19197 -- fixed convert_values() for nullable numeric fields

Cleaned up the implementation of base convert_values() a little, and
made sure it accepts None as a value for numeric fields.

There are no tests attached. The reason is that not all of the
convert_values() accept None as a value for numeric fields (for example
sqlite3.convert_values()).

The reason the base convert_values() needs to accept None is that this
situation might arise in custom compilers for 3rd party backends. It
is easy to keep the convert_values() working, so lets do that.

Backpatch of 12a96bfa263d514884ef11009913b2f8bb163472



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

[django/django] 12a96b: Fixed #19197 -- fixed convert_values() for nullabl...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 12a96bfa263d514884ef11009913b2f8bb163472
  
https://github.com/django/django/commit/12a96bfa263d514884ef11009913b2f8bb163472
  Author: Anssi Kääriäinen 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/db/backends/__init__.py

  Log Message:
  ---
  Fixed #19197 -- fixed convert_values() for nullable numeric fields

Cleaned up the implementation of base convert_values() a little, and
made sure it accepts None as a value for numeric fields.

There are no tests attached. The reason is that not all of the
convert_values() accept None as a value for numeric fields (for example
sqlite3.convert_values()).

The reason the base convert_values() needs to accept None is that this
situation might arise in custom compilers for 3rd party backends. It
is easy to keep the convert_values() working, so lets do that.


  Commit: 85712a53552a6457c9362b4bf037b1ba6a2e45e1
  
https://github.com/django/django/commit/85712a53552a6457c9362b4bf037b1ba6a2e45e1
  Author: Anssi Kääriäinen 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  Made sure connections are actually closed in backends tests


Compare: https://github.com/django/django/compare/72a6ac568d28...85712a53552a

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

Re: [Django] #19484: Hostgator

[Django]

#19484: Hostgator
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 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:

 See TicketClosingReasons/UseSupportChannels

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

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

Re: [Django] #19197: BaseDatabaseOperations: convert_values raise error on None data type conversions

[Django]

#19197: BaseDatabaseOperations: convert_values raise error on None data type
conversions
-+-
 Reporter:  maxi |Owner:
 Type:  Bug  |  maxirobaina@…
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.4
 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 akaariai):

 Patch available at https://github.com/akaariai/django/compare/ticket_19197

 There is a fix for completely unrelated issue in one commit - backends
 tests seem to leak connections if ran alone on postgresql. This ticket's
 issue is fixed without tests, the base convert_values() has been doing a
 different thing than for example sqlite3's convert_values(), so writing a
 test for just base convert_values() seemed wrong.

 In general the situation with convert_values() and Field.to_python is
 somewhat messy. It would be nice to clean that up but not this ticket's
 problem...

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

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

[Django] #19484: Hostgator

[Django]

#19484: Hostgator
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Is it possible to have a running django app on hostgator shared hosting?
 I've been searching the web, but I have yet to find a decent solution.

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

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

Re: [Django] #7281: Add doctype tag to webdesign template tags

[Django]

#7281: Add doctype tag to webdesign template tags
-+-
 Reporter:  Rob Hudson   |Owner:  nobody
 |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  contrib.webdesign|   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  webdesign|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 I got a second vote for "wontfix" on IRC.

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

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

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

[Django]

#13559: Need a contextprocessor for current site
---+--
 Reporter:  tonnzor|Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 #17005 is about adding a middleware for the same purpose in views.

 With that middleware and the request context processor, the current site
 will be available in {{ request.site }}, but that doesn't rule out a
 specific context processor in case you don't want the site middleware or
 the request context processor.

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

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

Re: [Django] #17005: Adding django.contrib.site.middleware ?

[Django]

#17005: Adding django.contrib.site.middleware ?
---+--
 Reporter:  jordan@…   |Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 #13559 is about adding a context processor for the same purpose in
 templates.

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

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

Re: [Django] #7281: Add doctype tag to webdesign template tags

[Django]

#7281: Add doctype tag to webdesign template tags
-+-
 Reporter:  Rob Hudson   |Owner:  nobody
 |   Status:  new
 Type:  New feature  |  Version:  master
Component:  contrib.webdesign|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  webdesign|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 This ticket was opened 5 years ago. Since then HTML5 has won the
 HTML/XHTML race and it solves the doctype problem by simplifying it
 drastically: ``.

 In my opinion the `{% doctype %}` tag would add very little value
 nowadays:
 - existing projects already have doctypes hardcoded in their templates and
 don't need it;
 - new projects should use HTML5 in general — it's an established best
 practice since 2010 (roughly).

 I'm leaning towards "wontfix". I'm sorry, because you've obviously put
 some effort into the patch (it looks good). When you're working on such an
 old ticket, it's often a good idea to make sure the decision still stands,
 especially if it depends on the current state of the ecosystem — that
 states changes over the course of years.

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

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

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Alex):

 I think Anssii, is correct that the right solution is to support "virtual
 fields" (and with the multi column primary keys), and have that work with
 foreign keys. However, there could be an argument made that ForeignKey
 needs some support of its own, specifically with the `to_field` otpion,
 which lets you point a foreign key at something besides a primary key,
 it's not unreasonable to say that `to_field` should accept a list of
 fields. I suspect however that doing this correctly would still require
 most of the work of #373, so it should happen afterwards.

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

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

Re: [Django] #19279: Order of database setup and Django install unclear

[Django]

#19279: Order of database setup and Django install unclear
--+
 Reporter:  colinnkeenan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"528483cae22fa89f46a48a7d20d50f2880fb3bf7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="528483cae22fa89f46a48a7d20d50f2880fb3bf7"
 [1.5.X] Fixed #19279 - Clarified order of database setup and Django
 install.

 Thanks colinnkeenan for the suggestion.

 Backport of 72a6ac568d from master
 }}}

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

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

[django/django] 528483: [1.5.X] Fixed #19279 - Clarified order of database...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 528483cae22fa89f46a48a7d20d50f2880fb3bf7
  
https://github.com/django/django/commit/528483cae22fa89f46a48a7d20d50f2880fb3bf7
  Author: Tim Graham 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M docs/topics/install.txt

  Log Message:
  ---
  [1.5.X] Fixed #19279 - Clarified order of database setup and Django install.

Thanks colinnkeenan for the suggestion.

Backport of 72a6ac568d from master



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

Re: [Django] #19279: Order of database setup and Django install unclear

[Django]

#19279: Order of database setup and Django install unclear
--+
 Reporter:  colinnkeenan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"72a6ac568d28afdfa5be6bcb01526adb03eedfae"]:
 {{{
 #!CommitTicketReference repository=""
 revision="72a6ac568d28afdfa5be6bcb01526adb03eedfae"
 Fixed #19279 - Clarified order of database setup and Django install.

 Thanks colinnkeenan for the suggestion.
 }}}

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

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

[django/django] 72a6ac: Fixed #19279 - Clarified order of database setup a...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 72a6ac568d28afdfa5be6bcb01526adb03eedfae
  
https://github.com/django/django/commit/72a6ac568d28afdfa5be6bcb01526adb03eedfae
  Author: Tim Graham 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M docs/topics/install.txt

  Log Message:
  ---
  Fixed #19279 - Clarified order of database setup and Django install.

Thanks colinnkeenan for the suggestion.



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

Re: [Django] #19279: Order of database setup and Django install unclear

[Django]

#19279: Order of database setup and Django install unclear
--+
 Reporter:  colinnkeenan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by colinkeenan):

 You've inserted a phrase about first installing Django and creating a
 project near the beginning of the paragraph and a sentence about settings
 at the end of the paragraph.
 Looks good to me: I don't think I would've been confused if I had read the
 proposed patch when first installing Django.
 Thanks.

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

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

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

[Django]

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

Comment (by timo):

 @akaariai, is the example with the text "p2 doesn't have an associated
 restaurant" what you're looking for?

 https://docs.djangoproject.com/en/dev/topics/db/examples/one_to_one/

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

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

Re: [Django] #19279: Order of database setup and Django install unclear (was: docs.djangoproject.com/en/dev/topics/install/ "you'll need to ensure that Django has permission to create and alter tables

[Django]

#19279: Order of database setup and Django install unclear
--+
 Reporter:  colinnkeenan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timo):

 * cc: timograham@… (added)
 * has_patch:  0 => 1
 * version:  1.4 => master
 * type:  Bug => Cleanup/optimization


Comment:

 How does the attached patch look?

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

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

Re: [Django] #15516: Update the ticket life cycle diagram

[Django]

#15516: Update the ticket life cycle diagram
-+-
 Reporter:  ramiro   |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   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 aaugustin):

 * owner:  tswicegood => aaugustin


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

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

Re: [Django] #19483: ImportError is misinterpreted (in contrib.comments)

[Django]

#19483: ImportError is misinterpreted (in contrib.comments)
-+-
 Reporter:  Valentin Lorentz |Owner:  nobody
   |   Status:  closed
 Type:   |  Version:  1.4
  Cleanup/optimization   |   Resolution:  fixed
Component:  contrib.comments | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Claude Paroz ):

 In [changeset:"0bbc7c2b4921919ae989c6335be3b25676c6c40f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0bbc7c2b4921919ae989c6335be3b25676c6c40f"
 [1.5.x] Fixed #19483 -- Improved import error message in contrib.comments

 Thanks Valentin Lorentz for the report and the suggested fix.
 Backport of ed711c4bd from master.
 }}}

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

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

[django/django] 0bbc7c: [1.5.x] Fixed #19483 -- Improved import error mess...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 0bbc7c2b4921919ae989c6335be3b25676c6c40f
  
https://github.com/django/django/commit/0bbc7c2b4921919ae989c6335be3b25676c6c40f
  Author: Claude Paroz 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/contrib/comments/__init__.py
M tests/regressiontests/comment_tests/tests/app_api_tests.py

  Log Message:
  ---
  [1.5.x] Fixed #19483 -- Improved import error message in contrib.comments

Thanks Valentin Lorentz for the report and the suggested fix.
Backport of ed711c4bd from master.



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

Re: [Django] #19483: ImportError is misinterpreted (in contrib.comments)

[Django]

#19483: ImportError is misinterpreted (in contrib.comments)
-+-
 Reporter:  Valentin Lorentz |Owner:  nobody
   |   Status:  closed
 Type:   |  Version:  1.4
  Cleanup/optimization   |   Resolution:  fixed
Component:  contrib.comments | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"ed711c4bd5fd3b6321cae00bbad0876295c5c537"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ed711c4bd5fd3b6321cae00bbad0876295c5c537"
 Fixed #19483 -- Improved import error message in contrib.comments

 Thanks Valentin Lorentz for the report and the suggested fix.
 }}}

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

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

[django/django] ed711c: Fixed #19483 -- Improved import error message in c...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ed711c4bd5fd3b6321cae00bbad0876295c5c537
  
https://github.com/django/django/commit/ed711c4bd5fd3b6321cae00bbad0876295c5c537
  Author: Claude Paroz 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/contrib/comments/__init__.py
M tests/regressiontests/comment_tests/tests/app_api_tests.py

  Log Message:
  ---
  Fixed #19483 -- Improved import error message in contrib.comments

Thanks Valentin Lorentz for the report and the suggested fix.



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

Re: [Django] #15516: Update the ticket life cycle diagram

[Django]

#15516: Update the ticket life cycle diagram
-+-
 Reporter:  ramiro   |Owner:
 Type:   |  tswicegood
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  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
-+-

Comment (by aaugustin):

 The latest version of OmniGraffle Pro allows exporting to SVG. I just used
 that successfully for two other images. A PDF version must also be
 included, because Sphinx' PDF builder doesn't handle SVG.

 Travis, could you upload the .graffle file?

 I'll review it, tweak it again :), make the SVG + PDF export, and commit
 the result.

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

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

[django/django] dbdd25: Replaced the test case hierarchy schema with a vec...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: dbdd2538607e06f5f59c6f3c16737acb6bc68918
  
https://github.com/django/django/commit/dbdd2538607e06f5f59c6f3c16737acb6bc68918
  Author: Aymeric Augustin 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
A docs/topics/_images/django_unittest_classes_hierarchy.graffle
A docs/topics/_images/django_unittest_classes_hierarchy.pdf
R docs/topics/_images/django_unittest_classes_hierarchy.png
A docs/topics/_images/django_unittest_classes_hierarchy.svg
M docs/topics/http/middleware.txt
M docs/topics/testing.txt

  Log Message:
  ---
  Replaced the test case hierarchy schema with a vector version.

The OmniGraffle source file is included for future use.



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

Re: [Django] #19463: Add UUID Field to core

[Django]

#19463: Add UUID Field to core
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Accepted


Comment:

 Quoting Jacob from the recent [https://groups.google.com/group/django-
 developers/browse_thread/thread/e9a16f0e6fa319e django-developers
 discussion]: "If someone can come up with a good patch I'd be fine
 considering it for core.".

 So, marking as accepted based on that.

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

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

Re: [Django] #19149: Generic Relation not cascading with Multi table inheritance.

[Django]

#19149: Generic Relation not cascading with Multi table inheritance.
-+-
 Reporter:  thomaspurchas|Owner:  nicolas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  multitable,  |  Needs documentation:  0
  inheritance, genericforeignkey |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 The patch isn't correct - doing if not objs: return [] doesn't return a
 queryset.

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

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

Re: [Django] #16679: Speed up signals by caching the reveicers per sender

[Django]

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"704ee33f503c96b96c2682b946a11b3b42318ba7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="704ee33f503c96b96c2682b946a11b3b42318ba7"
 Fixed #16679 -- Use caching to speed up signal sending
 }}}

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

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

[django/django] 704ee3: Fixed #16679 -- Use caching to speed up signal sen...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 704ee33f503c96b96c2682b946a11b3b42318ba7
  
https://github.com/django/django/commit/704ee33f503c96b96c2682b946a11b3b42318ba7
  Author: Anssi Kääriäinen 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/db/models/signals.py
M django/dispatch/dispatcher.py

  Log Message:
  ---
  Fixed #16679 -- Use caching to speed up signal sending



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

Re: [Django] #19483: ImportError is misinterpreted (in contrib.comments)

[Django]

#19483: ImportError is misinterpreted (in contrib.comments)
-+-
 Reporter:  Valentin Lorentz |Owner:  nobody
   |   Status:  new
 Type:   |  Version:  1.4
  Cleanup/optimization   |   Resolution:
Component:  contrib.comments | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => contrib.comments
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19160: Make ungettext_lazy really usable

[Django]

#19160: Make ungettext_lazy really usable
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 Reviewing the discussion and the patches above, I think Claude nailed the
 API in 19160-1.diff and Julien the implementation in 19160.smart-
 ngettext-lazy.diff.

 I suggest to adapt Julien's patch to Claude's API.

 For anonymous parameters, I recommend to support only a single integer
 parameter. If no `number` argument is passed to `ngettext_lazy`, and later
 on the result is interpolated with a single integer value, that value
 should be used as the "count".

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

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

Re: [Django] #9334: The docs don't explain how django names cache keys

[Django]

#9334: The docs don't explain how django names cache keys
---+
 Reporter:  simon@…|Owner:
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.0
 Severity:  Normal |   Resolution:
 Keywords:  dceu2011   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timo):

 It looks to me like #19320 is a suggestion (with a patch) for public cache
 API as discussed above. Perhaps we should close this ticket as a duplicate
 of that one?

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

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

Re: [Django] #18718: django.utils.encoding.filepath_to_uri is undocumented

[Django]

#18718: django.utils.encoding.filepath_to_uri is undocumented
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 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
--+

Comment (by Tim Graham ):

 In [changeset:"53b40d75b787b1f76e08aa078de88bae6473a3fc"]:
 {{{
 #!CommitTicketReference repository=""
 revision="53b40d75b787b1f76e08aa078de88bae6473a3fc"
 [1.5.X] Fixed #18718 - Documented django.utils.encoding.filepath_to_uri

 Backport of 507c081484 from master
 }}}

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

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

[django/django] 53b40d: [1.5.X] Fixed #18718 - Documented django.utils.enc...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 53b40d75b787b1f76e08aa078de88bae6473a3fc
  
https://github.com/django/django/commit/53b40d75b787b1f76e08aa078de88bae6473a3fc
  Author: Tim Graham 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/utils/encoding.py
M docs/ref/utils.txt

  Log Message:
  ---
  [1.5.X] Fixed #18718 - Documented django.utils.encoding.filepath_to_uri

Backport of 507c081484 from master



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

Re: [Django] #18718: django.utils.encoding.filepath_to_uri is undocumented

[Django]

#18718: django.utils.encoding.filepath_to_uri is undocumented
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 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 Tim Graham ):

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


Comment:

 In [changeset:"507c0814847fe3637d23625cc6f26bf2cfa5f66f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="507c0814847fe3637d23625cc6f26bf2cfa5f66f"
 Fixed #18718 - Documented django.utils.encoding.filepath_to_uri
 }}}

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

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

[django/django] 507c08: Fixed #18718 - Documented django.utils.encoding.fi...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 507c0814847fe3637d23625cc6f26bf2cfa5f66f
  
https://github.com/django/django/commit/507c0814847fe3637d23625cc6f26bf2cfa5f66f
  Author: Tim Graham 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/utils/encoding.py
M docs/ref/utils.txt

  Log Message:
  ---
  Fixed #18718 - Documented django.utils.encoding.filepath_to_uri



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

Re: [Django] #18629: Adding methods/attributes to date-based views

[Django]

#18629: Adding methods/attributes to date-based views
--+
 Reporter:  pydanny   |Owner:  donigian
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  cbv   | 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):

 Is there any work in progress on 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 https://groups.google.com/groups/opt_out.

Re: [Django] #18632: Cleanup on methods/attributes associated with editing views

[Django]

#18632: Cleanup on methods/attributes associated with editing views
--+
 Reporter:  pydanny   |Owner:  pydanny
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  Documentation |  Version:  1.4
 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):

 Danny, do you have any work in progress 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19267: PDF Table of Contents missing on readthedocs (was: 1.4.1 PDF Table of Contents links broken)

[Django]

#19267: PDF Table of Contents missing on readthedocs
-+-
 Reporter:  michael.amie@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  PDF, Documentation,  | Triage Stage:  Accepted
  Links  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timo):

 * ui_ux:  1 => 0
 * version:  1.4 =>


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

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

Re: [Django] #19483: ImportError is misinterpreted (in contrib.comments) (was: ImportError is misinterpreted)

[Django]

#19483: ImportError is misinterpreted (in contrib.comments)
-+-
 Reporter:  Valentin Lorentz |Owner:  nobody
   |   Status:  new
 Type:  Uncategorized|  Version:  1.4
Component:  Uncategorized|   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
-+-

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

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

Re: [Django] #19483: ImportError is misinterpreted

[Django]

#19483: ImportError is misinterpreted
-+-
 Reporter:  Valentin Lorentz |Owner:  nobody
   |   Status:  new
 Type:  Uncategorized|  Version:  1.4
Component:  Uncategorized|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Valentin Lorentz ):

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


Comment:

 For instance:

 {{{
 try:
 package = import_module(comments_app)
 except ImportError as e:
 raise ImproperlyConfigured("The COMMENTS_APP setting refers to "\
"a non-existing package: %s" %
 e.args[0])
 }}}

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

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

[Django] #19483: ImportError is misinterpreted

[Django]

#19483: ImportError is misinterpreted
-+
 Reporter:  Valentin Lorentz   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Uncategorized|Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Hi,

 I kept having this error when running "./manage.py runserver" on a
 project:


 {{{
 progval@Andromede:~/workspace/lqdn/memopol2-0$ ./manage.py runserver
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/usr/lib/python2.7/dist-
 packages/django/core/management/__init__.py", line 443, in
 execute_from_command_line
 utility.execute()
   File "/usr/lib/python2.7/dist-
 packages/django/core/management/__init__.py", line 382, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/lib/python2.7/dist-packages/django/core/management/base.py",
 line 196, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/usr/lib/python2.7/dist-packages/django/core/management/base.py",
 line 217, in execute
 translation.activate('en-us')
   File "/usr/lib/python2.7/dist-
 packages/django/utils/translation/__init__.py", line 105, in activate
 return _trans.activate(language)
   File "/usr/lib/python2.7/dist-
 packages/django/utils/translation/trans_real.py", line 194, in activate
 _active.value = translation(language)
   File "/usr/lib/python2.7/dist-
 packages/django/utils/translation/trans_real.py", line 183, in translation
 default_translation = _fetch(settings.LANGUAGE_CODE)
   File "/usr/lib/python2.7/dist-
 packages/django/utils/translation/trans_real.py", line 160, in _fetch
 app = import_module(appname)
   File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line
 35, in import_module
 __import__(name)
   File "/usr/local/lib/python2.7/dist-packages/haystack/__init__.py", line
 154, in 
 handle_registrations()
   File "/usr/local/lib/python2.7/dist-packages/haystack/__init__.py", line
 151, in handle_registrations
 search_sites_conf =
 importlib.import_module(settings.HAYSTACK_SITECONF)
   File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line
 35, in import_module
 __import__(name)
   File
 "/home/progval/workspace/lqdn/memopol2-0/memopol/search/search_indexes.py",
 line 4, in 
 from memopol.meps.models import MEP
   File "/home/progval/workspace/lqdn/memopol2-0/memopol/meps/models.py",
 line 4, in 
 from django.contrib.comments.moderation import CommentModerator,
 moderator
   File "/usr/lib/python2.7/dist-
 packages/django/contrib/comments/moderation.py", line 356, in 
 moderator = Moderator()
   File "/usr/lib/python2.7/dist-
 packages/django/contrib/comments/moderation.py", line 281, in __init__
 self.connect()
   File "/usr/lib/python2.7/dist-
 packages/django/contrib/comments/moderation.py", line 289, in connect
 signals.comment_will_be_posted.connect(self.pre_save_moderation,
 sender=comments.get_model())
   File "/usr/lib/python2.7/dist-
 packages/django/contrib/comments/__init__.py", line 41, in get_model
 if get_comment_app_name() != DEFAULT_COMMENTS_APP and
 hasattr(get_comment_app(), "get_model"):
   File "/usr/lib/python2.7/dist-
 packages/django/contrib/comments/__init__.py", line 25, in get_comment_app
 raise ImproperlyConfigured("The COMMENTS_APP setting refers to "\
 django.core.exceptions.ImproperlyConfigured: The COMMENTS_APP setting
 refers to a non-existing package.
 }}}

 After loads of debugging, I editted django/contrib/comments/__init__.py: I
 replaced this:

 {{{
 try:
 package = import_module(comments_app)
 exce*pt ImportError:
 raise ImproperlyConfigured("The COMMENTS_APP setting refers to "\
"a non-existing package.")
 }}}

 by this:

 {{{
 package = import_module(comments_app)
 }}}


 And I got:

 {{{
 progval@Andromede:~/workspace/lqdn/memopol2-0$ ./manage.py runserver
 Error: No module named gunicorn
 }}}


 I have no idea how to solve this, but you could display the name of the
 module in the error message, it would help a lot.

 Regards,
 Valentin

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

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

[django/django] bf14ae: Added PDF version of SVG file for latexpdf builds.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: bf14aed3cc3cc1a7422873a4a8bc0e9ad1615c6f
  
https://github.com/django/django/commit/bf14aed3cc3cc1a7422873a4a8bc0e9ad1615c6f
  Author: Aymeric Augustin 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
A docs/topics/http/_images/middleware.pdf
M docs/topics/http/middleware.txt

  Log Message:
  ---
  Added PDF version of SVG file for latexpdf builds.

Thanks Tim Graham for reporting this issue and testing the fix.



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

Re: [Django] #19481: Django exercises for beginners

[Django]

#19481: Django exercises for beginners
---+--
 Reporter:  addnab@…   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 Thanks for taking the time to report your feelings about current
 tutorials. However, Django's documentation is already quite extensive in
 my opinion. Surely, there are always things to improve, and adding more
 beginners content might be a good thing. Nothing prevents anyone to create
 such resources outside of the official documentation. Then, if those
 resources are recognized valuable, they could be integrated in official
 documentation. I don't think that keeping such reports open without any
 real content attached brings much value for us currently.

 I'm closing it, not to say it wouldn't be worth creating more
 documentation, but because the ticketing system is not the ideal location
 to share this sort of wishes. Maybe sharing your thoughts on django-
 developers mailing list might be more fruitful.

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

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

Re: [Django] #4065: Ability to disable admin pagination

[Django]

#4065: Ability to disable admin pagination
-+-
 Reporter:  Marek Kubica |Owner:  nobody
|   Status:  new
 Type:  New feature  |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  nfa-changelist   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  aaugustin => nobody


Comment:

 Please don't assigned tickets to people without their consent. I'm not
 going to work on 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 https://groups.google.com/groups/opt_out.

Re: [Django] #4065: Ability to disable admin pagination

[Django]

#4065: Ability to disable admin pagination
-+-
 Reporter:  Marek Kubica |Owner:  aaugustin
|   Status:  new
 Type:  New feature  |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  nfa-changelist   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

 * owner:  adamv => aaugustin
 * status:  reopened => new


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

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

Re: [Django] #12978: Support in syndication framework for CSS stylesheet links

[Django]

#12978: Support in syndication framework for CSS stylesheet links
-+-
 Reporter:  intrepidweb  |Owner:  yuval_a
 Type:  New feature  |   Status:  reopened
Component:  contrib.syndication  |  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:  syndication css  | Triage Stage:  Accepted
  stylesheets|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Someday/Maybe => Accepted


Comment:

 Accepting based on comment 2.

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

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

Re: [Django] #13663: Foreign Key to table in another database fails

[Django]

#13663: Foreign Key to table in another database fails
-+-
 Reporter:  berto|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 I'm not sure we want to go down this rabbit hole. I think it's safer to
 insist that ForeignKey don't work across databases, and force users to do
 queries in different databases manually (NoSQL style).

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

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

Re: [Django] #14451: add related_name to contrib.auth.models.User for 'groups'

[Django]

#14451: add related_name to contrib.auth.models.User for 'groups'
-+-
 Reporter:  tvon |Owner:  anonymous
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Someday/Maybe => Design decision needed


Comment:

 This can be done with a deprecation path right now if we want to. During
 the transition, `Group.users_set` would be a property raising a
 deprecation warning and returning `members`.

 However I don't know if there's much value in forcing this change upon all
 users of Django.

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

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

Re: [Django] #16521: Provide keyboard shortcuts in admin

[Django]

#16521: Provide keyboard shortcuts in admin
---+
 Reporter:  coolRR |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.3
 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:  1
---+
Changes (by aaugustin):

 * stage:  Someday/Maybe => Accepted


Comment:

 Given the comments above I think this ticket can be "accepted". Like many
 accepted tickets, it needs a good patch now, and Selenium tests.

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

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

Re: [Django] #13161: Ticked 2514 and 5171, solution for using Django with other psycopg2 applications.

[Django]

#13161: Ticked 2514 and 5171, solution for using Django with other psycopg2
applications.
-+-
 Reporter:  spoksss  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  psycopg2, unicode|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ramiro):

 * needs_tests:  0 => 1


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

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

Re: [Django] #14930: `values_list()` fails on queryset ordered by extra column

[Django]

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  vicould
 Type:  Bug  |   Status:  assigned
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:  1|
-+-
Changes (by mkai):

 * cc: django@… (added)


Comment:

 Can the patch be merged? I just hit this problem, too, and the patch fixes
 it.

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

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

Re: [Django] #13161: Ticked 2514 and 5171, solution for using Django with other psycopg2 applications.

[Django]

#13161: Ticked 2514 and 5171, solution for using Django with other psycopg2
applications.
-+-
 Reporter:  spoksss  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  psycopg2, unicode|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Henrietta):

 * needs_tests:  1 => 0


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

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

[Django] #19482: django.contrib.localflavor in INSTALLED_APPS raises DeprecationWarning

[Django]

#19482: django.contrib.localflavor in INSTALLED_APPS raises DeprecationWarning
---+
 Reporter:  andreas_pelme  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The documentation states that "If you want localflavor's texts to be
 translated, like form fields error messages, you must include
 django.contrib.localflavor in the INSTALLED_APPS setting, ...".

 Adding django.contrib.localflavor to INSTALLED_APPS will make that module
 automatically imported, which will raise a deprecation warning.

 The deprecation warning located in django/contrib/localflavor/__init__.py
 should probably be moved to django/contrib/localflavor/XX/__init__.py.
 That would make the deprecation warning appear when there is some actual
 code that is imported.

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

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

Re: [Django] #16187: Refactor lookup system

[Django]

#16187: Refactor lookup system
-+-
 Reporter:  UloPe|Owner:  UloPe
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 #10790 just went in, rebased branch available from
 https://github.com/akaariai/django/compare/ticket_16187_new

 The commit history is ugly... but the basic status is that the above
 branch does implement custom lookups in barckwards compatible way. The
 next steps would be to convert the GIS ORM to use the custom lookups, and
 then to try to implement things like `datefield__year__2000=1`.

 After that the big question is how exactly to handle backwards
 compatibility. Otherwise I don't see currently any major problems for this
 feature.

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

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

Re: [Django] #17093: Refactor django.template to quarantine global state

[Django]

#17093: Refactor django.template to quarantine global state
-+-
 Reporter:  carljm   |Owner:
 Type:   |  chrismedrela
  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:  0|UI/UX:  0
-+-
Changes (by chrismedrela):

 * owner:  nobody => chrismedrela


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

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

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Just a mention about the future changes which might make sense:
   - Move the path generation code (the ugly stuff in names_to_path()) to
 fields. There is little reason the ORM code needs to know the internal
 implementation of the fields (how the field.rel.to... stuff). If this is
 done in fields instead this will allow for cleaner code in sql/query.py
 and also custom field subclasses can easily customize the behaviour of the
 join setup.
   - Move the names_to_path() call to beginning of add_filter(). This
 allows fixing some bugs related to F() expression handling and also allows
 the removal of MultiJoin exception.
   - Generate the join condition fully by the field. This would make the
 ORM agnostic about multiple columns in the join, and it would be possible
 to generate completely custom join clause for cases like what is discussed
 in #373 comment 111.
   - Some cleanup to the model._meta get_* methods. It could be possible to
 reduce the amount of different field types and the different get_foo
 methods related to these - if the field would tell what type of relation
 it is, then we need to just get a handle to the field and we are done. How
 much we want to actually change the ._meta is a good question - if
 anything is semi-public API then it is model._meta.

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

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

Re: [Django] #18816: Remove "trim" argument from add_filter()

[Django]

#18816: Remove "trim" argument from add_filter()
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"f811649710fb51e48217e9a78991735977decfd8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f811649710fb51e48217e9a78991735977decfd8"
 Fixed #18816 -- Removed "trim" argument from add_filter()

 The trim argument was used by split_exclude() only to trim the last
 join from the given lookup. It is cleaner to just trim the last part
 from the lookup in split_exclude() directly so that there is no need
 to burden add_filter() with the logic needed for only split_exclude().
 }}}

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

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

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"69597e5bcc89aadafd1b76abf7efab30ee0b8b1a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="69597e5bcc89aadafd1b76abf7efab30ee0b8b1a"
 Fixed #10790 -- Refactored sql.Query.setup_joins()

 This is a rather large refactoring. The "lookup traversal" code was
 splitted out from the setup_joins. There is now names_to_path() method
 which does the lookup traveling, the actual work of setup_joins() is
 calling names_to_path() and then adding the joins found into the query.

 As a side effect it was possible to remove the "process_extra"
 functionality used by genric relations. This never worked for left
 joins. Now the extra restriction is appended directly to the join
 condition instead of the where clause.

 To generate the extra condition we need to have the join field
 available in the compiler. This has the side-effect that we need more
 ugly code in Query.__getstate__ and __setstate__ as Field objects
 aren't pickleable.

 The join trimming code got a big change - now we trim all direct joins
 and never trim reverse joins. This also fixes the problem in #10790
 which was join trimming in null filter cases.
 }}}

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

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

[django/django] f81164: Fixed #18816 -- Removed "trim" argument from add_f...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f811649710fb51e48217e9a78991735977decfd8
  
https://github.com/django/django/commit/f811649710fb51e48217e9a78991735977decfd8
  Author: Anssi Kääriäinen 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/db/models/sql/query.py

  Log Message:
  ---
  Fixed #18816 -- Removed "trim" argument from add_filter()

The trim argument was used by split_exclude() only to trim the last
join from the given lookup. It is cleaner to just trim the last part
from the lookup in split_exclude() directly so that there is no need
to burden add_filter() with the logic needed for only split_exclude().


  Commit: 69597e5bcc89aadafd1b76abf7efab30ee0b8b1a
  
https://github.com/django/django/commit/69597e5bcc89aadafd1b76abf7efab30ee0b8b1a
  Author: Anssi Kääriäinen 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/contrib/contenttypes/generic.py
M django/db/models/sql/compiler.py
M django/db/models/sql/constants.py
M django/db/models/sql/expressions.py
M django/db/models/sql/query.py
M tests/regressiontests/aggregation_regress/tests.py
M tests/regressiontests/queries/models.py
M tests/regressiontests/queries/tests.py

  Log Message:
  ---
  Fixed #10790 -- Refactored sql.Query.setup_joins()

This is a rather large refactoring. The "lookup traversal" code was
splitted out from the setup_joins. There is now names_to_path() method
which does the lookup traveling, the actual work of setup_joins() is
calling names_to_path() and then adding the joins found into the query.

As a side effect it was possible to remove the "process_extra"
functionality used by genric relations. This never worked for left
joins. Now the extra restriction is appended directly to the join
condition instead of the where clause.

To generate the extra condition we need to have the join field
available in the compiler. This has the side-effect that we need more
ugly code in Query.__getstate__ and __setstate__ as Field objects
aren't pickleable.

The join trimming code got a big change - now we trim all direct joins
and never trim reverse joins. This also fixes the problem in #10790
which was join trimming in null filter cases.


Compare: https://github.com/django/django/compare/d7b49f5b0dce...69597e5bcc89

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

Re: [Django] #14485: New Site.root field

[Django]

#14485: New Site.root field
---+-
 Reporter:  gsakkis|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by aaugustin):

 An alternative might be pluggable sites models. See also #2618.

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

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

Re: [Django] #14170: Issue in get_language_from_request() if LANGUAGES setting is changed at runtime

[Django]

#14170: Issue in get_language_from_request() if LANGUAGES setting is changed at
runtime
--+
 Reporter:  Kronuz|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Someday/Maybe => Accepted


Comment:

 The solution is to implement a `setting_changed` listener that resets the
 caches.

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

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

Re: [Django] #14092: ImageField should allow SVG

[Django]

#14092: ImageField should allow SVG
-+-
 Reporter:  graeme   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 `ImageField` is raster-oriented:
 - it validates common raster formats (JPG and PNG);
 - it denormalizes image width and height.

 There's little in common between raster and vector handling — at least in
 the scope of PIL. And SVGs don't have a width and a height expressed in
 pixel in general. I don't see what ImageField adds to FileField when it
 comes to SVG files.

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

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

Re: [Django] #12050: Provide a way to control markup standard for forms

[Django]

#12050: Provide a way to control markup standard for forms
-+-
 Reporter:  diraol   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  xml, xhtml, html5,   | Triage Stage:
  html4  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 If I understand correctly, #15667 covers the general issue of customizing
 form and widget rendering.

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

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

Re: [Django] #8565: Comments should use object_id instead of object_pk

[Django]

#8565: Comments should use object_id instead of object_pk
-+-
 Reporter:  baumer1122   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  contrib.comments |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  comments generic |  Someday/Maybe
  object_pk object_id|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 This is a bit annoying, but changing the name doesn't seem worth it at
 this point.

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

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

Re: [Django] #4467: handle a huge list of ForeignKey objects by implementing a CategorizedModelChoiceField

[Django]

#4467: handle a huge list of ForeignKey objects by implementing a
CategorizedModelChoiceField
-+-
 Reporter:  ulda |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  ForeignKey   | Triage Stage:
  ModelChoiceField   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 The implementation is very far from Django's current standards, and it
 doesn't need to live in core.

 Besides, demand for this feature is non-existent: there hasn't been a
 single commend here in 6 years.

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

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

Re: [Django] #14684: RESTful Model View

[Django]

#14684: RESTful Model View
-+-
 Reporter:  gdoermann|Owner:  lrekucki
 Type:  New feature  |   Status:  closed
Component:  Generic views|  Version:  1.3-alpha
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  models, views,   | Triage Stage:
  sprintdec2010  |  Someday/Maybe
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


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

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

Re: [Django] #6195: Allow caching of the javascript translation library by the client browser

[Django]

#6195: Allow caching of the javascript translation library by the client browser
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  i18 javascript   |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 I investigated this issue a few months ago for a project of mine.

 I found three non-exclusive ways to decorate `javascript_catalog` to
 provide caching.

 For providing translations in more than one language, the easiest is to
 include the language code in the URL with `i18n_patterns`.

 1) Server-side caching
 {{{
 key_prefix = 'js18n-%s' % get_version()
 @cache_page(86400, key_prefix=key_prefix)
 }}}
 You need a `get_version()` function that returns a different result
 whenever the translations change. In production, this isn't difficult, but
 it depends on your deployment strategy, making it hard for Django to
 provide a generic solution. In development, you have to use the dummy
 cache to avoid stale translations.

 The full translations catalog will be resent every time, but you'll save
 the generation cost.

 2) Client-side caching with If-Modified-Since:
 {{{
 last_modified_date = timezone.now()
 @last_modified(lambda req, **kw: last_modified_date)
 }}}
 `last_modified_date` changes whenever the server is reloaded (in
 production, because the code was updated; in development, because the dev
 server auto-reloaded). It's even better if you can set
 `last_modified_date` to the software release date, but that's a bit more
 difficult to get right than version numbers.

 3) Client-side caching with Etag:
 {{{
 etag_value = 'js18n-%s' % get_version()
 @etag(lambda req, **kw: etag_value)
 }}}

 In production, this is perfect. Unfortunately, it doesn't work well in
 development, because it's hard to generate an etag_value that's guaranteed
 to change when you just edit .po and .mo files.

 

 Neither of these techniques can provide proper cache invalidation without
 application-supplied information about the software version. Therefore, I
 think it's best to leave the implementation of caching to application
 developers. The cache framework provides tools to add caching with one-
 liners.

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

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

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Another final version - no major changes this time, just some minor
 cleanup. Patch at
 https://github.com/akaariai/django/compare/ticket_10790_final

 While I know a lot of things that could still be improved, it is time to
 just commit this one. I am confident that the taken approach is correct -
 while there might be regressions those should be fixable.

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

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

Re: [Django] #16679: Speed up signals by caching the reveicers per sender

[Django]

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 A rebased and slightly simplified version at
 https://github.com/akaariai/django/tree/ticket_16679.

 Benchmarks:
 model_init_signals (pre and post init signals defined for model __other__
 than initialized, one field for the initialized model):
 {{{
 Running 'model_init_signals' benchmark ...
 Min: 0.012126 -> 0.007745: 1.5656x faster
 Avg: 0.012178 -> 0.007774: 1.5666x faster
 Significant (t=644.833741)
 Stddev: 0.4 -> 0.2: 2.3318x smaller (N = 34)
 }}}
 Benchmark available at:
 
https://github.com/akaariai/djangobench/tree/continuous_bechmarking/djangobench/benchmarks/model_init_signals
 (Note that the djangobench used is somewhat hacked version - it discards
 2/3 of the results - the highest third and the lowest third - to get
 consistent results on my laptop).

 model_init_self_signals (pre and post init for same model):
 {{{
 Running 'model_init_self_signals' benchmark ...
 Min: 0.014637 -> 0.011735: 1.2473x faster
 Avg: 0.014675 -> 0.011762: 1.2477x faster
 Significant (t=530.411861)
 Stddev: 0.2 -> 0.2: 1.2429x smaller (N = 34)
 }}}
 
https://github.com/akaariai/djangobench/tree/continuous_bechmarking/djangobench/benchmarks/model_init_self_signals

 query_all (no signals at all, 1000 objects from DB)
 {{{
 Running 'query_all' benchmark ...
 Min: 0.006779 -> 0.006783: 1.0006x slower
 Avg: 0.006819 -> 0.006825: 1.0010x slower
 Not significant
 Stddev: 0.3 -> 0.3: 1.1693x larger (N = 34)
 }}}
 
https://github.com/akaariai/djangobench/tree/continuous_bechmarking/djangobench/benchmarks/query_all

 All tests pass and I don't see any reason to not add the cache. So, will
 commit tonight if no objections.

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

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

Re: [Django] #4065: Ability to disable admin pagination

[Django]

#4065: Ability to disable admin pagination
-+-
 Reporter:  Marek Kubica |Owner:  adamv
|   Status:  reopened
 Type:  New feature  |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  nfa-changelist   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Someday/Maybe => Accepted


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

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

Re: [Django] #2618: [patch] Added the ability for Site objects to have profiles.

[Django]

#2618: [patch] Added the ability for Site objects to have profiles.
---+-
 Reporter:  jay@…  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.sites  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by aaugustin):

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


Comment:

 `User` profiles haven't been very convincing. They've been deprecated in
 Django 1.5 in favor of custom user models.

 `Site` profiles probably wouldn't fare better. You could make a case for
 custom site models. If you're interested, please send a concrete proposal
 to the django-developers mailing list.

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

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

Re: [Django] #9156: Make tests self-contained

[Django]

#9156: Make tests self-contained
-+-
 Reporter:  pupeno   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  1.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Someday/Maybe
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 No concrete suggestion was made since Malcolm'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 https://groups.google.com/groups/opt_out.

Re: [Django] #8085: call_command('runserver') executes management command twice.

[Django]

#8085: call_command('runserver') executes management command twice.
-+-
 Reporter:  ericholscher |Owner:
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Reading this ticket, I don't understand what the problem is, or what the
 fix should be.

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

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

Re: [Django] #19469: Remove opts.get_ordered_objs()

[Django]

#19469: Remove opts.get_ordered_objs()
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"d7b49f5b0dcecfcc9b5a77632ecbba88e7637490"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d7b49f5b0dcecfcc9b5a77632ecbba88e7637490"
 Fixed #19469 -- Removed opts.get_ordered_objects() and related code

 The code was dead-code since 2006.
 }}}

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

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

[django/django] d7b49f: Fixed #19469 -- Removed opts.get_ordered_objects()...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d7b49f5b0dcecfcc9b5a77632ecbba88e7637490
  
https://github.com/django/django/commit/d7b49f5b0dcecfcc9b5a77632ecbba88e7637490
  Author: Anssi Kääriäinen 
  Date:   2012-12-16 (Sun, 16 Dec 2012)

  Changed paths:
M django/contrib/admin/options.py
R django/contrib/admin/static/admin/js/admin/ordering.js
R django/contrib/admin/static/admin/js/getElementsBySelector.js
M django/contrib/admin/templates/admin/change_form.html
M django/contrib/admin/templates/admin/submit_line.html
M django/contrib/admin/templatetags/admin_modify.py
M django/db/models/options.py

  Log Message:
  ---
  Fixed #19469 -- Removed opts.get_ordered_objects() and related code

The code was dead-code since 2006.



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

Re: [Django] #1453: generic views sometimes inefficient with large data sets - especially archive_index

[Django]

#1453: generic views sometimes inefficient with large data sets - especially
archive_index
---+
 Reporter:  hugo   |Owner:  zefciu
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

 * stage:  Someday/Maybe => Accepted


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

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

Re: [Django] #15110: User Isolation between sites.

[Django]

#15110: User Isolation between sites.
---+-
 Reporter:  jorgeecardona  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.auth   |  Version:  1.2
 Severity:  Normal |   Resolution:  fixed
 Keywords:  multitenancy   | Triage Stage:  Someday/Maybe
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by akaariai):

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


Comment:

 For the usermodel.site field: yes.

 I don't think we want to drag this ticket into solving all possible
 problems when having multiple users with same username, but different
 site. If there are places which makes this usecase extra complicated lets
 consider fixing those in separate tickets.

 So, closing this as fixed (by custom user models).

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

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

Re: [Django] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
--+
 Reporter:  jkocherhans   |Owner:  adrian
 Type:  New feature   |   Status:  reopened
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+
Changes (by aaugustin):

 * stage:  Fixed on a branch => Accepted


Comment:

 The GSoC branch is out of date.

 The latest efforts are in the [https://github.com/ptone/django/tree/app-
 loading app-loading branch].

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

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

Re: [Django] #7497: AppAdmin class for customizing app listing in admin index

[Django]

#7497: AppAdmin class for customizing app listing in admin index
---+-
 Reporter:  mrts   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 aaugustin):

 * status:  new => closed
 * resolution:   => duplicate
 * stage:  Someday/Maybe => Accepted


Comment:

 This is #3591 — also known as the 'app-loading' branch.

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

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

Re: [Django] #12767: Problem running syncdb with a multi-db router that restricts auth to a single database

[Django]

#12767: Problem running syncdb with a multi-db router that restricts auth to a
single database
-+-
 Reporter:  russellm |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => duplicate
 * stage:  Someday/Maybe => Accepted


Comment:

 This is a duplicate of #16039 that's fixed in 1.5.

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

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

Re: [Django] #16046: Document best practices around using request.is_secure() in reverse proxy environments

[Django]

#16046: Document best practices around using request.is_secure() in reverse 
proxy
environments
---+
 Reporter:  adamnelson |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  1.3
 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 aaugustin):

 * status:  new => closed
 * type:  Cleanup/optimization => New feature
 * resolution:   => fixed
 * stage:  Someday/Maybe => Accepted


Comment:

 As far as I can tell, 61f0aff811aa596fa62136852c59d47f988d1185 covers
 this.

 There's extensive documentation for the `SECURE_PROXY_SSL_HEADER` setting.

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

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

Re: [Django] #15110: User Isolation between sites.

[Django]

#15110: User Isolation between sites.
---+-
 Reporter:  jorgeecardona  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  1.2
 Severity:  Normal |   Resolution:
 Keywords:  multitenancy   | Triage Stage:  Someday/Maybe
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by aaugustin):

 Isn't this problem essentially solved by the custom user models introduced
 in Django 1.5?

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

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

Re: [Django] #13053: Support for non-static DB connection info

[Django]

#13053: Support for non-static DB connection info
-+-
 Reporter:  Lynge|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 This is a subset of the general problem of multi-tenancy (#15089).

 The approach taken by the patch doesn't work because Django maintains
 internal caches that depend on the values of settings. If you change the
 active settings between two requests handled by the same Python process,
 these caches may hold stale values, with undefined results.

 The `settings_changed` signal might help, but it's only designed for tests
 at this time, and I'm not sure it covers all settings at this time.

 I'm going to close this ticket because I don't think the solution to
 multi-tenancy will come from hacks in the settings.

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

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

Re: [Django] #19469: Remove opts.get_ordered_objs()

[Django]

#19469: Remove opts.get_ordered_objs()
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Ready for checkin


Comment:

 I think I will just commit what I have. If somebody needs any of the
 removed code it will be fairly simple to resurrect. And, I don't think the
 code will be missed...

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

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

Re: [Django] #14881: [nonrel] Do not assume ``User.id`` to be an integer in django.contrib.auth's pasword reset feature

[Django]

#14881: [nonrel] Do not assume ``User.id`` to be an integer in
django.contrib.auth's pasword reset feature
--+
 Reporter:  jonash|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  nonrel| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Someday/Maybe => Accepted


Comment:

 With the introduction of custom user models in 1.5, it's now possible to
 have a User model with a non-integer primary key.

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

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