date:20160503

Re: [Django] #26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a bit.

2016-05-03 Thread Django

#26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a
bit.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"ad0f536e1c80e7122f03ae4746a90904a573b4b8" ad0f536e]:
 {{{
 #!CommitTicketReference repository=""
 revision="ad0f536e1c80e7122f03ae4746a90904a573b4b8"
 Fixed #26577 -- Disabled implicit wait of Selenium tests where
 appropriate.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e56070b00ae617d5127285ec6e9ee4f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a bit.

2016-05-03 Thread Django

#26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a
bit.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c7c5a3f7b79c118afaaf126befaabf13%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22936: Get rid of field.get_db_prep_lookup()

2016-05-03 Thread Django

#22936: Get rid of field.get_db_prep_lookup()
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 I submitted a PR to Claude's PR in comment:4 which completes the 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a5782003f2b2a22b5ea546902a4d43cb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14415: Multiple aliases for one database: testing problems

2016-05-03 Thread Django

#14415: Multiple aliases for one database: testing problems
-+-
 Reporter:  shai |Owner:  boaz85
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  multidb, multiple| Triage Stage:  Accepted
  databases, multiple aliases|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * type:  Uncategorized => Bug


Comment:

 Did you try to add a test for that change?

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.64fc7bfd39ae4e66d491de7f278d67d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26097: UserCreationForm isn't using password_validators_help_text_html

2016-05-03 Thread Django

#26097: UserCreationForm isn't using password_validators_help_text_html
--+
 Reporter:  ataylor32 |Owner:  sasha0
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_tests:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2589f87a8733d42de1cb87c229cb6f2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26579: Control deep copy depth for 'save as new' in admin with inlines

2016-05-03 Thread Django

#26579: Control deep copy depth for 'save as new' in admin with inlines
---+--
 Reporter:  heka27 |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  saveasnew  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 I'm not immediately convinced -- could you sketch out the idea at a high
 level a bit more? How will the user understand the expected behavior?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.26f5637e9436e4103499a2f0536e9a54%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26579: Control deep copy depth for 'save as new' in admin with inlines

2016-05-03 Thread Django

#26579: Control deep copy depth for 'save as new' in admin with inlines
---+--
 Reporter:  heka27 |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  saveasnew  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by heka27):

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


Old description:

> Proposal:
>
> Add 'save_as' class attribute to all InlineModelAdmin. By default it
> should probably True.
>
> ModelAdmin could then be modified as followed:
>
> {{{
> def get_formsets_with_inlines(self, request, obj=None):
> """
> Yields formsets and the corresponding inlines.
> """
> if '_saveasnew' in request.POST:
> inline_instances = [inline_instance for inline_instance in
> self.get_inline_instances(request, obj)
> if getattr(inline_instance, 'save_as',
> True)]
> else:
> inline_instances = self.get_inline_instances(request, obj)
>
> for inline in inline_instances:
> yield inline.get_formset(request, obj), inline
>
> }}}
>
> This change will allow you to control the save_as behavior per inline

New description:

 Proposal:

 Add 'save_as' class attribute to InlineModelAdmin. By default it should
 probably True.

 ModelAdmin could then be modified as followed:

 {{{
 def get_formsets_with_inlines(self, request, obj=None):
 """
 Yields formsets and the corresponding inlines.
 """
 if '_saveasnew' in request.POST:
 inline_instances = [inline_instance for inline_instance in
 self.get_inline_instances(request, obj)
 if getattr(inline_instance, 'save_as',
 True)]
 else:
 inline_instances = self.get_inline_instances(request, obj)

 for inline in inline_instances:
 yield inline.get_formset(request, obj), inline

 }}}

 This change will allow you to control the save_as behavior per inline

--

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.35b8f713a0c2038ce032dfad36cf66e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26579: Control deep copy depth for 'save as new' in admin with inlines

2016-05-03 Thread Django

#26579: Control deep copy depth for 'save as new' in admin with inlines
---+---
 Reporter:  heka27 |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:  saveasnew
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 Proposal:

 Add 'save_as' class attribute to all InlineModelAdmin. By default it
 should probably True.

 ModelAdmin could then be modified as followed:

 {{{
 def get_formsets_with_inlines(self, request, obj=None):
 """
 Yields formsets and the corresponding inlines.
 """
 if '_saveasnew' in request.POST:
 inline_instances = [inline_instance for inline_instance in
 self.get_inline_instances(request, obj)
 if getattr(inline_instance, 'save_as',
 True)]
 else:
 inline_instances = self.get_inline_instances(request, obj)

 for inline in inline_instances:
 yield inline.get_formset(request, obj), inline

 }}}

 This change will allow you to control the save_as behavior per inline

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.316e844f8ef23233f7ae5d92b7179cb3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26578: validate_ipv4_address (and probably other validators) accept non-ASCII digits

2016-05-03 Thread Django

#26578: validate_ipv4_address (and probably other validators) accept non-ASCII
digits
--+
 Reporter:  mdickopp  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.9
 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):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Other)
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 See also #22378.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.72c67968665120eb0089a1a2cfcbdc92%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26578: validate_ipv4_address (and probably other validators) accept non-ASCII digits

