Re: [Django] #6702: ModelForm: assert given instance is instance of model

[Django]

#6702: ModelForm: assert given instance is instance of model
--+
 Reporter:  guettli   |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  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 selwin):

 * cc: selwin (added)
 * needs_tests:  1 => 0


Comment:

 I opened a pull request on Github to fix this issue here:
 https://github.com/django/django/pull/296 . Test included.

-- 
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] #18830: FormWizard with Formset and Form Fields mixed on same page

[Django]

#18830: FormWizard with Formset and Form Fields mixed on same page
-+
 Reporter:  jeff@…   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I would like to request something like the following:
 On a given page in a FormWizard, support the ability to mix a formset
 along with other form fields.

 A use-case would be a page in a wizard that lets you add N users to email,
 and a textarea to customize this email.

 The code for such a thing would look like

 forms.py
 {{{
 # Step 1 in wizard
 class Step1Form(forms.Form):
 # interesting form fields...

 # Form for the email addresses used in Step 2 Formset
 class EmailAddressForm(forms.Form):
 email = forms.EmailField()

 # Step 2 in wizard
 class EmailAddressesAndText(forms.Form):
 emailText = forms.Textarea()
 emailAddressFormSet = formset_factory(EmailAddressForm,
 can_delete=True, ...)
 }}}

 in urls.py
 {{{
 ##
 named_formwizard_forms = (
 ('Step1', Step1Form),
 ('Step2', EmailAddressesAndText),
 )
 }}}

 This would be a very clean way to mix form fields and an embedded formset
 in a way that can be leveraged as part of the FormWizard found in 1.4

 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.

[Django] #18829: ModelChoiceIterator returns the queryset length when

[Django]

#18829: ModelChoiceIterator returns the queryset length when
---+---
 Reporter: |  Owner:  nobody
  facundo.olano@…  | Status:  new
 Type:  Bug|Version:  1.4
Component:  Forms  |   Keywords:  ModelChoiceIterator ModelForm
 Severity:  Normal |  Has patch:  0
 Triage Stage:  Unreviewed |  UI/UX:  0
Easy pickings:  0  |
---+---
 In forms/models.py, the ModelChoiceIterator defines an {{{ __iter__ }}}
 method which yields an empty entry {{{ if empty_label is not None}}}, but
 the {{{ __len__ }}} method always returns the length of the queryset, no
 matter if the empty choice is present.

 {{{
 def __iter__(self):
 if self.field.empty_label is not None:
 yield (u"", self.field.empty_label)
 if self.field.cache_choices:
 if self.field.choice_cache is None:
 self.field.choice_cache = [
 self.choice(obj) for obj in self.queryset.all()
 ]
 for choice in self.field.choice_cache:
 yield choice
 else:
 for obj in self.queryset.all():
 yield self.choice(obj)

 def __len__(self):
 return len(self.queryset)
 }}}


 This can lead to erratic behavior when iterating. For example, the
 following template code wont hold the expected output, because the
 forloop.last will be True before for the second to last item, causing the
 semicolon to render on the last line and not in the previous one.


 {{{
 {% for choice_id, choice_name in my_form.my_field.field.choices %}
 {{ choice_id }} - {{ choice_name }} {% if not forloop.last %};{% endif
 %}
 {% endfor %}
 }}}

 This would produce an output like:

 {{{
  - -;
 1 - One;
 2 - Two
 3 - Three;
 }}}

-- 
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] #18063: repr() should return only ascii, not unicode

[Django]

#18063: repr() should return only ascii, not unicode
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by DrMeers):

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


Comment:

 See Karen's notes above.

-- 
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] #18063: repr() should return only ascii, not unicode

[Django]

#18063: repr() should return only ascii, not unicode
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by DrMeers):

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


Comment:

 Auto-"fixed" by git commit; reopening to mark as wontfix/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] #18063: repr() should return only ascii, not unicode

[Django]

#18063: repr() should return only ascii, not unicode
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Meers ):

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


Comment:

 In [dfe63a52effab2c8b5f72a6aceb8646f03d490bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="dfe63a52effab2c8b5f72a6aceb8646f03d490bb"
 Revert "Fixed #18063 -- Avoid unicode in Model.__repr__ in python 2"

 This reverts commit 3fce0d2a9162cf6e749a6de0b18890dea8955e89.
 }}}

