date:20150703

Re: [Django] #25058: GenericRelation with related_query_name related instances not shown on delete confirmation page

2015-07-03 Thread Django

#25058: GenericRelation with related_query_name related instances not shown on
delete confirmation page
---+
 Reporter:  jmfederico |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I can reproduce the issue. For the regression test, we should be able to
 make some additions to the test added in
 d3d66d47222dd8765a20a15fdc754c0ed7635404.

--
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.bb4bfecb553939a78f5f0b4288e39de2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25061: Default template loader wrong in docs OR default loader not working properly

2015-07-03 Thread Django

#25061: Default template loader wrong in docs OR default loader not working
properly
-+-
 Reporter:  mlissner |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  loader, templates,   | Triage Stage:
  defaults   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by mlissner):

 Yeah, I think it's safe to close this off. I thought that the old
 TEMPLATE_* settings were mapped more or less directly to the new OPTIONS
 key...missed that it's {} by default.

 End of day Friday. Apologies.

--
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.da763bea335d39ad8bd0c24fbd556c4e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25061: Default template loader wrong in docs OR default loader not working properly

2015-07-03 Thread Django

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

Comment:

As best I can figure out, OP is either referring to what you linked, or to
the mention of "the default value of TEMPLATE_LOADERS" in
https://docs.djangoproject.com/en/1.8/ref/templates/upgrading/#the-
templates-settings

Both of those are referring to the default value of `TEMPLATE_LOADERS`
pre-1.8. The default value of `['OPTIONS']['loaders']` for Django Template
Language in 1.8 is more complex; it only includes the `app_directories`
loader if you set `APP_DIRS: True`, as documented in the TEMPLATES setting
docs: https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-
TEMPLATES

I would assume the OP isn't setting `APP_DIRS: True`. It defaults to
`False`, though the startproject default settings file sets it to `True`.

But it sounds like OP also has a polluted installation of 1.8 which is
somehow still using an old project template. Django 1.8 startproject
template definitely uses `TEMPLATES`, not `TEMPLATE_*`.

--
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.2aa8f55ae57b8b79d2c2e3d9a931d44d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25061: Default template loader wrong in docs OR default loader not working properly

2015-07-03 Thread Django

#25061: Default template loader wrong in docs OR default loader not working
properly
-+-
 Reporter:  mlissner |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  loader, templates,   | Triage Stage:
  defaults   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Which docs are you referring to regarding the template loaders defaults?
 Is it from the [https://docs.djangoproject.com/en/dev/ref/settings
 /#template-loaders TEMPLATE_LOADERS] setting? If so, I think the confusion
 is that once you define the `TEMPLATES` setting, the old `TEMPLATE_`
 settings are ignored.

--
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.a805b9d4f50616c5123ffa4f7d3b71d5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25061: Default template loader wrong in docs OR default loader not working properly

2015-07-03 Thread Django

#25061: Default template loader wrong in docs OR default loader not working
properly
-+-
Reporter: mlissner | Owner: nobody
Type: Bug | Status: new
Component: Template system |Version: 1.8
Severity: Normal | Keywords: loader, templates, defaults
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 1| UI/UX: 0
-+-
Not sure if the docs are correct or if the functionality is incorrect. In
any case, the docs say that in Django 1.8, the default template loaders
are:

('django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader')

The error I ran into was that when I had the TEMPLATES variable set,
Django could not find the templates from the debug toolbar, which made me
think that the app_directories loader wasn't working.

I did three tests:

First, I added the above tuple to the TEMPLATES directory to see if the
default wasn't being set correctly. When I added the values above,
suddenly the template was found successfully.

Second, I created a brand new project in a brand new virtualenv. In the
env I installed django_debug_toolbar and django 1.8.2. I then added
debug_toolbar to the installed apps, and tested if runserver could find
the templates it needed to. Sure enough, this worked.

Third, when that worked, I noticed that the default settings for Django
1.8.2 still use the TEMPLATE_ format. This seems odd (perhaps an indicator
that my system wasn't clean?) but I swapped the settings over to use the
TEMPLATES variable instead. Again, when 'loaders' is unset, the template
can't be found, but when it is set to the supposed default value, things
work fine.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To 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.8e48cc7a539902faf8d8241fca8dfe8c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25060: Add support for str(timedelta) representation in parse_duration

2015-07-03 Thread Django

#25060: Add support for str(timedelta) representation in parse_duration
-+--
 Reporter:  vmspike  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Utilities|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by timgraham):

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


Comment:

 Can you elaborate on your use case a bit?

 `parse_duration()` is currently the inverse of
 `django.utils.duration.duration_string()` which is not English specific.
 Maybe you can use that function instead of `str()`.

--
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.461077a00085ac3acb66ef9797afc78a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24375: Add ability to mark migration as "part of initial" in Migration

2015-07-03 Thread Django

#24375: Add ability to mark migration as "part of initial" in Migration
-+-
 Reporter:  haeric   |Owner:  akulakov
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  fake migrations  | 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/064.45f9dce3c2b4fcf450c2d79aced5088e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25059: URLValidator does not pass some valid IDN top-level domans

2015-07-03 Thread Django

#25059: URLValidator does not pass some valid IDN top-level domans
---+
 Reporter:  alexey-sveshnikov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.8
 Severity:  Release blocker|   Resolution:
 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 bmispelon):

 For reference, the commit that introduced the regression is
 2e65d56156b622e2393dee1af66e9c799a51924f.