2016-05-03 Thread Django

#26578: validate_ipv4_address (and probably other validators) accept non-ASCII
digits
---+
 Reporter:  mdickopp   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 validate_ipv4_address incorrectly accepts values that contain non-ASCII
 digits, e.g. 127.0.0.൧ (where the last character is U+0D67) in Python 3.
 This appears to be caused by the use of \d in the regular expression,
 which matches not only ASCII digits [0-9], but any Unicode digit.

 Other validators that use \d may be affected as well.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.6a47eec4b7f473ad332ef0b94cf4d416%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14370: Adding support for Autocomplete in contrib.admin

2016-05-03 Thread Django

#14370: Adding support for Autocomplete in contrib.admin
-+-
 Reporter:  tyrion   |Owner:  codingjoe
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  autocomplete,| Triage Stage:  Accepted
  jquery, javascript, widgets,   |
  admin  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by codingjoe):

 Since there are so many people following this ticket. Please review. From
 where I'm standing this ticket is only shy of a review to be merged into
 1.10. So please, please, please :)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.41a9579a329dcc0cfb658a110ce0e1ea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14370: Adding support for Autocomplete in contrib.admin

2016-05-03 Thread Django

#14370: Adding support for Autocomplete in contrib.admin
-+-
 Reporter:  tyrion   |Owner:  codingjoe
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  autocomplete,| Triage Stage:  Accepted
  jquery, javascript, widgets,   |
  admin  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by codingjoe):

 Replying to [comment:50 yeago]:
 > I'd like to raise something else for discussion...
 >
 > Regarding permission checks, I think matching the way raw_id_fields
 would just be building in unwanted limitations in many cases. Firstly, the
 permission says 'change' where no change is occurring. It just seemed like
 the original implementation was taking a short-cut by using that
 permission (since it was effectively a pop-out changeview).
 >
 > In many cases, someone may want to grant access to a form that has an
 autocomplete list of users but that doesn't mean they want to grant change
 access to their user list. Moreover, we're already granting a permission
 when we are allowing access to the admin form the autocomplete would be
 used on. I'm not sure what case we are covering by granting access to a
 form but not granting access to the autocomplete we explicitly added.

 It's not implemented that way. In fact you need change permission on the
 model the you are currently editing not the related object. e.g. If you
 have access to groups but not to users, the groups m2m autocomplete would
 still work.
 Does that solve the issue for you?

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.3737d22202b25169baa82010a6185b3d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26449: Document that SplitDateTimeWidget requires SplitDateTimeField

2016-05-03 Thread Django

Comment (by MarysiaLowas):

@timgraham That ticket you mentioned is about inheriting and this issue is
about merging dictionaries.

@yakky It's not so much about `AdminSplitDateTime` as about
`formfield_overrides` for `DateTimeField`. I wanted to use
`formfield_overrides` to override the default widget for `DateTimeField`,
and I was doing it according to the published documentation (not the
inline docs in the code), and I got an error.

Please see the PR I created which should solve this problem
[https://github.com/django/django/pull/6553 PR for #26449 ]

This is my first contribution to Django, so please forgive me if I
happened not to follow the procedures or custom at any point. That was
unconsciously done.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/070.84236fd591fecedb49d6a2f7d3609640%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

2016-05-03 Thread Django

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * keywords:   => db-indexes


--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.3666d7a4b34d2a3bdff31237cbfab792%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a bit.

2016-05-03 Thread Django

#26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a
bit.
--+
 Reporter:  charettes |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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 charettes):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/6552 PR]

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.70058c84fb1a5a17eb86b79548c60775%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14370: Adding support for Autocomplete in contrib.admin

