Re: [Django] #18314: request.build_absolute_uri() functions incorrectly when the path starts with //

[Django]

#18314: request.build_absolute_uri() functions incorrectly when the path starts
with //
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by claudep):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 1
 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17890: django.contrib.admin.site extra_context

[Django]

#17890: django.contrib.admin.site extra_context
+
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by claudep):

 * needs_tests:  0 => 1


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

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

Re: [Django] #15246: Allow to change session expiration without re-saving session data.

[Django]

#15246: Allow to change session expiration without re-saving session data.
--+
 Reporter:  zimnyx|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_tests:  0 => 1


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

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

Re: [Django] #16884: Add message level argument to ModelAdmin's message_user

[Django]

#16884: Add message level argument to ModelAdmin's message_user
---+
 Reporter:  shelldweller   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+
Changes (by sbaechler):

 * cc: simon@… (added)


Comment:

 If you have to import messages anyway now, isn't it easier to just use
 messages.error(request, 'foo') instead of self.message_user(request,
 'foo', level=messages.ERROR) ?
 Especially since message_user doesn't seem to do anything but call
 messages.info().

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

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

Re: [Django] #18306: Deferred models should automatically issue update_fields when saving

[Django]

#18306: Deferred models should automatically issue update_fields when saving
-+-
 Reporter:  akaariai |Owner:  niwi
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by niwi):

 * owner:  nobody => niwi
 * status:  new => assigned


Comment:

 I've been testing, and all cases you mention, and work fine. In a few days
 I will work on the documentation and other aspects that you mentioned in
 the issue.

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

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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (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):

 So, you are creating !ForeignKeys with value 0 knowing they point nowhere?
 You should set the !ForeignKey as null=True and use None instead. You
 could get incorrect results from some queries if you use 0 instead of
 null=True.

 I don't think !ForeignKeys should be fixed to allow 0 as a value. Django's
 foreign keys are really meant to point at things if they have a value set.

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

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

Re: [Django] #10890: generic views archive_week and archive_day should have next/previous as Template Context

[Django]

#10890: generic views archive_week and archive_day should have next/previous as
Template Context
-+-
 Reporter:  ee_lars  |Owner:  aaugustin
 Type:  New feature  |   Status:  closed
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  generic views| Triage Stage:  Accepted
  date_based archive_day |  Needs documentation:  1
  archive_week   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [fcb09b5746192fea1b672346c915ee11e4120d7e]:
 {{{
 #!CommitTicketReference repository=""
 revision="fcb09b5746192fea1b672346c915ee11e4120d7e"
 Fixed #10890: added prev/next_week in the context

 of per-week date-based generic views. Thanks ee_lars for the report.
 }}}

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

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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (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 anonymous):

 Sorry that I opened it twice. Yes, I guess I found it a bit confusing that
 it said AutoField. My first reaction was to check the id of the object,
 which was not 0 (in fact I was editing something).

 But why is it illegal? I mean, it had worked before with no problem. I
 know it's not a good practice to have a foreign key as 0, but I don't
 understand how it can be illegal. Pointing a Foreign Key to 0 for me would
 be just like pointing to an id that doesn't exist, I don't see the
 difference. I did understand the bug you were trying to fix, but should
 this also apply to ForeignKeys?

 Thanks in advance!

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

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

[django/django] fcb09b: Fixed #10890: added prev/next_week in the context

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fcb09b5746192fea1b672346c915ee11e4120d7e
  
https://github.com/django/django/commit/fcb09b5746192fea1b672346c915ee11e4120d7e
  Author: Aymeric Augustin 
  Date:   2012-05-14 (Mon, 14 May 2012)

  Changed paths:
M django/views/generic/dates.py
M tests/regressiontests/generic_views/dates.py

  Log Message:
  ---
  Fixed #10890: added prev/next_week in the context

of per-week date-based generic views. Thanks ee_lars for the report.



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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (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 akaariai):

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


Comment:

 It seems you are trying to save 0 to a !ForeignKey which points to an
 !AutoField. But, this is illegal, as the !AutoField will not accept that
 value and so the !ForeignKey can not hold that value either.

 I am closing this still as fixed - you can again open this, but please
 provide more details if you do. The above explanation leaves us guessing
 if there is some bug or not in the newly introduced behavior. A
 testcase/testproject would be really valuable.

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

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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


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

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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (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 carneiro.be@…):

 Alright, I've managed to track what's my problem. I have a ForeignKey to
 the user model. If this value is 0 it will trigger this exception. I
 believe the patch isn't checking anywhere if it is in fact an autofield.
 Or this the desired behavior?

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

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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (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 aaugustin):

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


Comment:

 Yes, you're seeing the expected behavior introduced by the patch, ie.
 raising an explicit value error.

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

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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carneiro.be@…):

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