--
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/075.54203c35cd37cb57b7fc31f7dbefcc04%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25060: Add support for str(timedelta) representation in parse_duration

2015-07-03 Thread Django

#25060: Add support for str(timedelta) representation in parse_duration
-+
 Reporter:  vmspike  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Utilities|Version:  1.8
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  1|  UI/UX:  0
-+
 It's useful for conversions to/from str, so we can convert timedelta value
 to str and back without additional work.
 The following code can be used instead of original parse_duration function
 {{{
 # Support str(timedelta) format
 str_timedelta_duration_re = re.compile(
 r'^'
 r'(?:(?P-?\d+) days*, )?'
 r'((?:(?P\d+):)(?=\d+:\d+))?'
 r'(?:(?P\d+):)?'
 r'(?P\d+)'
 r'(?:\.(?P\d{1,6})\d{0,6})?'
 r'$'
 )

 def parse_duration(value):
 """Parses a duration string and returns a datetime.timedelta.

 The preferred format for durations in Django is '%d %H:%M:%S.%f'.

 Also supports ISO 8601 and str(timedelta) representations.
 """
 for duration_re in (standard_duration_re, iso8601_duration_re,
 str_timedelta_duration_re):
 match = duration_re.match(value)
 if match:
 kw = match.groupdict()
 if kw.get('microseconds'):
 kw['microseconds'] = kw['microseconds'].ljust(6, '0')
 kw = {k: float(v) for k, v in six.iteritems(kw) if v is not
 None}
 return datetime.timedelta(**kw)
 }}}

--
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/050.c0f49b90b8203f25754675853040c1ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25059: URLValidator does not pass some valid IDN top-level domans

2015-07-03 Thread Django

#25059: URLValidator does not pass some valid IDN top-level domans
---+
 Reporter:  alexey-sveshnikov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.8
 Severity:  Normal |   Resolution:
 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 timgraham):

 * 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/075.5a6a75f950da4ad3b3bb575cf1623f30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25059: URLValidator does not pass some valid IDN top-level domans

2015-07-03 Thread Django

#25059: URLValidator does not pass some valid IDN top-level domans
---+
 Reporter:  alexey-sveshnikov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.8
 Severity:  Release blocker|   Resolution:
 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 timgraham):

 * severity:  Normal => Release blocker


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/075.131255fc9fbba9b9b9221a269ae66f07%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25047: "Conflicting migrations detected" error in makemigrations is rather unhelpful

2015-07-03 Thread Django

#25047: "Conflicting migrations detected" error in makemigrations is rather
unhelpful
--+
 Reporter:  nip3o |Owner:  mossplix
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by mossplix):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.705764b8d415a389f035d9769396053a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22990: Sensitive POST data leaks from complex variables

2015-07-03 Thread Django

#22990: Sensitive POST data leaks from complex variables
--+
 Reporter:  vzima |Owner:  vzima
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_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 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.17de810de1004a392c2b81f44f5475b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9061: formsets with can_delete=True shouldn't add delete field to extra forms