-- 
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] dfe63a: Revert "Fixed #18063 -- Avoid unicode in Model.__r...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: dfe63a52effab2c8b5f72a6aceb8646f03d490bb
  
https://github.com/django/django/commit/dfe63a52effab2c8b5f72a6aceb8646f03d490bb
  Author: Simon Meers 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M django/db/models/base.py
M tests/regressiontests/model_regress/tests.py

  Log Message:
  ---
  Revert "Fixed #18063 -- Avoid unicode in Model.__repr__ in python 2"

This reverts commit 3fce0d2a9162cf6e749a6de0b18890dea8955e89.



-- 
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] #18063: repr() should return only ascii, not unicode

[Django]

#18063: repr() should return only ascii, not unicode
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by DrMeers):

 Hmm, I think you are correct here Karen, thanks for investigating this
 further.

-- 
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] #18063: repr() should return only ascii, not unicode

[Django]

#18063: repr() should return only ascii, not unicode
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kmtracey):

 * status:  closed => reopened
 * resolution:  fixed =>
 * severity:  Normal => Release blocker
 * stage:  Accepted => Unreviewed


Comment:

 I don't believe this fix is correct. More broadly, the problem description
 is not correct. Nowhere in the referenced Python documentation
 
(http://docs.python.org/reference/datamodel.html?highlight=repr#object.__repr!__)
 does it say the (byte)string returned by `__repr__` must contain only
 ASCII characters. Django was not returning unicode from `__repr__`, it was
 returning a utf-8 encoded bytestring. That's perfectly legal Python. The
 fact that some other bits of Python tools are unhelpful and deal with non-
 ascii data by throwing up "unprintable exception object" when an exception
 is raised involving a model instance with non-ASCII data in its repr
 indicates a bug somewhere else. That bug should be fixed at its source,
 not by removing non-ASCII characters from model instances' repr.

 The referenced doc also states "This is typically used for debugging, so
 it is important that the representation is information-rich and
 unambiguous." This change has moved in the wrong direction on that score.
 Consider before the change:

 {{{
 --> ./manage.py shell
 Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
 [GCC 4.6.1] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> import django
 >>> django.get_version()
 u'1.5.dev20120819181059'
 >>> from ctrac.models import Cat
 >>> Cat.objects.filter(adopted_name__startswith='Am')
 []
 >>> quit()
 }}}

 After the change:

 {{{
 --> ./manage.py shell
 Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
 [GCC 4.6.1] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> import django
 >>> django.get_version()
 u'1.5.dev20120821213816'
 >>> from ctrac.models import Cat
 >>> Cat.objects.filter(adopted_name__startswith='Am')
 []
 >>>
 }}}

 That second output would have me concerned the my data been corrupted,
 when in fact it has not. It is just `__repr__` that is now corrupting it
 on output.

 I believe this change should be reverted and the ticket closed either
 wontfix or needsinfo. needsinfo would be to investigate under what
 conditions the real problem (unprintable exception objects) occurs and to
 see if there is anything that Django is doing to cause it (though I rather
 suspect is a base Python problem).

 Marking release blocker because this has introduced a regression in
 functionality from previous release.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
-+-
 Reporter:  danbrwn  |Owner:  mitsuhiko
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
  foreign,key,quoted,dceu2011|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Replying to [comment:40 auzigog]:
 > I'm also experiencing this in 1.4.1. I can confirm this regression.

 Can you post a simple example demonstrating 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 https://groups.google.com/groups/opt_out.

Re: [Django] #18828: Tutorial Code/Syntax Error

[Django]

#18828: Tutorial Code/Syntax Error
-+-
 Reporter:  knightxthyme@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  erorr, typo, syntax  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Replying to [comment:2 timo]:
 > You are probably mixing versions of the tutorial. choice.choice has been
 renamed choice.choice_text in the development version of the tutorial.

 Oh, I thought I had been using version 1.4 the whole time.
 "choice.choice" wouldn't work, but just "choice" is working.
 Maybe I did something else wrong, but it works for me now.

-- 
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] #18828: Tutorial Code/Syntax Error

[Django]

#18828: Tutorial Code/Syntax Error
-+-
 Reporter:  knightxthyme@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  erorr, typo, syntax  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 You are probably mixing versions of the tutorial. choice.choice has been
 renamed choice.choice_text in the development version of the tutorial.

