Re: [Django] #11098: syncdb raising an ImportError when using pyuno

[Django]

#11098: syncdb raising an ImportError when using pyuno
-+-
 Reporter:  dedsm|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  syncdb importerror   | Triage Stage:
  import |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * 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] #16211: using negated F()-expression in update query

[Django]

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

Comment (by akaariai):

 Here is my idea how to move this issue forward:
   - Revert the commit
   - Remove '&' and '|' operators from 1.5, implement F.bitand() and
 F.bitor() instead
   - Reintroduce this feature into 1.6

 The idea is that in 1.5 usage of '&' and '|' will fail loudly. If we just
 replace what '&' and '|' do then there is possibility that the operators
 still work for upgraders, but they just don't do what they did in 1.4.
 This is a data-loss issue.

 In 1.6 we would have then boolean operators for F(), and '&' and '|' would
 work like they do for Q-objects.

 The '&' and '|' operators aren't documented, or at least I can't find any
 reference to them. The question is if anybody is actually using them. If
 not, then we could just replace the meaning of '&' and '|' directly in
 1.5. But, as said, I vote for the safe alternative of one release where
 you can't use '|' and '&' at all.

-- 
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] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
 Reporter:  marcin.tustin@…  |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  forms formsets   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by vicould):

 * cc: vicould (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.

[Django] #19054: Django backend for mysql is not installed

[Django]

#19054: Django backend for mysql is not installed
---+
 Reporter:  sholland@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:  MySQL
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The Django documentation
 https://docs.djangoproject.com/en/dev/ref/settings/#engine says that
 several backends are available with the Django distribution, including
 MySQL.  However, when I specifying mysql as the backend Django dies during
 startup with the error that the backend is not available.  On the web,
 multiple sites describe how to download MySQLdb and install. This backend
 should be in Django, or the documentation should instruct how to install
 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] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
 Reporter:  marcin.tustin@…  |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  forms formsets   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by vicould):

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

Re: [Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
 Reporter:  marcin.tustin@…  |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  forms formsets   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by vicould):

 Updated part of the patch, which could not be applied anymore: changed the
 context of the additional import required by the test.

-- 
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] #7377: "extends" and "block" tags are not available when constructing template from scratch

[Django]

#7377: "extends" and "block" tags are not available when constructing template
from scratch
-+
 Reporter:  mgeorge@…|Owner:  melinath
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  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 melinath):

 * status:  new => assigned


-- 
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] #19053: USE_THOUSAND_SEPARATOR causes error on inline admin

[Django]

#19053: USE_THOUSAND_SEPARATOR causes error on inline admin
---+
 Reporter:  alpha  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 when you use inline (tabular or stacked), it show a link to the object by
 the "view on site" link.
 but if you have USE_THOUSAND_SEPARATOR=True in the settings, the link will
 give an page not found.
 {{{ Content type 20 object 2 465 doesn't exist }}} with an space inside
 number 2465

-- 
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] 030b55: Removed incorrectly reintroduced 1.3 version notes

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 030b55393ea1164080a25eb6e241e43918bae8ac
  
https://github.com/django/django/commit/030b55393ea1164080a25eb6e241e43918bae8ac
  Author: Preston Holmes 
  Date:   2012-10-01 (Mon, 01 Oct 2012)

  Changed paths:
M docs/topics/auth.txt

  Log Message:
  ---
  Removed incorrectly reintroduced 1.3 version notes



-- 
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] 2aac3c: Cleaned up loaddata command options help text

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 2aac3ce0c6d944093f5c32e170c9a0d90e8e1f94
  
https://github.com/django/django/commit/2aac3ce0c6d944093f5c32e170c9a0d90e8e1f94
  Author: Preston Holmes 
  Date:   2012-10-01 (Mon, 01 Oct 2012)

  Changed paths:
M django/core/management/commands/loaddata.py

  Log Message:
  ---
  Cleaned up loaddata command options help text



-- 
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] #18447: LazyObject doesn't unwrap on dict access

[Django]

#18447: LazyObject doesn't unwrap on dict access
---+
 Reporter:  FunkyBob   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by d1ffuz0r):

 * cc: d1fffuz0r@… (added)
 * version:  1.4 => master


Comment:

 Added tests for the path
 https://github.com/django/django/pull/416

-- 
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] #19052: HTTP POST Dictionary should not be populated unconditionally

[Django]