2015-07-03 Thread Django

#9061: formsets with can_delete=True shouldn't add delete field to extra forms
-+--
 Reporter:  gsf  |Owner:  danielward
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left comments for improvement on the 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/061.783696798ebbd6c42144542ec67f2cce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25059: URLValidator does not pass some valid IDN top-level domans

2015-07-03 Thread Django

#25059: URLValidator does not pass some valid IDN top-level domans
---+--
 Reporter:  alexey-sveshnikov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by alexey-sveshnikov):

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


Old description:

> There are some valid IDN top level domains with dashes which is not
> validated by URLValidator.
>
> One example is '.xn--p1ai' which is punycode-encoded '.рф' (IDN TLD for
> Russian Federation)
>
> This is a regression since 1.7.x
>
> (I'm going to post pull request when I get ticket number)

New description:

 There are some valid IDN top level domains with dashes which is not
 validated by URLValidator.

 One example is '.xn--p1ai' which is punycode-encoded '.рф' (IDN TLD for
 Russian Federation)

 This is a regression since 1.7.x

 Pull request: https://github.com/django/django/pull/4949

--

--
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/075.04bc19a243677ecb4ad17b4f2dca9b03%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25059: URLValidator does not pass some valid IDN top-level domans

2015-07-03 Thread Django

#25059: URLValidator does not pass some valid IDN top-level domans
---+
 Reporter:  alexey-sveshnikov  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Core (Other)   |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 There are some valid IDN top level domains with dashes which is not
 validated by URLValidator.

 One example is '.xn--p1ai' which is punycode-encoded '.рф' (IDN TLD for
 Russian Federation)

 This is a regression since 1.7.x

 (I'm going to post pull request when I get ticket number)

--
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/060.1e3c3bfb23b48ff8a1cca4cc83fd8100%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24877: Exceptions in renderizable responses are not handled by Middleware's `process_exception()`

2015-07-03 Thread Django

#24877: Exceptions in renderizable responses are not handled by Middleware's
`process_exception()`
---+
 Reporter:  Kronuz |Owner:  sephii
 Type:  New feature|   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
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f5d5867a4a6aeddd58ff855a01ab4e438d938ac1" f5d5867a]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5d5867a4a6aeddd58ff855a01ab4e438d938ac1"
 Fixed #24877 -- Added middleware handling of response.render() errors.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.34a5863e43832a55b93056ec44956bbb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24782: Add TestCase.assertFormValid

2015-07-03 Thread Django

#24782: Add TestCase.assertFormValid
---+---
 Reporter:  mjtamlyn   |Owner:  delgiudices
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  forms  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by timgraham):

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


Comment:

 See [https://github.com/django/django/pull/4645#issuecomment-107254019
 comment from Marc on the pull request] for methods to be 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/066.1a9a60102fe0fa254438a68d0eab55c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24375: Add ability to mark migration as "part of initial" in Migration

2015-07-03 Thread Django

#24375: Add ability to mark migration as "part of initial" in Migration
-+
 Reporter:  haeric   |Owner:  akulakov
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  fake migrations  | 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):

 * 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/064.519523960aa09fc5d614d75a29421e0f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23190: Make paginator.page_range an iterator.

2015-07-03 Thread Django

#23190: Make paginator.page_range an iterator.
--+
 Reporter:  CollinAnderson|Owner:  zedr
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"b91a2a499fd562011fd275238924baa6002fb1f8" b91a2a4]:
 {{{
 #!CommitTicketReference repository=""
 revision="b91a2a499fd562011fd275238924baa6002fb1f8"
 Fixed #23190 -- Made Paginator.page_range an iterator
 }}}

--
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/072.23569260023b8c095b4fca65ff445382%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25055: Test invalid_models_tests.test_models.FieldNamesTests.test_M2M_long_column_name fails for backends that support very long names

2015-07-03 Thread Django