Comment:

 I am now getting the error "The database backend does not accept 0 as a
 value for AutoField." using the latest SVN version. What am I doing wrong?
 I'm not even using any AutoField (besides the django automatic id on all
 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18314: request.build_absolute_uri() functions incorrectly when the path starts with //

[Django]

#18314: request.build_absolute_uri() functions incorrectly when the path starts
with //
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  HTTP handling  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 A request to:

 http://www.example.com:8080//django-ate-my-baby/

 leads to request.build_absolute_uri() returning:

 http://django-ate-my-baby/

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

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

Re: [Django] #14646: django.contrib.comments is missing default template for comment_notification_email.txt, and has no documentation of template context

[Django]

#14646: django.contrib.comments is missing default template for
comment_notification_email.txt, and has no documentation of template
context
--+-
 Reporter:  tpherndon |Owner:  tzulberti
 Type:  Bug   |   Status:  new
Component:  contrib.comments  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  email, template   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by programmerq):

 * needs_tests:  1 => 0


Comment:

 As for the tests, all that would have to be done is remove the template
 that is used by the tests:
 
https://github.com/django/django/blob/master/tests/templates/comments/comment_notification_email.txt

 The tests currently use that to test the email functionality. If that file
 is removed, the test breaks. If that file is removed and the new template
 is checked in to django.contrib.comments, then the test will pass again.

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

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

Re: [Django] #1: Create architecture for anonymous sessions

[Django]

#1: Create architecture for anonymous sessions
--+--
 Reporter:  adrian|Owner:  jacob
 Type:  enhancement   |   Status:  closed
Component:  Core (Other)  |  Version:
 Severity:  normal|   Resolution:  fixed
 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 David):

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


Comment:

 From my experience, it looks good.
 David.

 --
 As careful readers would point, there's no playing with the cookies and
 setting the time to live. It should be obviously done after creationg of
 the object. At the moment, I don't have idea how to make it, but I don't
 think it'll be the problem to add some kind of _post_creation() method.

 The httpwrappers accusation is easier to respond. The
 [http://www.events-i-aarhus.dk event] has been invented for this kind of
 challenges. Anonymous session can be then created automatically after
 every request by our new middleware class, which would take care on them.
 If you don't need anonymous sessions, you simply do not set
 MIDDLEWARE_CLASSES.

 Feel free to comment.

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

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

Re: [Django] #17890: django.contrib.admin.site extra_context

[Django]

#17890: django.contrib.admin.site extra_context
+
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  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 smuss):

 * cc: stephenmuss@… (added)
 * has_patch:  0 => 1


Comment:

 Have created a patch and submitted a pull request at
 https://github.com/django/django/pull/64

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

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

Re: [Django] #15246: Allow to change session expiration without re-saving session data.

[Django]

#15246: Allow to change session expiration without re-saving session data.
--+
 Reporter:  zimnyx|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.4
 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 anonymous):

 * version:  master => 1.4
 * type:  New feature => Bug


Comment:

 Still a valid ticket in 1.4? Is the above patch helpful?

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

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

Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+-
 Reporter:  pixelcort|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  1
-+-
Changes (by kitsunde):

 * cc: kitsunde@… (added)


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

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

Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

[Django]

#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Template system  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by akaariai):

 * needs_docs:  0 => 1


Comment:

 To move this patch forward the patch would need some comments. Currently
 you need to do some reverse engineering to understand the patch. In
 addition this needs tests and possibly some doc changes along the lines of
 "When extending a template the currently used template is skipped. This
 allows to extend a template which has same path as the currently used
 template. This is useful when...".

 I trust there is no use case for extending "self" currently - it leads
 always to infinite recursion and thus there is no backwards compatibility
 issues here. What if the extended template name is a variable? It probably
 is impossible to change that variable, and there is still infinite
 recursion.

 I haven't done the reverse engineering mentioned above, so it might be the
 current approach as whole isn't correct.

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

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

Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

[Django]

#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Template system  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Wouter):

 Do something about this please!

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

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

Re: [Django] #18251: multithreading deadlock in django.models.loading.get_apps

[Django]

#18251: multithreading deadlock in django.models.loading.get_apps
-+-
 Reporter:  harm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by harm):

 patch looks sane. I think this is a clean an correct fix.

 I can't validate your testcase though. It seems the attachement is corrupt
 ?

 {{{
 harm@dev3:~$ wget -q --no-check-certificate
 https://code.djangoproject.com/attachment/ticket/18251/threading_lock.tar.gz
 harm@dev3:~$ tar vxzf threading_lock.tar.gz

 gzip: stdin: not in gzip format
 tar: Child returned status 1
 tar: Exiting with failure status due to previous errors

 }}}

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

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