-- 
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] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
-+-
 Reporter:  danbrwn  |Owner:  mitsuhiko
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
  foreign,key,quoted,dceu2011|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by auzigog):

 I'm also experiencing this in 1.4.1. I can confirm this regression.

-- 
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] #18828: Tutorial Code/Syntax Error

[Django]

#18828: Tutorial Code/Syntax Error
-+-
 Reporter:  knightxthyme@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  erorr, typo, syntax  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by anonymous):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #18828: Tutorial Code/Syntax Error

[Django]

#18828: Tutorial Code/Syntax Error
+-
 Reporter:  knightxthyme@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Documentation   |Version:  1.4
 Severity:  Normal  |   Keywords:  erorr, typo, syntax
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
 In the '''tutorial part 04''', from the example code given for the
 “'''polls/detail.html'''” file, I believe:

 {{ '''choice.choice'''
 }}

 Should simply be:

 {{ '''choice''' }}


 This is also the case for the “'''polls/results.html'''” where:

 {{ '''choice.choice''' }} -- {{ choice.votes }} vote{{
 choice.votes|pluralize }}

 Should be:

 {{ '''choice''' }} -- {{ choice.votes }} vote{{ choice.votes|pluralize
 }}


 Thank you for putting up such good documentaries!
 I really value being able to learn things like this online. Thanks so
 much, I love 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] #18637: FK.limit_choices_to doc says it's for admin, but works in ModelForm

[Django]