#25055: Test
invalid_models_tests.test_models.FieldNamesTests.test_M2M_long_column_name
fails for backends that support very long names
---+
 Reporter:  manfre |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.8
 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:"342074f4a434a38d1b3a569e517ba9f1ce6ed946" 342074f4]:
 {{{
 #!CommitTicketReference repository=""
 revision="342074f4a434a38d1b3a569e517ba9f1ce6ed946"
 [1.8.x] Fixed #25055 -- Made m2m long name testing friendlier for 3rd
 party databases.

 Backport of f9c3587b51487179cf3fb92b509790f4610d6012 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/064.4345cc30a6b76ea5225f96d6df2ac23e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25055: Test invalid_models_tests.test_models.FieldNamesTests.test_M2M_long_column_name fails for backends that support very long names

2015-07-03 Thread Django

#25055: Test
invalid_models_tests.test_models.FieldNamesTests.test_M2M_long_column_name
fails for backends that support very long names
---+
 Reporter:  manfre |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f9c3587b51487179cf3fb92b509790f4610d6012" f9c3587]:
 {{{
 #!CommitTicketReference repository=""
 revision="f9c3587b51487179cf3fb92b509790f4610d6012"
 Fixed #25055 -- Made m2m long name testing friendlier for 3rd party
 databases.
 }}}

--
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.b7203f025c71455f6c39561c8d100454%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ after POST, and only then 302 /admin/

2015-07-03 Thread Django

#25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ 
after
POST, and only then 302 /admin/
--+
 Reporter:  adelton   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"335368410210ce0e27e0068b3a2a6cdf4baa956b" 3353684]:
 {{{
 #!CommitTicketReference repository=""
 revision="335368410210ce0e27e0068b3a2a6cdf4baa956b"
 Fixed #25032 -- Removed double redirect in admin login.
 }}}

--
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.100973a550fffce250b3429749f8cf83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25058: GenericRelation with related_query_name related instances not shown on delete confirmation page

2015-07-03 Thread Django

#25058: GenericRelation with related_query_name related instances not shown on
delete confirmation page
---+
 Reporter:  jmfederico |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.8
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  1  |
---+
Changes (by jmfederico):

 * Attachment "Screen Shot 2015-07-03 at 7.31.41.png" 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/068.db243ad78e24a38950eaa4c94b38%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25058: GenericRelation with related_query_name related instances not shown on delete confirmation page

2015-07-03 Thread Django

#25058: GenericRelation with related_query_name related instances not shown on
delete confirmation page
---+
 Reporter:  jmfederico |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  1
---+
 When deleting an object with a GenericRelation and related_query_name, the
 related instances are not shown on the confirmation page.

 Instances are actually deleted and the confirmation page show the correct
 count of related instances to be deleted.

 Related to #24940, which fixes an issue where it wasn't possible to delete
 the instances.

--
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.163e466b0c77327993f3c1f15493aad9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25056: Tests fails when using Jinja2 2.6

2015-07-03 Thread Django

#25056: Tests fails when using Jinja2 2.6
---+
 Reporter:  vzima  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"cb3e9bc0d7b23c39ee6fe78589cfc9975baa8c92" cb3e9bc]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb3e9bc0d7b23c39ee6fe78589cfc9975baa8c92"
 [1.8.x] Fixed #25056 -- Documented minimum version of jinja2 for testing.

 Backport of ca58181bac5366d3a1fb44e1b49fe9e365095138 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/063.6771b10bf6b6010a0be562cf8d9eeeda%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25056: Tests fails when using Jinja2 2.6

2015-07-03 Thread Django

#25056: Tests fails when using Jinja2 2.6
---+
 Reporter:  vzima  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ca58181bac5366d3a1fb44e1b49fe9e365095138" ca58181]:
 {{{
 #!CommitTicketReference repository=""
 revision="ca58181bac5366d3a1fb44e1b49fe9e365095138"
 Fixed #25056 -- Documented minimum version of jinja2 for testing.
 }}}

--
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.d069922316b14c9ca2791048f577bcbe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25050: When the default manager returns a queryset with a deferred field, the dumpdata command fails to produce importable data.

2015-07-03 Thread Django

#25050: When the default manager returns a queryset with a deferred field, the
dumpdata command fails to produce importable data.
-+-
 Reporter:  cecedille1   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  1.8
  (Serialization)|
 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:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"c0c7fa4837c85bc510462f0be3882c6220dce728" c0c7fa48]:
 {{{
 #!CommitTicketReference repository=""
 revision="c0c7fa4837c85bc510462f0be3882c6220dce728"
 Refs #25050 -- Corrected test assertion in serializers test.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.9b4ae7432abcda9603f41444393fd600%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25057: Permission for view (CRUD) and correct handling of inactive users for business applications

2015-07-03 Thread Django

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

Comment:

Thanks for the suggestions.

The request for a "view" permission is a duplicate of #820 which was
closed as "won't fix". If you want to reopen the discussion, please write
to the DevelopersMailingList.

I don't find your proposal for permissions checking compelling because
these ideas can be implemented with a custom user model. That seems more
elegant that requiring an application to pass `check_active=False`
everywhere it does permission checks. Also, the default `ModelBackend`

[https://github.com/django/django/blob/a570701e02e0bc09d977c8ae0b6ee987a1190039/django/contrib/auth/backends.py#L33-L40
doesn't return any permissions for inactive users] so that would need to
be overridden as well.

For future reference, please keep a ticket focused on one 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 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.0b87f6da4df363be645f6a41a20a1a2a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22990: Sensitive POST data leaks from complex variables

2015-07-03 Thread Django

#22990: Sensitive POST data leaks from complex variables
--+
 Reporter:  vzima |Owner:  vzima
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by vzima):

 * 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/063.f977265984534b46d55fc6790c360169%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22990: Sensitive POST data leaks from complex variables

2015-07-03 Thread Django

#22990: Sensitive POST data leaks from complex variables
--+
 Reporter:  vzima |Owner:  vzima
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by vzima):

 * owner:  auvipy => vzima


Comment:

 Finally I had a bit of time to update the patch. It is in new PR
 https://github.com/django/django/pull/4947.

--
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.0a47a53965db13f46388734309f2b264%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25056: Tests fails when using Jinja2 2.6

2015-07-03 Thread Django

#25056: Tests fails when using Jinja2 2.6
---+
 Reporter:  vzima  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.8
 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_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Template system => Documentation
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Indeed, we should document the minimum required version of Jinja2 for
 running Django's own tests in
 https://docs.djangoproject.com/en/1.8/internals/contributing/writing-code
 /unit-tests/#running-all-the-tests.

 That only affects Django's own test suite. You can use older versions of
 Jinja2 with Django in general, provided you don't use options added in
 newer versions.

--
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.2e61109d3a652e75cefd334a0ca2a260%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ after POST, and only then 302 /admin/

2015-07-03 Thread Django

#25032: When /admin/login/ is accessed directly, there is 302 /admin/login/ 
after
POST, and only then 302 /admin/
--+
 Reporter:  adelton   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by adelton):

 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.f33781bf02fa887f33321eed2c7674c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25057: Permission for view (CRUD) and correct handling of inactive users for business applications

2015-07-03 Thread Django

#25057: Permission for view (CRUD) and correct handling of inactive users for
business applications
-+-
 Reporter:  djbaldey |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  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 djbaldey):

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