#19052: HTTP POST Dictionary should not be populated unconditionally
---+--
 Reporter:  eric@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords:  http, post | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 Yes, what I meant to say that although it is lazily loaded, if accessed,
 it is unconditionally populated with the contents of the entity body.  The
 resulting QueryDict is garbage.  An application that attempts to access
 request.POST (or request.REQUEST) may get erroneous results.  The specific
 case I ran into is that in the application/octet-stream entity body, there
 were values that could get parsed into name/value pairs in request._post.
 However, they were never intended as query or form data parameters, yet
 showed up in the request.POST dictionary.  The application attempted to
 locate a parameter which was NOT specified in the query parameters, but
 which showed up in request.POST because it was put there upon lazy loading
 of the post data.

-- 
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] #19052: HTTP POST Dictionary should not be populated unconditionally

[Django]

#19052: HTTP POST Dictionary should not be populated unconditionally
---+--
 Reporter:  eric@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords:  http, post | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 It appears to me that `request.POST` is loaded lazily at the first access.

 Could you clarify why you think it's unconditionally loaded at the
 creation of the `HttpRequest`?

-- 
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] #19052: HTTP POST Dictionary should not be populated unconditionally

[Django]

#19052: HTTP POST Dictionary should not be populated unconditionally
---+
 Reporter:  eric@… |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:  1.4
 Severity:  Normal |   Keywords:  http, post
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When Django creates an HttpRequest object, it appears to populate the POST
 property by creating a QueryDict using the contents of the POST entity
 body unless the Content-Type header begins with "multipart" (in which case
 it attempts to process a file upload).  This behavior produces a garbage
 POST dictionary if the contents of the entity body are arbitrary binary
 data.  The populating of the POST QueryDict should be skipped unless the
 Content-Type specifies such processing (such as for URL-encoded form
 data).  It should not perform this processing, for example, if the
 Content-Type is application/octet-stream.

-- 
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] #18375: F() doesn't work as expected across multijoin relations

[Django]

#18375: F() doesn't work as expected across multijoin relations
-+-
 Reporter:  FunkyBob |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 True, that example isn't valid Python.

 The simplest example is something like this:
 {{{
 .filter(unter__id=1, id=F('unter__id'))
 }}}
 where unter is any reverse relation.

 Depending on the ordering of the kwargs dict the F() either creates a new
 join or not. This means the same query will execute differently on
 different runs if dict randomization is turned on.

-- 
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] 55fa86: Fixed postgres rollback issue with fixture test

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 55fa86a97f399df117d0de5f19d97dc72185c556
  
https://github.com/django/django/commit/55fa86a97f399df117d0de5f19d97dc72185c556
  Author: Preston Holmes 
  Date:   2012-10-01 (Mon, 01 Oct 2012)

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

  Log Message:
  ---
  Fixed postgres rollback issue with fixture test



-- 
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] #18375: F() doesn't work as expected across multijoin relations

[Django]

#18375: F() doesn't work as expected across multijoin relations
-+-
 Reporter:  FunkyBob |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by clelland):

 akaariai, shouldn't the query in comment:3 fail with a Syntax error? You
 can't specify the same keyword argument twice. The only way to filter
 twice on the same keyword is to call .filter() twice, which is well
 defined (in execution semantics, at least), or include duplicate Q objects
 (or mix Q objects with a keyword argument). Otherwise, you at least need
 to use a different operator, to filter twice on the same database field.
 Either
 {{{
 .filter(Q(unter__available__gt=0),
 Q(unter__available__gt=F('unter__used')))
 }}}
 or
 {{{
 .filter(Q(unter__available__gte=1, unter__available__gt=F('unter__used'))
 }}}
 should trigger this behaviour, though.

-- 
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] #19051: Error in testing/live-test-server example

[Django]

#19051: Error in testing/live-test-server example
---+
 Reporter:  glarrain   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 https://docs.djangoproject.com/en/1.4/topics/testing/#live-test-server

 In
 {{{
 MySeleniumTests.tearDownClass
 }}}
 this
 {{{
 cls.selenium.quit()
 }}}
 must appear before calling
 {{{
 super(MySeleniumTests, cls).tearDownClass()
 }}}

 Otherwise the test will fail with the following message: "RuntimeError:
 Failed to shutdown the live test server in 2 seconds. The server might be
 stuck or generating a slow response."

-- 
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] #8001: Make redirection URLs customizable in ModelAdmin views

[Django]

#8001: Make redirection URLs customizable in ModelAdmin views
---+
 Reporter:  julien |Owner:  nobody
 Type:  New feature|   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
---+

Comment (by ramiro):

 Work is ready for review in this branch
 https://github.com/ramiro/django/compare/master...8001_18310

-- 
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] #19050: auth.ModWsgiHandlerTestCase fails when User model is swapped

[Django]