#18637: FK.limit_choices_to doc says it's for admin, but works in ModelForm
---+
 Reporter:  Tuttle |Owner:  stumbles
 Type:  Bug|   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:  1  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [27c2ccc1ea0d08752a480aae30d48be6126d21ff]:
 {{{
 #!CommitTicketReference repository=""
 revision="27c2ccc1ea0d08752a480aae30d48be6126d21ff"
 [1.4.x] Fixed #18637 - Updated some documentation for aspects of models
 that are ModelForm specific, not admin specific.

 Thanks Ben Sturmfels for the patch.

 Backport of 13d47c3f338e1e9a5da943b97b5334c0523d2e2c 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] 27c2cc: [1.4.x] Fixed #18637 - Updated some documentation ...

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 27c2ccc1ea0d08752a480aae30d48be6126d21ff
  
https://github.com/django/django/commit/27c2ccc1ea0d08752a480aae30d48be6126d21ff
  Author: Tim Graham 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M docs/ref/models/fields.txt
M docs/topics/db/models.txt

  Log Message:
  ---
  [1.4.x] Fixed #18637 - Updated some documentation for aspects of models that 
are ModelForm specific, not admin specific.

Thanks Ben Sturmfels for the patch.

Backport of 13d47c3f338e1e9a5da943b97b5334c0523d2e2c 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] #18637: FK.limit_choices_to doc says it's for admin, but works in ModelForm

[Django]

#18637: FK.limit_choices_to doc says it's for admin, but works in ModelForm
---+
 Reporter:  Tuttle |Owner:  stumbles
 Type:  Bug|   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:  1  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [13d47c3f338e1e9a5da943b97b5334c0523d2e2c]:
 {{{
 #!CommitTicketReference repository=""
 revision="13d47c3f338e1e9a5da943b97b5334c0523d2e2c"
 Fixed #18637 - Updated some documentation for aspects of models that are
 ModelForm specific, not admin specific.

 Thanks Ben Sturmfels for the 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.

[django/django] 13d47c: Fixed #18637 - Updated some documentation for aspe...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 13d47c3f338e1e9a5da943b97b5334c0523d2e2c
  
https://github.com/django/django/commit/13d47c3f338e1e9a5da943b97b5334c0523d2e2c
  Author: Tim Graham 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M docs/ref/models/fields.txt
M docs/topics/db/models.txt

  Log Message:
  ---
  Fixed #18637 - Updated some documentation for aspects of models that are 
ModelForm specific, not admin specific.

Thanks Ben Sturmfels for the patch.



-- 
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] #14885: is_valid for ModelForm changes instance if instance is provided

[Django]

#14885: is_valid for ModelForm changes instance if instance is provided
-+-
 Reporter:  italomaia|Owner:  stumbles
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.2
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  forms, is_valid, |  Needs documentation:  0
  bad data   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by Tim Graham ):

 In [42aee6ffe5f16852347e0cf069447950e9d2ef85]:
 {{{
 #!CommitTicketReference repository=""
 revision="42aee6ffe5f16852347e0cf069447950e9d2ef85"
 [1.4.x] Fixed #14885 - Clarified that ModelForm cleaning may not fully
 complete if the form is invalid.

 Thanks Ben Sturmfels for the patch.

 Backport of 3fd89d99036696ba08dd2dd7e20a5b375f85d23b 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] 42aee6: [1.4.x] Fixed #14885 - Clarified that ModelForm cl...

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 42aee6ffe5f16852347e0cf069447950e9d2ef85
  
https://github.com/django/django/commit/42aee6ffe5f16852347e0cf069447950e9d2ef85
  Author: Tim Graham 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M docs/topics/forms/modelforms.txt

  Log Message:
  ---
  [1.4.x] Fixed #14885 - Clarified that ModelForm cleaning may not fully 
complete if the form is invalid.

Thanks Ben Sturmfels for the patch.

Backport of 3fd89d99036696ba08dd2dd7e20a5b375f85d23b 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] #14885: is_valid for ModelForm changes instance if instance is provided

[Django]

#14885: is_valid for ModelForm changes instance if instance is provided
-+-
 Reporter:  italomaia|Owner:  stumbles
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.2
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  forms, is_valid, |  Needs documentation:  0
  bad data   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [3fd89d99036696ba08dd2dd7e20a5b375f85d23b]:
 {{{
 #!CommitTicketReference repository=""
 revision="3fd89d99036696ba08dd2dd7e20a5b375f85d23b"
 Fixed #14885 - Clarified that ModelForm cleaning may not fully complete if
 the form is invalid.

 Thanks Ben Sturmfels for the 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.

[django/django] 3fd89d: Fixed #14885 - Clarified that ModelForm cleaning m...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3fd89d99036696ba08dd2dd7e20a5b375f85d23b
  
https://github.com/django/django/commit/3fd89d99036696ba08dd2dd7e20a5b375f85d23b
  Author: Tim Graham 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M docs/topics/forms/modelforms.txt

  Log Message:
  ---
  Fixed #14885 - Clarified that ModelForm cleaning may not fully complete if 
the form is invalid.

Thanks Ben Sturmfels for the patch.



-- 
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] #18196: loaddata doesn't handle ImportError exception

[Django]

#18196: loaddata doesn't handle ImportError exception
-+-
 Reporter:  nvalcarcel@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [4353a6163c00d4193307dae533e3e6ae9b44d18f]:
 {{{
 #!CommitTicketReference repository=""
 revision="4353a6163c00d4193307dae533e3e6ae9b44d18f"
 Fixed #18196 -- Improved loaddata error messages.
 }}}

-- 
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] 4353a6: Fixed #18196 -- Improved loaddata error messages.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4353a6163c00d4193307dae533e3e6ae9b44d18f
  
https://github.com/django/django/commit/4353a6163c00d4193307dae533e3e6ae9b44d18f
  Author: Claude Paroz 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M django/core/management/commands/loaddata.py
M django/test/signals.py
M tests/regressiontests/fixtures_regress/tests.py

  Log Message:
  ---
  Fixed #18196 -- Improved loaddata error messages.



-- 
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] #18827: Exclude __pycache__ from module detection

[Django]

#18827: Exclude __pycache__ from module detection
---+
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Python 3   |  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 claudep):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Related tickets: #8280, #15084

-- 
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] #17886: LOUTER join not promoted across filter expression

[Django]

#17886: LOUTER join not promoted across filter expression
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Normal   |   Resolution:  fixed
 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 Anssi Kääriäinen ):

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


Comment:

 In [a193372753ad9d1d15ad5e2d6d06bbc07ca3f433]:
 {{{
 #!CommitTicketReference repository=""
 revision="a193372753ad9d1d15ad5e2d6d06bbc07ca3f433"
 Fixed #17886 -- Fixed join promotion in ORed nullable queries

 The ORM generated a query with INNER JOIN instead of LEFT OUTER JOIN
 in a somewhat complicated case. The main issue was that there was a
 chain of nullable FK -> non-nullble FK, and the join promotion logic
 didn't see the need to promote the non-nullable FK even if the
 previous nullable FK was already promoted to LOUTER JOIN. This resulted
 in a query like a LOUTER b INNER c, which incorrectly prunes results.
 }}}

-- 
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] a19337: Fixed #17886 -- Fixed join promotion in ORed nulla...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a193372753ad9d1d15ad5e2d6d06bbc07ca3f433
  