Old description:

> Our framework is beautiful, it is convenient to make sites, but not
> business applications.
> You have to write a lot of code and/or wrappers to do elementary things,
> in order not to lose performance.
> The most striking problem: when you need in a single view to decide what
> data to display, depending on which groups the user belongs to.
> For example, a simple task:
>

> {{{
> def dash(request):
> ctx = {}
> user = request.user
>
> if not user.has_module_perms('myadminapp'):
> return HttpResponseForbidden()
>
> if user.has_perm('auth.view_group'):
> ctx['groups'] = Group.objects.all()
> if user.has_perm('auth.view_permission'):
> ctx['permissions'] = Permissions.objects.all()
> if user.has_perm('auth.view_user'):
> ctx['users'] = User.objects.all()
>
> # Also the external applications to which you cannot add custom
> permissions:
> if user.has_perm('partner.view_supplier'):
> ctx['suppliers'] = Supplier.objects.all()
> if user.has_perm('partner.view_org'):
> ctx['orgs'] = Org.objects.all()
> if user.has_perm('partner.view_address'):
> ctx['addresses'] = Address.objects.all()
> if user.has_perm('order.view_summaryorder'):
> ctx['summary_orders'] = SummaryOrder.objects.all()
> if user.has_perm('order.view_customorder'):
> ctx['custom_orders'] = CustomOrder.objects.all()
> if user.has_perm('order.view_document'):
> ctx['docs'] = Document.objects.all()
> ...
> # 0 additional requests in database
> }}}
>