#19050: auth.ModWsgiHandlerTestCase fails when User model is swapped
-+-
 Reporter:  ivan_virabyan|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

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


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

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

Re: [Django] #17751: GenericIPAddressField allows an ipv6 address to start with a space

[Django]

#17751: GenericIPAddressField allows an ipv6 address to start with a space
-+-
 Reporter:  federico.capoano@…   |Owner:  Federico
 Type:  Bug  |  Capoano
Component:  Forms|   Status:  new
 Severity:  Normal   |  Version:
 Keywords:   |  1.4-beta-1
  GenericIPAddressField, ipv6|   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by federico.capoano@…):

 why not just trimming the eventual initial white space? I could try fixing
 it even though I don't have experience with contributing back to django.
 Is there any page where it is described how to do so?

-- 
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] #19045: remove "Fixed on Branch" triage stage from Trac and Docs

[Django]

#19045: remove "Fixed on Branch" triage stage from Trac and Docs
--+
 Reporter:  ptone |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:  1 |UI/UX:  0
--+
Changes (by Preston Holmes ):

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


Comment:

 In [changeset:"14681eaa53a035fa1c8fc390d5cca0b340fdcdb3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="14681eaa53a035fa1c8fc390d5cca0b340fdcdb3"
 Fixed #19045 -- removed 'fixed on a branch' from triage docs
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] 14681e: Fixed #19045 -- removed 'fixed on a branch' from t...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 14681eaa53a035fa1c8fc390d5cca0b340fdcdb3
  
https://github.com/django/django/commit/14681eaa53a035fa1c8fc390d5cca0b340fdcdb3
  Author: Preston Holmes 
  Date:   2012-10-01 (Mon, 01 Oct 2012)

  Changed paths:
M docs/internals/contributing/triaging-tickets.txt

  Log Message:
  ---
  Fixed #19045 -- removed 'fixed on a branch' from triage docs



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

Re: [Django] #16211: using negated F()-expression in update query

[Django]

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

Comment (by akaariai):

 The problem is that in 1.4 we already do define '&' and '|' to behave as
 bitwise operators. This is not documented, but the behaviour is there and
 tested. For this feature we need the same '&' and '|' operators to do
 boolean AND and OR operations in the DB. This is a conflict which I don't
 see any nice way to resolve. The best would be to have f1.bitand(f2) and
 f1.bitor(f2). But, if we do this we will be silently breaking existing
 code using the '&' and '|' operators.

 As for `__hash__` - from Python 3 docs:
 {{{
 Called by built-in function hash() and for operations on members of hashed
 collections
 including set, frozenset, and dict. __hash__() should return an integer.
 The only
 required property is that objects which compare equal have the same hash
 value...
 }}}

 The problem is all F-objects compare equal to each other by the `__eq__`
 override, and for that reason we can't implement `__hash__`.

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

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

Re: [Django] #16211: using negated F()-expression in update query

[Django]

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

Comment (by twoolie):

 @akaariai: From the
 [http://docs.python.org/reference/datamodel.html#object.__hash__],

 > Called by built-in function hash() and for operations on members of
 hashed collections including set, frozenset, and dict. __hash__() should
 return an integer.
 > User-defined classes have `__cmp__()` and `__hash__()` methods by
 default; with them, all objects compare unequal (except with themselves)
 and `x.__hash__()` returns `id(x)`.

 This means that even when overriding `__eq__()` we are not breaking the
 hashability of F objects, and hence do not break sets or dicts.

 As far as using bitwise operators, we're forced to do it due to
 limitations in python's operator overloading. As far as i'm concerned,
 this is entirely consistent with Q objects and as long as it's explicitly
 documented, it should be fine. Really, the only way we can fix this is to
 make people do `(F('somefield')<100).and(F('somefield') >50)` every time
 they want to do `&&` which will be confusing.

 I volunteer to write extra docs for the new operators if that's required.

 (Random Thoughts) Perhaps what we need is an E object that can take a
 "normalized" (db independent) expression that we can build F objects from.

-- 
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] #19050: auth.ModWsgiHandlerTestCase fails when User model is swapped

[Django]

#19050: auth.ModWsgiHandlerTestCase fails when User model is swapped
---+
 Reporter:  ivan_virabyan  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.auth   |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 Assuming  {{{ AUTH_USER_MODEL }}} is set, running this test fails:



 {{{
 $python manage.py test auth.ModWsgiHandlerTestCase.test_check_password

 ERROR: test_check_password
 (django.contrib.auth.tests.handlers.ModWsgiHandlerTestCase)
 --
 Traceback (most recent call last):
   File
 "/Users/ivan/Projects/django/django/contrib/auth/tests/handlers.py", line
 14, in setUp
 user1 = User.objects.create_user('test', 't...@example.com', 'test')
 AttributeError: type object 'User' has no attribute 'objects'
 }}}