https://github.com/django/django/commit/a193372753ad9d1d15ad5e2d6d06bbc07ca3f433
  Author: Anssi Kääriäinen 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

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

  Log Message:
  ---
  Fixed #17886 -- Fixed join promotion in ORed nullable queries

The ORM generated a query with INNER JOIN instead of LEFT OUTER JOIN
in a somewhat complicated case. The main issue was that there was a
chain of nullable FK -> non-nullble FK, and the join promotion logic
didn't see the need to promote the non-nullable FK even if the
previous nullable FK was already promoted to LOUTER JOIN. This resulted
in a query like a LOUTER b INNER c, which incorrectly prunes results.



-- 
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] #17886: LOUTER join not promoted across filter expression

[Django]

#17886: LOUTER join not promoted across filter expression
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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 akaariai):

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


Comment:

 I now know what was the reason for the wrong query. The basic problem was
 that we had an existing LOUTER JOIN, and joined a non-nullable FK to that.
 In that case we must LOUTER JOIN the new join, too, but the current code
 doesn't consider the case where the previous join was a LOUTER JOIN. The
 patch just directly creates the join as LOUTER JOIN, thus there is no need
 to fix promote_alias() logic.

 #16715 would fix this issue, but even if I am planning to commit that one
 soon, I do think the idea of generating LOUTER JOIN automatically in case
 we are joining to an existing LOUTER JOIN chain is obviously correct, and
 thus it is a good idea to apply this.

 The cleaned up patch is
 
[https://github.com/akaariai/django/commit/a193372753ad9d1d15ad5e2d6d06bbc07ca3f433
 here], the main change is that the test case is reduced to the minimal set
 of filters displaying the issue in this ticket.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #18827: Exclude __pycache__ from module detection

[Django]

#18827: Exclude __pycache__ from module detection
--+
   Reporter:  aaugustin   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Python 3|Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 If you make a typo in the database backend you get this error message on
 Python 3:

 {{{
 Try using django.db.backends.XXX, where XXX is one of:
 '__pycache__', 'dummy', 'mysql', 'oracle', 'postgresql_psycopg2',
 'sqlite3'
 }}}

 At least `__pycache__` should be filtered out. Maybe `dummy` too.

 It would be nice to check if this pattern occurs in other places in
 Django.

 (One more reason not to attempt listing modules in a package...)

-- 
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] #18826: A bit changed JavaScript for CSRF with async JS

[Django]

#18826: A bit changed JavaScript for CSRF with async JS
--+
 Reporter:  panco |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.4
 Severity:  Normal|   Keywords:  ajax, csrf
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Recently I've found use for the code found at
 https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax
 and as I can't sleep well if my JS doesn't pass some of the basic JSlint
 standards I've changed the snippet a bit:
 {{{
 jQuery(document).ajaxSend(function (event, xhr, settings) {
 function getCookie(name) {
 var cookieValue = null, cookies = [], i = 0, j = 0, cookie
 = {};
 if (document.cookie && document.cookie !== '') {
 cookies = document.cookie.split(';');
 for (j = cookies.length; i < j; i += 1) {
 cookie = jQuery.trim(cookies[i]);
 // Does this cookie string begin with the
 name we want?
 if (cookie.substring(0, name.length + 1)
 === (name + '=')) {
 cookieValue =
 decodeURIComponent(cookie.substring(name.length + 1));
 break;
 }
 }
 }
 return cookieValue;
 }

 function sameOrigin(url) {
 // url could be relative or scheme relative or absolute
 var host = document.location.host, // host + port
 protocol = document.location.protocol,
 sr_origin = '//' + host,
 origin = protocol + sr_origin;
 // Allow absolute or scheme relative URLs to same origin
 return (url === origin || url.slice(0, origin.length + 1)
 === origin + '/') || (url === sr_origin || url.slice(0, sr_origin.length +
 1) === sr_origin + '/') || // or any other URL that isn't scheme relative
 or absolute i.e relative.
 !(/^(\/\/|http:|https:).*/.test(url));
 }

 function safeMethod(method) {
 return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
 }

 if (!safeMethod(settings.type) && sameOrigin(settings.url)) {
 xhr.setRequestHeader("X-CSRFToken",
 getCookie('csrftoken'));
 }
 });
 }}}

 * "===" instead of "=="
 * all vars at the beginning of the function (and all the changes that
 brings forth)

 I realize these changes are very small, but I think since this is a simple
 copy/paste snippet it should be of the highest quality possible (there's
 room for improvement still).
 I'm using it and it performs as intended.