> Today turns into:
>
> {{{
> def dash(request):
> ctx = {}
> user = request.user
>
> if not user.has_module_perms('myadminapp') or not user.is_active:
> return HttpResponseForbidden()
>
> if user.groups.filter(name='Has view groups').count():
> ctx['groups'] = Group.objects.all()
> if user.groups.filter(name='Has view permissions').count():
> ctx['permissions'] = Permissions.objects.all()
> if user.groups.filter(name='Has view users').count():
> ctx['users'] = User.objects.all()
>
> # Also the external applications to which you cannot add custom
> permissions:
> if user.groups.filter(name='Has view suppliers').count():
> ctx['suppliers'] = Supplier.objects.all()
> if user.groups.filter(name='Has view orgs').count():
> ctx['orgs'] = Org.objects.all()
> if user.groups.filter(name='Has view addresses').count():
> ctx['addresses'] = Address.objects.all()
> if user.groups.filter(name='Has view summary orders').count():
> ctx['summary_orders'] = SummaryOrder.objects.all()
> if user.groups.filter(name='Has view custom orders').count():
> ctx['custom_orders'] = CustomOrder.objects.all()
> if user.groups.filter(name='Has view documents').count():
> ctx['docs'] = Document.objects.all()
> ...
> # +9 additional requests in database
> }}}
>
> Or add to the database by hand after installing the apps.
> But if someone of the admins accidentally rename a group? The horror!
> For large and complex applications permission to view inside framework
> the only decent solution.
>
> While all of this madness can be reduced to two simple solutions.
>
> 1. Set four default permissions in
> db.models.options.Options.default_permissions = ('view', 'add', 'change',
> 'delete'). Also, would the names of the permission form on the language
> set in settings.LANGUAGE_CODE. It's a matter of principle any
> "perfectionist".
> 2. Inactive user should not have any permissions. Now has. For
> exceptional cases of inactive user should be a special parameter for the
> function that changes its behavior.
>
> I have three patches for master branch and and can do for stable/1.8.x. I
> think these changes will not affect existing projects, because the
> permissions have already been recorded in the database during the
> migration and shall not affect the administrative interfa

Re: [Django] #25057: Permission for view (CRUD) and correct handling of inactive users for business applications

2015-07-03 Thread Django

#25057: Permission for view (CRUD) and correct handling of inactive users for
business applications
--+
 Reporter:  djbaldey  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by djbaldey):

 * Attachment "25057_permission_for_view_without_locales.diff" 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/066.74f54d00e289188328e4bf3d3743743e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25057: Permission for view (CRUD) and correct handling of inactive users for business applications

2015-07-03 Thread Django

#25057: Permission for view (CRUD) and correct handling of inactive users for
business applications
--+
 Reporter:  djbaldey  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by djbaldey):

 * Attachment "25057_permission_for_view_with_locales.diff" 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/066.052d3823ce0fbb6602574152a4b40d23%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25057: Permission for view (CRUD) and correct handling of inactive users for business applications

2015-07-03 Thread Django

#25057: Permission for view (CRUD) and correct handling of inactive users for
business applications
--+
 Reporter:  djbaldey  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by djbaldey):

 * Attachment "25057_inactive_user.diff" 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/066.ca9892ae97025f8eaae97c6f717613f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25057: Permission for view (CRUD) and correct handling of inactive users for business applications

2015-07-03 Thread Django