2016-05-03 Thread Django

Comment (by yeago):

I'd like to raise something else for discussion...

Regarding permission checks, I think matching the way raw_id_fields would
just be building in unwanted limitations in many cases. Firstly, the
permission says 'change' where no change is occurring. It just seemed like
the original implementation was taking a short-cut by using that
permission (since it was effectively a pop-out changeview).

In many cases, someone may want to grant access to a form that has an
autocomplete list of users but that doesn't mean they want to grant change
access to their user list. Moreover, we're already granting a permission
when we are allowing access to the admin form the autocomplete would be
used on. I'm not sure what case we are covering by granting access to a
form but not granting access to the autocomplete we explicitly 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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.2c469a1056351426a6f2b10842af63c8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a bit.

2016-05-03 Thread Django

#26577: Usage of `implicitly_wait` in selenium tests can slow down tests quite a
bit.
+
Reporter: charettes | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Testing framework |Version: master
Severity: Normal| Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
+
While reviewing #26575 I noticed that some `find_elements_by_css_selector`
were taking forever to execute (10 seconds) and I realized it was related
to #26048.

One example is when `AdminSeleniumTestCase.assertSelectOptions` is used to
assert that no options are present (`assertSelectOptions('#select', [])`.
In this case the `find_elements_by_css_selector('#select > option')` call
blocks for 10 seconds as no options are present in the select.

Since there's no way to specify an explicit `timeout` argument to the
`find_elements` methods I think we'll have to issue an
`implicitly_wait(0)` before calling them. Ideally we would use an explicit
wait with an appropriate condition if `values == []` but I can't find how
to bypass the implicit wait when calling `find_elements` methods.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/052.5f086e29e4a8f1bfbbfd68b56876e59c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26575: Admin SelectFilter Buttons Not Disabled When Inactive

2016-05-03 Thread Django

#26575: Admin SelectFilter Buttons Not Disabled When Inactive
-+-
 Reporter:  dsanders11   |  Owner:  nobody
 Type:  Bug  | Status:  closed
Component:  contrib.admin|Version:  master
 Severity:  Normal   | Resolution:  fixed
 Keywords:  admin selectfilter disabled  |   Triage Stage:
  inactive   |  Unreviewed
Has patch:  1|  Easy pickings:  0
UI/UX:  0|
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"e00d77c4834b40f06f9bf271da5fdfb526ad8f56" e00d77c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="e00d77c4834b40f06f9bf271da5fdfb526ad8f56"
 Fixed #26575 -- Disabled SelectFilter buttons when inactive.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.52ecc9cc5b72d1835eb2cbaf03abf0dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26567: Update references to the HTTP spec

2016-05-03 Thread Django

#26567: Update references to the HTTP spec
--+
 Reporter:  vfaronov  |Owner:  vfaronov
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 I think the same could be done with RFC 5322 replacing RFC 2822. vfaronov,
 up to a similar 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.486068e0032b649fc670ac2d58e97c8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26570: Test runner imports models package with Python 3.5+

2016-05-03 Thread Django

#26570: Test runner imports models package with Python 3.5+
---+--
 Reporter:  bronger|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.9
 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
---+--

Comment (by claudep):

 #26576 was a duplicate with some other symptoms described.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.bc1879003fd4d86015f65d7f6ba16b8b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26576: django.conf and test discovery issues with Python 3.5

2016-05-03 Thread Django

#26576: django.conf and test discovery issues with Python 3.5
---+--
 Reporter:  eukreign   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 Duplicate of #26570.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2abf577ec0df7670108d5ddade6a172f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26572: AdminEmailHandler fails to honor subject length limit

2016-05-03 Thread Django

#26572: AdminEmailHandler fails to honor subject length limit
-+
 Reporter:  pdewacht |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 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):

 * needs_better_patch:  1 => 0