-- 
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] #19049: Subclassing AbstractUser doesn't work

[Django]

#19049: Subclassing AbstractUser doesn't work
---+--
 Reporter:  ivan_virabyan  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.auth   |  Version:  master
 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
---+--

Comment (by ivan_virabyan):

 I'm sorry. I have mispelled setting name.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #19049: Subclassing AbstractUser doesn't work

[Django]

#19049: Subclassing AbstractUser doesn't work
---+--
 Reporter:  ivan_virabyan  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.auth   |  Version:  master
 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 ivan_virabyan):

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


-- 
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] #19049: Subclassing AbstractUser doesn't work

[Django]

#19049: Subclassing AbstractUser doesn't work
---+--
 Reporter:  ivan_virabyan  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by akaariai):

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


Comment:

 Do you have settings.AUTH_USER_MODEL set to your User model? It seems you
 have both auth.user and accounts.user installed... I don't think it is
 possible to have subclassed !AbstractUser in use in addition to the
 default User model.

-- 
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] #19049: Subclassing AbstractUser doesn't work

[Django]

#19049: Subclassing AbstractUser doesn't work
---+
 Reporter:  ivan_virabyan  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.auth   |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 According to https://docs.djangoproject.com/en/dev/topics/auth/#extending-
 django-s-default-user I created my own User model


 {{{
 from django.contrib.auth.models import AbstractUser

 class User(AbstractUser):
 avatar = models.ImageField(upload_to='avatars')

 }}}

 but django complains:


 {{{
 CommandError: One or more models did not validate:
 accounts.user: Accessor for m2m field 'groups' clashes with related m2m
 field 'Group.user_set'. Add a related_name argument to the definition for
 'groups'.
 accounts.user: Accessor for m2m field 'user_permissions' clashes with
 related m2m field 'Permission.user_set'. Add a related_name argument to
 the definition for 'user_permissions'.
 auth.user: Accessor for m2m field 'groups' clashes with related m2m field
 'Group.user_set'. Add a related_name argument to the definition for
 'groups'.
 auth.user: Accessor for m2m field 'user_permissions' clashes with related
 m2m field 'Permission.user_set'. Add a related_name argument to the
 definition for 'user_permissions'.
 }}}

-- 
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] #19038: Add Experimental Support for Python 3.3

[Django]

#19038: Add Experimental Support for Python 3.3
-+--
 Reporter:  clelland |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by ojii):

 * cc: ojiidotch@… (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] #15089: contrib.sites and multitenancy

[Django]

#15089: contrib.sites and multitenancy
-+-
 Reporter:  legutierr|Owner:  apollo13
 Type:  New feature  |   Status:  new
Component:  contrib.sites|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"1ce4aedcefb68086918adc4137d75a6f2c0bd1f2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1ce4aedcefb68086918adc4137d75a6f2c0bd1f2"
 Prevented flatpage view from directly accessing settings.SITE_ID

 Refs #15089
 }}}

-- 
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] 1ce4ae: Prevented flatpage view from directly accessing se...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1ce4aedcefb68086918adc4137d75a6f2c0bd1f2
  
https://github.com/django/django/commit/1ce4aedcefb68086918adc4137d75a6f2c0bd1f2
  Author: Claude Paroz 
  Date:   2012-10-01 (Mon, 01 Oct 2012)

  Changed paths:
M django/contrib/flatpages/views.py

  Log Message:
  ---
  Prevented flatpage view from directly accessing settings.SITE_ID

Refs #15089



-- 
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] #14087: django.core.management.get_commands only sees commands in the last package of a namespace package

[Django]

#14087: django.core.management.get_commands only sees commands in the last 
package
of a namespace package
--+
 Reporter:  KyleMac   |Owner:  nobody
 Type:  Bug   |   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:  0
--+

Comment (by Natim):

 My patch for Python 1.4.1 : https://code.djangoproject.com/ticket/19048

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

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

Re: [Django] #16211: using negated F()-expression in update query

[Django]

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

Comment (by akaariai):

 BTW I can't see the bitwise operators for F() expressions documented
 anywhere. I think we want to document those...

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

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

Re: [Django] #16211: using negated F()-expression in update query

[Django]

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

 * status:  closed => reopened
 * has_patch:  1 => 0
 * resolution:  fixed =>
 * severity:  Normal => Release blocker