#25057: Permission for view (CRUD) and correct handling of inactive users for
business applications
--+
 Reporter:  djbaldey  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Our framework is beautiful, it is convenient to make sites, but not
 business applications.
 You have to write a lot of code and/or wrappers to do elementary things,
 in order not to lose performance.
 The most striking problem: when you need in a single view to decide what
 data to display, depending on which groups the user belongs to.
 For example, a simple task:


 {{{
 def dash(request):
 ctx = {}
 user = request.user

 if not user.has_module_perms('myadminapp'):
 return HttpResponseForbidden()

 if user.has_perm('auth.view_group'):
 ctx['groups'] = Group.objects.all()
 if user.has_perm('auth.view_permission'):
 ctx['permissions'] = Permissions.objects.all()
 if user.has_perm('auth.view_user'):
 ctx['users'] = User.objects.all()

 # Also the external applications to which you cannot add custom
 permissions:
 if user.has_perm('partner.view_supplier'):
 ctx['suppliers'] = Supplier.objects.all()
 if user.has_perm('partner.view_org'):
 ctx['orgs'] = Org.objects.all()
 if user.has_perm('partner.view_address'):
 ctx['addresses'] = Address.objects.all()
 if user.has_perm('order.view_summaryorder'):
 ctx['summary_orders'] = SummaryOrder.objects.all()
 if user.has_perm('order.view_customorder'):
 ctx['custom_orders'] = CustomOrder.objects.all()
 if user.has_perm('order.view_document'):
 ctx['docs'] = Document.objects.all()
 ...
 # 0 additional requests in database
 }}}


 Today turns into:

 {{{
 def dash(request):
 ctx = {}
 user = request.user

 if not user.has_module_perms('myadminapp') or not user.is_active:
 return HttpResponseForbidden()

 if user.groups.filter(name='Has view groups').count():
 ctx['groups'] = Group.objects.all()
 if user.groups.filter(name='Has view permissions').count():
 ctx['permissions'] = Permissions.objects.all()
 if user.groups.filter(name='Has view users').count():
 ctx['users'] = User.objects.all()

 # Also the external applications to which you cannot add custom
 permissions:
 if user.groups.filter(name='Has view suppliers').count():
 ctx['suppliers'] = Supplier.objects.all()
 if user.groups.filter(name='Has view orgs').count():
 ctx['orgs'] = Org.objects.all()
 if user.groups.filter(name='Has view addresses').count():
 ctx['addresses'] = Address.objects.all()
 if user.groups.filter(name='Has view summary orders').count():
 ctx['summary_orders'] = SummaryOrder.objects.all()
 if user.groups.filter(name='Has view custom orders').count():
 ctx['custom_orders'] = CustomOrder.objects.all()
 if user.groups.filter(name='Has view documents').count():
 ctx['docs'] = Document.objects.all()
 ...
 # +9 additional requests in database
 }}}

 Or add to the database by hand after installing the apps.
 But if someone of the admins accidentally rename a group? The horror!
 For large and complex applications permission to view inside framework the
 only decent solution.

 While all of this madness can be reduced to two simple solutions.

 1. Set four default permissions in
 db.models.options.Options.default_permissions = ('view', 'add', 'change',
 'delete'). Also, would the names of the permission form on the language
 set in settings.LANGUAGE_CODE. It's a matter of principle any
 "perfectionist".
 2. Inactive user should not have any permissions. Now has. For exceptional
 cases of inactive user should be a special parameter for the function that
 changes its behavior.

 I have three patches for master branch and and can do for stable/1.8.x. I
 think these changes will not affect existing projects, because the
 permissions have already been recorded in the database during the
 migration and shall not affect the administrative interface.

 Each of the patches tested.

--
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://group

[Django] #25056: Tests fails when using Jinja2 2.6

2015-07-03 Thread Django

#25056: Tests fails when using Jinja2 2.6
-+
 Reporter:  vzima|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.8
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 When I run tests on master (hash a570701) 6 of them fails with the same
 error. Is seems Django does not work with Jinja 2.6, but I found no
 minimal version required in documentation, so I expect 2.6 should work.
 Class `jinja2.Environment` does not have `keep_trailing_newline` argument
 in version 2.6.

 Example traceback
 {{{
 ==
 ERROR: setUpClass (template_backends.test_jinja2.Jinja2Tests)
 --
 Traceback (most recent call last):
   File "/home/vlastimil/git/django/tests/template_backends/test_dummy.py",
 line 28, in setUpClass
 cls.engine = cls.engine_class(params)
   File "/home/vlastimil/git/django/django/template/backends/jinja2.py",
 line 35, in __init__
 self.env = environment_cls(**options)
 TypeError: __init__() got an unexpected keyword argument
 'keep_trailing_newline'
 }}}

--
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/048.9ac4c550df7870a0234a3ae69c215439%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

39 matches

Mail list logo