-- 
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] #17069: Extend the error logger's API to allow ignoring some errors

[Django]

#17069: Extend the error logger's API to allow ignoring some errors
---+
 Reporter:  julien |Owner:  peppergrower
 Type:  New feature|   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 peppergrower):

 * owner:  nobody => peppergrower
 * has_patch:  0 => 1


Comment:

 As suggested by carljm, I added a change to the docs in
 [https://github.com/django/django/pull/297 this pull request]. Since we
 now have the exception class {{{ UnreadablePostError }}} (#17277),
 filtering out incomplete uploads is fairly simple and hopefully makes a
 good example of filtering.

-- 
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] fd58d6: Merge walk and find_files in makemessages command

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fd58d6c258058f8ac54e241b21b949bdbe50059b
  
https://github.com/django/django/commit/fd58d6c258058f8ac54e241b21b949bdbe50059b
  Author: Claude Paroz 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

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

  Log Message:
  ---
  Merge walk and find_files in makemessages command



-- 
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] #18825: Improve the Django Homepage

[Django]

#18825: Improve the Django Homepage
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Djangoproject.com|   Resolution:  invalid
  Web site   | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-

Comment (by idangazit):

 We've got a very active redesign effort underway—we've selected a team,
 and we're working with them daily on revamping djangoproject.com. I don't
 have a forecast for when we'll relaunch; but I suspect that it will be in
 the next three or four months. Such are the constraints with volunteer
 projects.

 This sort of effort doesn't fare well when thousands of community members
 each try to take their own paintbrush to the bikeshed, which is why we
 aren't publicizing our work as we go. We're focused on delivering a better
 experience for our target audiences, and one of those audiences are new
 users—exactly like the ones you are trying to introduce to Django. We have
 them in mind when it comes to everything about the site—content, IA, and
 visual design.

-- 
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] #18825: Improve the Django Homepage

[Django]

#18825: Improve the Django Homepage
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Djangoproject.com|   Resolution:  invalid
  Web site   | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


Comment:

 The developers of Django [https://groups.google.com/d/topic/django-
 developers/2Xy7SZAOc7E/discussion are aware] that the website could use an
 update. I haven't followed the latest news, but this is definitely on the
 radar.

 However, Trac isn't the right medium for this discussion: design-by-
 committee is a well-known recipe for disasters. Therefore I will close
 this ticket.

 Thanks for your feedback!

-- 
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] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.auth  |  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 robgolding63):

 My thinking was that `override_settings` is a class decorator, so by
 having `AUTH_PROFILE_MODULE` set to the empty string (or `None`), it's
 effectively unset at the start of each method call. We could then set it
 as required, or just leave it unset in this particular case.

 Perhaps the only way that would work, though, is if the tests were in
 separate classes altogether - which isn't exactly ideal.

 In any case, implementing #18824 will no doubt be useful in other places
 too - so that's probably the best course of action.

-- 
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] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.auth  |  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 claudep):

 I don't think so. AUTH_PROFILE_MODULE can be set in the current project
 settings and therefore I don't see how we can avoid the del. However, you
 have a point in that the del would probably succeed if the test was not in
 an override_settings context. But then we should also restore it at the
 end of the test, exactly the sort of manipulation we want to avoid with
 override_settings. That's why I still favour the solution proposed in
 #18824.

-- 
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] #18825: Improve the Django Homepage

[Django]

#18825: Improve the Django Homepage
+
 Reporter:  anonymous   |  Owner:  nobody
 Type:  Cleanup/optimization| Status:  new
Component:  Djangoproject.com Web site  |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  1   |  UI/UX:  1
+
 I tried introducing Django to a few colleagues of mine but they were put
 off by the homepage design and the getting started guide. I think the
 homepage could be improved a lot - it currently lacks focus and doesn't
 really give a good first impression.

 The core features of Django (displayed below the "Meet Django" box) are
 half hidden. They could be the key focus (showing off why Django is
 awesome) or at least be displayed more prominently, perhaps with an icon.

 Try and view the Django homepage with a fresh set of eyes, imagining that
 this is the first visit. The immediate focus is drawn to the "download"
 button, the rest is a mass of text. The tutorial is a small hyperlink not
 emphasised in any way. There is too much information squeezed into the
 homepage.

 The getting started guide could also be improved. The homepage states that
 Django helps you write web applications quickly and with less code, but it
 takes 3 pages until you write your first view. I'm not really sure how to
 improve this but it also seems like a wall of text with too much
 information squeezed into 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] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.auth  |  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 robgolding63):

 As far as I can see, moving the separate tests to their own functions
 would remove the need to use `del settings.AUTH_PROFILE_MODULE`, and so
 would work around this issue. As it stands there are 3 tests sitting in
 the same function (`test_site_profile_not_available`), so it probably
 makes more sense to break them out?