Comment:

 The [https://github.com/django/django/pull/6551 new PR].

 pdewacht, what was your issue with subject line length?

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a2fff4a201d53f9a767de73dd69a3813%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26572: AdminEmailHandler fails to honor subject length limit

2016-05-03 Thread Django

* needs_better_patch: 0 => 1

Comment:

After some more consideration, I discovered that headers are not limited
in total length by the spec, only individual lines are. Read
https://tools.ietf.org/html/rfc5322#section-2.1.3: `An unfolded header
field has no length restriction and therefore may be indeterminately
long.`.
Then Python is automatically folding headers when sending messages, by
default to 78 characters. So now I think that the subject line truncation
is simply wrong. Of course, it's not nice to receive very long headers,
but we have no reason to truncate subject or any other header.
We might even question the refusal to accept newlines in headers, but that
would be the subject of a separate 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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.8314f12cfd58e73bd2333127e032416d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22897: Make query_string argument to QueryDict optional

2016-05-03 Thread Django

#22897: Make query_string argument to QueryDict optional
--+
 Reporter:  duncan@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  HTTP handling |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"ead21a1949e408cf37226049559d0e71e3fdff6d" ead21a1]:
 {{{
 #!CommitTicketReference repository=""
 revision="ead21a1949e408cf37226049559d0e71e3fdff6d"
 Refs #22897 -- Removed unneeded empty string QueryDict argument.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.ffed42987d438a701b3e419432b6f6f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26567: Update references to the HTTP spec

2016-05-03 Thread Django

#26567: Update references to the HTTP spec
--+
 Reporter:  vfaronov  |Owner:  vfaronov
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"cb33e553ee537da4915f9055f8cdf9bf32113aed" cb33e553]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb33e553ee537da4915f9055f8cdf9bf32113aed"
 [1.9.x] Fixed #26567 -- Updated references to obsolete RFC2616.

 Didn't touch comments where it wasn't obvious that the code adhered to
 the newer standard.

 Backport of ac77c55bc5fc54cd763a7ae426784650a8cc97c9 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ccf5fc1720a82e8e2de843a4db5f2a77%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26567: Update references to the HTTP spec

2016-05-03 Thread Django

#26567: Update references to the HTTP spec
--+
 Reporter:  vfaronov  |Owner:  vfaronov
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ac77c55bc5fc54cd763a7ae426784650a8cc97c9" ac77c55]:
 {{{
 #!CommitTicketReference repository=""
 revision="ac77c55bc5fc54cd763a7ae426784650a8cc97c9"
 Fixed #26567 -- Updated references to obsolete RFC2616.

 Didn't touch comments where it wasn't obvious that the code adhered to
 the newer standard.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c1b7abe2fbb9a09ea3262a4202eb3dc7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26572: AdminEmailHandler fails to honor subject length limit

2016-05-03 Thread Django

#26572: AdminEmailHandler fails to honor subject length limit
-+
 Reporter:  pdewacht |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 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


Comment:

 I tried the "lower level" technique in
 [https://github.com/django/django/pull/6550 that PR].

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a7f6dfaa534c0b188ac5aa9d76a4bf52%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26561: SelectBox Too Slow With Thousands of Options

2016-05-03 Thread Django

#26561: SelectBox Too Slow With Thousands of Options
-+-
 Reporter:  dsanders11   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  selectbox admin  | Triage Stage:  Accepted
  many-to-many m2m   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"fb68674ea4b05280e3deb2ed23602038755092bc" fb68674e]:
 {{{
 #!CommitTicketReference repository=""
 revision="fb68674ea4b05280e3deb2ed23602038755092bc"
 Fixed #26561 -- Improved admin's JavaScript SelectBox performance on large
 lists.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.005e7d662f7a6e81f6b1a1ef97905040%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26576: django.conf and test discovery issues with Python 3.5

2016-05-03 Thread Django

#26576: django.conf and test discovery issues with Python 3.5
---+
 Reporter:  eukreign   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 There appears to be an issue between django loaded app settings and the
 same settings being loaded again by the test discover code.

 I should first mention how my settings are laid out:

 {{{
 /project/settings/__init__.py <-- imports .local or .production
 /project/settings/local.py
 /project/settings/production.py
 /project/apps <-- different apps
 }}}

 `__init__.py` is something like `from .local import *` and is not checked
 into version control.
 `manage.py` has `DJANGO_SETTINGS_MODULE=project.settings`.

 This setup has worked just fine up until upgrade to Python 3.5 (from 3.4).

 The issue now, when running `./manage.py test project` is that the
 settings get loaded twice:

 1. Django loads the settings first and proceeds to fill in all of the
 default/missing settings values.
 2. After Django finishes loading the test discovery code runs, if the
 `settings` directory is in the path of the discover search then the
 `__init__.py` gets loaded again and ends up resetting the settings+default
 values loaded in step 1.

 For example, stepping through the debugger on
 [https://github.com/django/django/blob/master/django/test/runner.py#L466
 line 466 in django/test/runner.py] and printing the before (repl line 1
 below) and after (repl line 2) values of default connection settings
 produces the following results:

  {{{
 #!python
 >>> connections['default'].settings_dict['TEST']
 {'MIRROR': None, 'NAME': None, 'CHARSET': None, 'SERIALIZE': False,
 'COLLATION': None}
 >>> connections['default'].settings_dict['TEST']
 {'SERIALIZE': False}
 }}}

 It seems that something has changed in Python 3.5 that causes Python to
 realize that the same module is being imported again and to overwrite the
 previous import erasing the defaults set by Django.

 If instead of `./manage.py test project` I run `./manage.py test
 project.apps` then all of the tests work fine.

 Possible solutions:

 1. Provide some kind of useful error explaining why this is happening. -
 or -
 2. Prevent the settings from getting reset when test discovery finds and
 loads the settings module.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.0bbb1e6059d7e1bdf7f49e61703118a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26573: Empty 'AssertionError' exception message on syntax error ({% else if %}) in templates

2016-05-03 Thread Django

#26573: Empty 'AssertionError' exception message on syntax error ({% else if 
%}) in
templates
-+-
 Reporter:  vakorol  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  assertionerror   | Triage Stage:  Accepted
  template elsif |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d1c7d567cb6de7dcc60728fbb78f6245%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26574: Need to do bitwise operations in where clause

2016-05-03 Thread Django

#26574: Need to do bitwise operations in where clause
+--
 Reporter:  awol|Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  1.9
 Severity:  Normal  |   Resolution:
 Keywords:  QuerySet.extra  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

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


Comment:

 From [https://docs.djangoproject.com/en/stable/topics/db/queries/#filters-
 can-reference-fields-on-the-model the docs]:
 {{{
  The F() objects support bitwise operations by .bitand() and .bitor(), for
 example:

  >>> F('somefield').bitand(16)
 }}}
 If this isn't sufficient, could you give an example usage of
 `QuerySet.extra()` that you aren't able to replace?

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.5a984243ef65d917026efa170876cf78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16508: Provide real support for virtual fields

2016-05-03 Thread Django

#16508: Provide real support for virtual fields
-+-
 Reporter:  vzima|Owner:  pirosb3
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tim Graham ):

 In [changeset:"b9f8635f58ad743995cad2081b3dc395e55761e5" b9f8635]:
 {{{
 #!CommitTicketReference repository=""
 revision="b9f8635f58ad743995cad2081b3dc395e55761e5"
 Refs #16508 -- Added invalidation of stale cached instances of
 GenericForeignKey targets.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.bdb25c0c70e5c30b33cace7ed45e33a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26565: Allow Prefetch query to use .values()

2016-05-03 Thread Django

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * has_patch:  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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.304ee55ea59d9579a168178cede77301%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26565: Allow Prefetch query to use .values()

2016-05-03 Thread Django

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * type:  Bug => New feature


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f12522e9194a1d21af3ebbe820ffbe3d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26565: Allow Prefetch query to use .values()

2016-05-03 Thread Django

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"7ec330eeb96d0874949eacb8ed1bbb97e11807e1" 7ec330e]:
 {{{
 #!CommitTicketReference repository=""
 revision="7ec330eeb96d0874949eacb8ed1bbb97e11807e1"
 Refs #26565 -- Errored nicely when using Prefetch with a values()
 queryset.

 Thanks Maxime Lorant for the report and Anssi for the suggestion.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f402d796491901f99a2c4ed4606fd291%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16508: Provide real support for virtual fields

2016-05-03 Thread Django

#16508: Provide real support for virtual fields
-+-
 Reporter:  vzima|Owner:  pirosb3
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tim Graham ):

 In [changeset:"8a47ba679d2da0dee74671a53ba0cd918b433e34" 8a47ba67]:
 {{{
 #!CommitTicketReference repository=""
 revision="8a47ba679d2da0dee74671a53ba0cd918b433e34"
 Refs #16508 -- Made Model.__init__() aware of virtual fields.

 It's no longer necessary for GenericForeignKey (and any other virtual
 fields)
 to intercept the field's values using the pre_init signal.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.785535ab45bd7d6ce1c40276145b746e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26575: Admin SelectFilter Buttons Not Disabled When Inactive

2016-05-03 Thread Django

#26575: Admin SelectFilter Buttons Not Disabled When Inactive
-+-
 Reporter:   |  Owner:  nobody
  dsanders11 |
 Type:  Bug  | Status:  new
Component:   |Version:  master
  contrib.admin  |   Keywords:  admin selectfilter disabled
 Severity:  Normal   |  inactive
 Triage Stage:   |  Has patch:  1
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 The action buttons (choose, remove, choose all, remove all) for
 SelectFilter still respond to click events while visually marked inactive,
 and will clear any selection in the boxes if clicked.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.aa42ba5885a4799d35147a881780%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26402: Allow relative paths in {% extends %} and {% include %}

2016-05-03 Thread Django

#26402: Allow relative paths in {% extends %} and {% include %}
-+-
 Reporter:  vb64 |Owner:  vb64
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  extends,include,template,relative  |
  path   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vb64):

 * needs_better_patch:  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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.3fb99bd73919baf4dffd69a9ff212930%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26292: Refactor MigrationLoader.build_graph() to use more of MigrationGraph's features

2016-05-03 Thread Django

#26292: Refactor MigrationLoader.build_graph() to use more of MigrationGraph's
features
--+
 Reporter:  MarkusH   |Owner:  jarekwg
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 MarkusH):

 * needs_better_patch:  1 => 0


Comment:

 I'll give this PR a small benchmark test later this week, but would
 generally love to see this in 1.10. There are a couple of optimization
 options Jarek and I have in mind but they should be fine to be submitted
 when alpha was cut, IMO.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f7e5811e460a3979a732a711319c8565%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26574: Need to do bitwise operations in where clause

2016-05-03 Thread Django

#26574: Need to do bitwise operations in where clause
---+
 Reporter:  awol   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:  QuerySet.extra
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 We receive a bitmask in a field from an external source and we need to do
 bitwise comparisons (of some complexity) with this field when selecting
 from the table in question. The bitwise operators are supported by the
 postgres backend. Deprecating the QuerySet.extra would make that
 hard/impossible I think.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.23c3150633508690181b6b46564e9b3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26572: AdminEmailHandler fails to honor subject length limit

2016-05-03 Thread Django

#26572: AdminEmailHandler fails to honor subject length limit
-+
 Reporter:  pdewacht |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 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):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Mail)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1dc2f45982a2572f0c000a092f8ed8e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26573: Empty 'AssertionError' exception message on syntax error ({% else if %}) in templates

2016-05-03 Thread Django

#26573: Empty 'AssertionError' exception message on syntax error ({% else if 
%}) in
templates
---+---
 Reporter:  vakorol|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Template   |Version:  1.8
  system   |
 Severity:  Normal |   Keywords:  assertionerror template elsif
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 If one erroneously uses `{% else if ... %}` instead of `{% elif ... %}` in
 django templates:

 {{{
 {% if task.status == TASK_STATUS_DONE %}
 ...
 {% else if task.status == TASK_STATUS_ERROR or task.status ==
 TASK_STATUS_ABORTED %}
 ...
 {% endif %}
 }}}

 then the following error without any message emerges:

 {{{
 AssertionError at /wizard/tasks/1/summary
 No exception message supplied

 Environment:

 Request Method: GET
 Request URL: http://127.0.0.1:20090/wizard/tasks/1/summary

 Django Version: 1.8.13
 Python Version: 3.4.3
 Installed Applications:
 ('django.contrib.admin',
  'django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  'rest_framework',
  'bootstrap3',
  'djkombu',
   ...)
 Installed Middleware:
 ('django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.common.CommonMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  'django.middleware.clickjacking.XFrameOptionsMiddleware',
  'django.middleware.security.SecurityMiddleware',
  'viking.middleware.LoginRequiredMiddleware')


 Traceback:
 File "/usr/local/lib/python3.4/dist-packages/django/core/handlers/base.py"
 in get_response
   132. response = wrapped_callback(request,
 *callback_args, **callback_kwargs)
 File "/usr/local/lib/python3.4/dist-
 packages/django/views/decorators/csrf.py" in wrapped_view
   58. return view_func(*args, **kwargs)
 File "/usr/local/lib/python3.4/dist-packages/django/views/generic/base.py"
 in view
   71. return self.dispatch(request, *args, **kwargs)
 File "/usr/local/lib/python3.4/dist-packages/rest_framework/views.py" in
 dispatch
   466. response = self.handle_exception(exc)
 File "/usr/local/lib/python3.4/dist-packages/rest_framework/views.py" in
 dispatch
   463. response = handler(request, *args, **kwargs)
 File "/usr/local/lib/python3.4/dist-packages/rest_framework/decorators.py"
 in handler
   53. return func(*args, **kwargs)
 File "/www/deploy/apps/wizard/views.py" in task_id_step
   156. return render_to_response( "wizard/step_summary.html",
 template_data )
 File "/usr/local/lib/python3.4/dist-packages/django/shortcuts.py" in
 render_to_response
   39. content = loader.render_to_string(template_name, context,
 using=using)
 File "/usr/local/lib/python3.4/dist-packages/django/template/loader.py" in
 render_to_string
   98. template = get_template(template_name, using=using)
 File "/usr/local/lib/python3.4/dist-packages/django/template/loader.py" in
 get_template
   35. return engine.get_template(template_name, dirs)
 File "/usr/local/lib/python3.4/dist-
 packages/django/template/backends/django.py" in get_template
   30. return Template(self.engine.get_template(template_name,
 dirs))
 File "/usr/local/lib/python3.4/dist-packages/django/template/engine.py" in
 get_template
   167. template, origin = self.find_template(template_name, dirs)
 File "/usr/local/lib/python3.4/dist-packages/django/template/engine.py" in
 find_template
   141. source, display_name = loader(name, dirs)
 File "/usr/local/lib/python3.4/dist-
 packages/django/template/loaders/base.py" in __call__
   13. return self.load_template(template_name, template_dirs)
 File "/usr/local/lib/python3.4/dist-
 packages/django/template/loaders/base.py" in load_template
   23. template = Template(source, origin, template_name,
 self.engine)
 File "/usr/local/lib/python3.4/dist-packages/django/template/base.py" in
 __init__
   191. self.nodelist = engine.compile_string(template_string,
 origin)
 File "/usr/local/lib/python3.4/dist-packages/django/template/engine.py" in
 compile_string
   261. return parser.parse()
 File "/usr/local/lib/python3.4/dist-packages/django/template/base.py" in
 parse
   342. compiled_result = compile_func(self, token)
 File "/usr/local/lib/python3.4/dist-
 packages/django/template/loader_tags.py" in do_extends
   210. nodelist = parser.parse()
 File

[Django] #26572: AdminEmailHandler fails to honor subject length limit

2016-05-03 Thread Django

#26572: AdminEmailHandler fails to honor subject length limit
---+
 Reporter:  pdewacht   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 AdminEmailHandler.format_subject() is careful to stay under the 998
 character limit of RFC 2822:

 Escape CR and LF characters, and limit length.
 RFC 2822's hard limit is 998 characters per line. So, minus
 "Subject: "
 the actual subject must be no longer than 989 characters.

 However, it forgets that the mail_admins function will prepend
 EMAIL_SUBJECT_PREFIX. After that's done, the subject line will again
 exceed to RFC limit.

 Either the truncation needs to be moved to a lower level in the mail
 system, or format_subject needs to be adjusted to account for
 EMAIL_SUBJECT_PREFIX.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.cbe85ec7ecbf4e8925ad4117f9a332d6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26571: Documentation about usage of fromtimestamp (wrt timezones) is confusing

2016-05-03 Thread Django

#26571: Documentation about usage of fromtimestamp (wrt timezones) is confusing
--+
 Reporter:  bronger   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.9
 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 aaugustin):

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


Comment:

 Indeed, I wasn't aware of the optional second parameter to `fromtimestamp`
 when I wrote this note.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.89323481e63133cc765ac85b48fe2a20%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

44 matches

Mail list logo