Comment:

 It seems I will have to revert this whole commit. The problem is we define
 '&' and '|' operators as bitwise and / or. But, other operators we define
 as boolean operators. This means (F('somefield') < 100) & (F'somefield') >
 50) doesn't do what one expects, and downright fails on some databases.

 I can see only one solutions apart of just reverting and wontfixing this
 issue: Create a subclass of F which redefines what '&' and '|' mean.

 I will leave this open for a while to see if any ideas pop out. The most
 likely solution is a revert from 1.5. Then we can revisit this issue for
 1.6 and see if we can create something working...

 This is causing a failure in expressions tests at least on postgres.

-- 
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] #8280: Commands framework doesn't support alternate import methods

[Django]

#8280: Commands framework doesn't support alternate import methods
--+
 Reporter:  jdetaeye  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  command zip   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 #19048 was a duplicate with a proposed patch

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

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

Re: [Django] #19048: [Management commands] Unknown commands on python packages application

[Django]

#19048: [Management commands] Unknown commands on python packages application
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  duplicate
 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 claudep):

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


Comment:

 Duplicate of #8280

-- 
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] #19048: [Management commands] Unknown commands on python packages application

[Django]

#19048: [Management commands] Unknown commands on python packages application
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natim):

 More information here : http://www.python.org/dev/peps/pep-0420/

-- 
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] #19048: [Management commands] Unknown commands on python packages application

[Django]

#19048: [Management commands] Unknown commands on python packages application
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   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 Natim):

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


Comment:

 It seams to come from this django.core.management.find_management_module
 which call imp.find_module('django_project')

 This command, return the first pkg_module path and not all of them.

-- 
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:
 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):

 Related: #19045.

-- 
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] #19045: remove "Fixed on Branch" triage stage from Trac and Docs

[Django]

#19045: remove "Fixed on Branch" triage stage from Trac and Docs
--+
 Reporter:  ptone |Owner:  nobody
 Type:  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:  1 |UI/UX:  0
--+
Changes (by aaugustin):

 * version:  1.4 => master
 * component:  Djangoproject.com Web site => Documentation


-- 
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] #19045: remove "Fixed on Branch" triage stage from Trac and Docs

[Django]

#19045: remove "Fixed on Branch" triage stage from Trac and Docs
-+-
 Reporter:  ptone|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Djangoproject.com|   Resolution:
  Web site   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by aaugustin):

 +1

 I've removed "Fixed on a branch" from Trac's configuration.

 Now we need to update the "triage workflow" section in the docs.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #19048: [Management commands] Unknown commands on python packages application

[Django]

#19048: [Management commands] Unknown commands on python packages application
+
 Reporter:  Natim   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 We are using the python namespace package functionality for a django
 project.

 {{{
 __import__('pkg_resources').declare_namespace(__name__)
 }}}

 But the commands not in the project package (the one with manage.py) are
 not found by the manage.py commands.

-- 
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] #19047: FilteredSelectMultiple gets cleared when using back button

[Django]

#19047: FilteredSelectMultiple gets cleared when using back button
---+
 Reporter:  olofsj@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  1
---+
 In the admin all fields that use a FilteredSelectMultiple will be cleared
 if the user leaves the page and then returns via the back button in the
 browser.

 The reason seems to be that the FilteredSelectMultiple widget removes all
 selected items from the original select widget and moves them to another
 select widget. This confuses the browser about which items were selected.

 The attached patch works around this by setting all items that were
 originally selected by default as selected. Then at least the widget gets
 back to the state it had on initial page load, though any changes the user
 may have done before leaving the page will not be kept so there's probably
 a better way to solve 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] #15919: Test failure on specific label

[Django]

#15919: Test failure on specific label
---+--
 Reporter:  BerislavLopac  |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Testing framework  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by aigarius):

 * status:  closed => reopened
 * ui_ux:   => 0
 * resolution:  worksforme =>
 * version:  1.3 => 1.4
 * easy:  0 => 1


Comment:

 This issue shows up if the tests are defined in the application using the
 suite(). The django.test.simple.build_suite() function has support for
 such arrangement (which is why testing the whole app works), but
 django.test.simple.build_test() does not which is why running a single
 test class or test case fails with the above error. The fix would be to
 call build_suite in build_test and then iterate over the TestSuite, just
 like it is done in the Doctest code in the same function.

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

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

Re: [Django] #19045: remove "Fixed on Branch" triage stage from Trac and Docs

[Django]

#19045: remove "Fixed on Branch" triage stage from Trac and Docs
-+-
 Reporter:  ptone|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Djangoproject.com|   Resolution:
  Web site   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by claudep):

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


Comment:

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