-- 
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] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.auth  |  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 claudep):

 This problem is a symptom of #18824.

-- 
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] #18824: Allow deletion of a setting from overridden settings

[Django]

#18824: Allow deletion of a setting from overridden settings
---+--
 Reporter:  claudep|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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

[Django] #18824: Allow deletion of a setting from overridden settings

[Django]

#18824: Allow deletion of a setting from overridden settings
-+
   Reporter:  claudep|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Currently, if you call `del settings.SOME_SETTING` when the settings have
 been customized with override_settings, the setting still exists if it was
 pre-existing in the original settings object. See #17966 for a real use
 case.

-- 
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] ab2f65: Removed obsolete __members__ definitions

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ab2f65bb7f9083b5fac777f5e3b7872c58837f4f
  
https://github.com/django/django/commit/ab2f65bb7f9083b5fac777f5e3b7872c58837f4f
  Author: Claude Paroz 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M django/conf/__init__.py
M django/utils/functional.py

  Log Message:
  ---
  Removed obsolete __members__ definitions

This was useful for pre-Python 2.6 support. See commit c6e8e5d9.



-- 
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] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.auth  |  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
--+
Changes (by claudep):

 * 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 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:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I quickly skimmed the patch and I do think this is useful, and that the
 patch is mostly ready. So, it is likely that this would get merged,
 although there can not be any guarantee.

 My biggest worry is the `__eq__` and `__ne__` methods. I have a feeling
 defining these methods to return another expression could lead to weird
 situations. Basically any f expression always returns True from ==, and
 !=, so if people are using these comparisons (or we happen to use these
 comparisons internally in Django) things will break.

 Maybe the `__eq__` and `__ne__` should be implemented as methods instead,
 so, instead of writing F('foo') == F('bar'), you would write
 F('foo').eq(F('bar')). It is a bit uglier, but should be safe re the above
 issue.

 I don't know too well how Python expects these methods to behave, so it is
 possible that this is an acceptable way to use `__eq__` and `__ne__`.

-- 
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] #18818: Typo: PDKDF instead of PBKDF

[Django]

#18818: Typo: PDKDF instead of PBKDF
-+-
 Reporter:  jonaskoelker@…   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:  typo |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by claudep):

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


Comment:

 Already fixed in #18819

-- 
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:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Looks like it has tests. If docs were written and patch rebased, would it
 get merged?

-- 
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] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
---+
 Reporter:  delormemarco@… |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.4
 Severity:  Release blocker|   Resolution:
 Keywords:  regression | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * has_patch:  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] #17040: In utils.crypto.constant_time_compare only call ord on non ints.

[Django]

#17040: In utils.crypto.constant_time_compare only call ord on non ints.
--+
 Reporter:  adsworth  |Owner:  adsworth
 Type:  Bug   |   Status:  closed
Component:  Python 3  |  Version:  1.3
 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 Aymeric Augustin ):

 In [e89bc39935afc5096e6a51a49874b2d30cbc2b5e]:
 {{{
 #!CommitTicketReference repository=""
 revision="e89bc39935afc5096e6a51a49874b2d30cbc2b5e"
 Reverted type check added in 62954ba04c.

 Refs #17040.
 }}}

-- 
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] e89bc3: Reverted type check added in 62954ba04c.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e89bc39935afc5096e6a51a49874b2d30cbc2b5e
  
https://github.com/django/django/commit/e89bc39935afc5096e6a51a49874b2d30cbc2b5e
  Author: Aymeric Augustin 
  Date:   2012-08-21 (Tue, 21 Aug 2012)

  Changed paths:
M django/utils/crypto.py
M tests/regressiontests/utils/crypto.py

  Log Message:
  ---
  Reverted type check added in 62954ba04c.

Refs #17040.



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