date:20151210

Re: [Django] #25912: Add binary left/right shift operators to F expressions

2015-12-10 Thread Django

#25912: Add binary left/right shift operators to F expressions
-+-
 Reporter:  anabelensc   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 We could also add this as normal expression.

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

Re: [Django] #25916: New Feature: Add lastmod support to sitemapindex

2015-12-10 Thread Django

#25916: New Feature: Add lastmod support to sitemapindex
--+--
 Reporter:  mgd020|Owner:  mgd020
 Type:  New feature   |   Status:  assigned
Component:  contrib.sitemaps  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  sitemap lastmod   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by mgd020:

Old description:

> Add support for `` for generated ``

New description:

 Add support for `` for generated ``

 https://github.com/django/django/pull/5814

--

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

Re: [Django] #24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it

2015-12-10 Thread Django

#24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it
-+-
 Reporter:  ssjunior |Owner:  ssjunior
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by shaib):

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


Comment:

 We only mark tickets fixed when the PR has been merged.

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

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

Re: [Django] #24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it

2015-12-10 Thread Django

#24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it
-+-
 Reporter:  ssjunior |Owner:  ssjunior
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by stewartpark):

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

Re: [Django] #24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it

2015-12-10 Thread Django

#24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it
-+-
 Reporter:  ssjunior |Owner:  ssjunior
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by stewartpark):

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


Comment:

 https://github.com/django/django/pull/5794

 I made a new pull request for this issue. Added testing as well.

 Can you check if it looks good?

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

Re: [Django] #25916: New Feature: Add lastmod support to sitemapindex

2015-12-10 Thread Django

#25916: New Feature: Add lastmod support to sitemapindex
--+--
 Reporter:  mgd020|Owner:  mgd020
 Type:  New feature   |   Status:  assigned
Component:  contrib.sitemaps  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  sitemap lastmod   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by mgd020):

 * type:  Uncategorized => 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/064.e493894b4352ac46d41f2977eba5a585%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25916: New Feature: Add lastmod support to sitemapindex

2015-12-10 Thread Django

#25916: New Feature: Add lastmod support to sitemapindex
--+--
 Reporter:  mgd020|Owner:  mgd020
 Type:  Uncategorized |   Status:  assigned
Component:  contrib.sitemaps  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  sitemap lastmod   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by mgd020):

 * owner:   => mgd020
 * needs_better_patch:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #25916: New Feature: Add lastmod support to sitemapindex

2015-12-10 Thread Django

#25916: New Feature: Add lastmod support to sitemapindex
--+-
 Reporter:  mgd020|  Owner:
 Type:  Uncategorized | Status:  new
Component:  contrib.sitemaps  |Version:  master
 Severity:  Normal|   Keywords:  sitemap lastmod
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Add support for `` for generated ``

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

[Django] #25915: Error when using a language that Django doesn't ship translations for

2015-12-10 Thread Django

#25915: Error when using a language that Django doesn't ship translations for
--+
 Reporter:  gavinwahl |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Internationalization  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I am trying to add translations for a new language (that Django doesn't
 support) to my project. Let's say it has the language code `xxx` for
 example.

 I make the .po file with

 {{{
 ./manage.py makemessages -l xxx
 }}}

 Then I translate the po file and compile it. When I set `LANGUAGE_CODE =
 'xxx'` and run runserver, Django fails with:


 {{{
 Traceback (most recent call last):
   File "./manage.py", line 13, in 
 execute_from_command_line(sys.argv)
   File "django/core/management/__init__.py", line 350, in
 execute_from_command_line
 utility.execute()
   File "django/core/management/__init__.py", line 324, in execute
 django.setup()
   File "django/__init__.py", line 18, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "django/apps/registry.py", line 108, in populate
 app_config.import_models(all_models)
   File "django/apps/config.py", line 202, in import_models
 self.models_module = import_module(models_module_name)
   File "it__.py", line 109, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 2254, in _gcd_import
   File "", line 2237, in _find_and_load
   File "", line 2226, in
 _find_and_load_unlocked
   File "", line 1200, in _load_unlocked
   File "", line 1129, in _exec
   File "", line 1471, in exec_module
   File "", line 321, in
 _call_with_frames_removed
   File "foo/models.py", line 381, in 
 MinLengthValidator(22, _("This value must be at least 22 digits.")),
   File "django/core/validators.py", line 297, in __init__
 if message:
   File "django/utils/functional.py", line 109, in __wrapper__
 res = func(*self.__args, **self.__kw)
   File "django/utils/translation/__init__.py", line 85, in ugettext
 return _trans.ugettext(message)
   File "django/utils/translation/trans_real.py", line 313, in gettext
 return do_translate(message, 'gettext')
   File "django/utils/translation/trans_real.py", line 296, in do_translate
 _default = _default or translation(settings.LANGUAGE_CODE)
   File "django/utils/translation/trans_real.py", line 203, in translation
 _translations[language] = DjangoTranslation(language)
   File "django/utils/translation/trans_real.py", line 112, in __init__
 self._init_translation_catalog()
   File "django/utils/translation/trans_real.py", line 150, in
 _init_translation_catalog
 translation = self._new_gnu_trans(localedir, use_null_fallback)
   File "django/utils/translation/trans_real.py", line 133, in
 _new_gnu_trans
 fallback=use_null_fallback)
   File "/usr/lib/python3.4/gettext.py", line 419, in translation
 raise OSError(ENOENT, 'No translation file found for domain', domain)
 FileNotFoundError: [Errno 2] No translation file found for domain:
 'django'
 }}}


 It seems that this errors happens whenever you try to use a language that
 doesn't have a django.po shipped with django (in `django/conf/locale/`).
 Shouldn't I be able to provide the translations just in my project?

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

Re: [Django] #25914: order_by not consistently returning data in specified order

2015-12-10 Thread Django

#25914: order_by not consistently returning data in specified order
-+-
 Reporter:  shmkrause|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Could you provide a test case for Django's test suite or at least a sample
 project that reproduces the behavior? We don't know what the model looks
 like or what database you're using. Thanks!

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

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

Re: [Django] #25893: Custom Lookups & Transform example lhs/rhs swap

2015-12-10 Thread Django

#25893: Custom Lookups & Transform example lhs/rhs swap
-+-
 Reporter:  browniebroke |Owner:
 Type:   |  browniebroke
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5791 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/070.8ccabdfe8da157466d24b99daf8ad205%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25914: order_by not consistently returning data in specified order

2015-12-10 Thread Django

#25914: order_by not consistently returning data in specified order
--+
Reporter: shmkrause | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) |Version: 1.8
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
When ordering model records by timestamp and slicing, where the start
parameter has not been specified, the query does not pull data in the
order specified.

To be more specific, the code I have is:
data = MyModel.objects.order_by('-timestamp')[:100]

Output ordering is not consistent; expected data should all be from today
(December 10, 2015), but data returned is stamped either December 1, 2015
or December 10, 2015. There is no discernible pattern as to when data
from the first and the tenth is given.

Note that adding the start parameter for the slice stops this behaviour
from occurring.

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

Re: [Django] #25912: Add binary left/right shift operators to F expressions

2015-12-10 Thread Django

#25912: Add binary left/right shift operators to F expressions
-+-
 Reporter:  anabelensc   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 There's a slight problem here that we'll probably need to take to the
 mailing list. Oracle (surprise surprise) is the only supported database
 that does *not* have a bitshift operator. It doesn't even have a bitshift
 function that I can find.

 We'll need to decide whether we want to leave a backend behind
 (NotSupportedError or whatever..), figure out a way to support bit
 shifting by doing the actual math (bitshift by doing [*/] 2**X) in an
 as_oracle method, or abandon the idea of supporting bitshifting in django
 core and using a library to implement some monkey patching.

 My preferences here are 2 (do the math for oracle), 3 (leave it out), 1
 (no support). Doing the math will result in some overhead (a super()
 method call) for every F() expression on oracle, whether or not you're
 doing bitshifting. Unsure if doing the math is actually equivalent in all
 cases or not though, so we'd need some more robust testing for corner
 cases.

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

Re: [Django] #25883: Admin Delete Page Incorrectly Counts Related Objects

2015-12-10 Thread Django

#25883: Admin Delete Page Incorrectly Counts Related Objects
---+--
 Reporter:  jpulec |Owner:  sir-sigurd
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.9
 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:"515f149e4d51ddcf32db0be440da726c0ca867b4" 515f149e]:
 {{{
 #!CommitTicketReference repository=""
 revision="515f149e4d51ddcf32db0be440da726c0ca867b4"
 [1.9.x] Fixed #25883 -- Fixed admin deletion page summary counts for
 related objects.

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

Re: [Django] #25883: Admin Delete Page Incorrectly Counts Related Objects

2015-12-10 Thread Django

#25883: Admin Delete Page Incorrectly Counts Related Objects
---+--
 Reporter:  jpulec |Owner:  sir-sigurd
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.9
 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:"8ab58b80529c5206654c1042a4ddcf2da364f8ec" 8ab58b80]:
 {{{
 #!CommitTicketReference repository=""
 revision="8ab58b80529c5206654c1042a4ddcf2da364f8ec"
 Fixed #25883 -- Fixed admin deletion page summary counts for related
 objects.
 }}}

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

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

Re: [Django] #25905: Unsafe usage of urljoin() within FileStorageSystem

2015-12-10 Thread Django

#25905: Unsafe usage of urljoin() within FileStorageSystem
--+
 Reporter:  free-Runner   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  File uploads/storage  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  file, storage | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Description changed by free-Runner:

Old description:

> It may be possible to override the hostname when displaying a link to a
> static/media file with an attacker-controlled filename. The url() method
> in FileStorageSystem uses urljoin(base,url) to combine the base_url
> (typically STATIC_URL or MEDIA_URL) to the filename. The urljoin function
> has an edge case where if the url parameter starts with "//", the
> base_url value is overwritten. Thus, if an attacker can set the name
> variable of a FileStorageSystem instance to "//www.evil.com", any url
> method call on that instance will return an external link pointing to the
> attacker's site. Creating a file of the name "\\www.evil.com" is also
> acceptable as the filepath_to_uri function (that is called on the
> filename before the urljoin call) converts all backslashes to forward-
> slashes. The latter example works better as it is a completely valid
> Linux file name.
>
> This issue can't be exploited using framework-provided upload techniques
> (FileFields, ImageFields, etc) as they properly escape the filename.
> However, an application may directly initialize a FileStorageSystem using
> user-controlled data or allow users to modify the name attribute of an
> existing FileStorageSystem instance. In such cases, an attacker could
> convert the expected relative paths into absolute external URLs.
>
> This issue can simply be patched by modifying the line found
> here[https://github.com/django/django/blob/master/django/core/files/storage.py#L302]
> as follows:
>
> return urljoin(self.base_url,
> filepath_to_uri(get_valid_filename(name)))
>
> This change filters the filename provided through the get_valid_filename
> function from django.utils.text. This function does a sufficient job of
> eliminating the ability to override the base_url.
>
> Note: This issue was initially disclosed to the Django security team and
> was decided not to be treated as a security issue, but instead a bug.

New description:

 It may be possible to override the hostname when displaying a link to a
 static/media file with an attacker-controlled filename. The url() method
 in FileStorageSystem uses urljoin(base,url) to combine the base_url
 (typically STATIC_URL or MEDIA_URL) to the filename. The urljoin function
 has an edge case where if the url parameter starts with {{{"//"}}}, the
 base_url value is overwritten. Thus, if an attacker can set the name
 variable of a FileStorageSystem instance to {{{"//www.evil.com"}}}, any
 url method call on that instance will return an external link pointing to
 the attacker's site. Creating a file of the name {{{"\\www.evil.com"}}} is
 also acceptable as the filepath_to_uri function (that is called on the
 filename before the urljoin call) converts all backslashes to forward-
 slashes. The latter example works better as it is a completely valid Linux
 file name.

 This issue can't be exploited using framework-provided upload techniques
 (FileFields, ImageFields, etc) as they properly escape the filename.
 However, an application may directly initialize a FileStorageSystem using
 user-controlled data or allow users to modify the name attribute of an
 existing FileStorageSystem instance. In such cases, an attacker could
 convert the expected relative paths into absolute external URLs.

 This issue can simply be patched by modifying the line found
 
here[https://github.com/django/django/blob/master/django/core/files/storage.py#L302]
 as follows:

   {{{return urljoin(self.base_url,
 filepath_to_uri(name).replace('//','/'))}}}

 This change filters the filename provided through the get_valid_filename
 function from django.utils.text. This function does a sufficient job of
 eliminating the ability to override the base_url.

 Note: This issue was initially disclosed to the Django security team and
 was decided not to be treated as a security issue, but instead a bug.

--

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

Re: [Django] #25873: GEOSGEometry handles srid parameter differently for EWKB and EWKT input

2015-12-10 Thread Django

#25873: GEOSGEometry handles srid parameter differently for EWKB and EWKT input
+--
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 Type:  Bug |   Status:  assigned
Component:  GIS |  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 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/068.fbc02c7ae085e7900d2b1d71bffddf36%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25874: allow GEOSGeometry to read SRID from GeoJSON input

2015-12-10 Thread Django

#25874: allow GEOSGeometry to read SRID from GeoJSON input
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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 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/068.ba75179732a7f5bcba42189e40b23524%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25913: --fake-initial not working with apps with other table names (was: --fake-migration not working with apps with other table names)

2015-12-10 Thread Django

#25913: --fake-initial not working with apps with other table names
---+--
 Reporter:  variable   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Could you please provide a `models.py` to reproduce the problem?

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

Re: [Django] #25912: Add binary left/right shift operators to F expressions (was: New feature Bitwise operators ( Binary Left Shift Operator and Binary Right Shift Operator))

2015-12-10 Thread Django

#25912: Add binary left/right shift operators to F expressions
-+-
 Reporter:  anabelensc   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * needs_docs:   => 1
 * has_patch:  0 => 1
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Seems reasonable. A mention in `topics/db/queries.txt` and the 1.10
 release notes are also needed. See the PatchReviewChecklist for tips. If
 you can provide the patch as a pull request, that's ideal for reviewing
 purposes.

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

Re: [Django] #25904: --fake-initial does not work for ManyToMany with through Model

2015-12-10 Thread Django

#25904: --fake-initial does not work for ManyToMany with through Model
-+
 Reporter:  maciej-pawlisz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 Severity:  Release blocker  |   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 timgraham):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks, I understand now. I'll have to look at the code a bit more to
 advise on the proper fix. For reference,
 db97a8849519a3933bf4abd2184efd68ebc21965 added the `Migration.initial`
 option.

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

[Django] #25913: --fake-migration not working with apps with other table names

2015-12-10 Thread Django

#25913: --fake-migration not working with apps with other table names
---+
 Reporter:  variable   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have the following migration step in "clients" app, notice the table
 name is "auth_client":

 {{{
 migrations.CreateModel(
 name='Client',
 fields=[
 ('id', models.AutoField(verbose_name='ID',
 serialize=False, auto_created=True, primary_key=True)),
 ('created_at', models.DateTimeField(auto_now_add=True,
 verbose_name='date created', db_index=True)),
 ('updated_at', models.DateTimeField(auto_now=True,
 verbose_name='date modified', db_index=True)),
 ('logo', models.FileField(null=True,
 upload_to=goconnect_client.clients.models.logo_path, blank=True)),
 ('name', models.CharField(max_length=255, blank=True)),
 ('client_id',
 
models.CharField(default=goconnect_client.clients.generators.generate_client_id,
 unique=True, max_length=100, db_index=True)),
 ('client_secret',
 
models.CharField(default=goconnect_client.clients.generators.generate_client_secret,
 max_length=255, db_index=True, blank=True)),
 ('client_type', models.CharField(max_length=32,
 choices=[('confidential', 'Confidential'), ('public', 'Public')])),
 ('authorization_grant_type',
 models.CharField(max_length=32, choices=[('authorization-code',
 'Authorization code'), ('implicit', 'Implicit'), ('password', 'Resource
 owner password-based'), ('client-credentials', 'Client credentials')])),
 ('skip_authorization',
 models.BooleanField(default=False)),
 ('redirect_uris', models.TextField(blank=True,
 validators=[goconnect_client.clients.validators.validate_uris])),
 ('cors', models.TextField(null=True, blank=True)),
 ('user', models.ForeignKey(related_name='clients_client',
 to=settings.AUTH_USER_MODEL)),
 ],
 options={
 'abstract': False,
 'db_table': 'auth_client',
 'swappable': 'AUTH_CLIENT_MODEL',
 },
 bases=(grabone_models.misc.timestampedmixin.TimeStampedMixin,
 models.Model),
 ),
 }}}

 When I run:

 {{{
 ./manage migrate clients --fake-initial
 }}}

 it complains about 'auth_client' table already exists.

 "When migrate is run with the --fake-initial option, these initial
 migrations are treated specially. For an initial migration that creates
 one or more tables (CreateModel operation), Django checks that all of
 those tables already exist in the database and fake-applies the migration
 if so. Similarly, for an initial migration that adds one or more fields
 (AddField operation), Django checks that all of the respective columns
 already exist in the database and fake-applies the migration if so.
 Without --fake-initial, initial migrations are treated no differently from
 any other migration."

 I am '''speculating''' that when determining the existence of the table
 it's using the default 'app_table' convention, and surely 'clients_client'
 table doesn't exist, but when running actual migration it uses
 'auth_client' as table name and encounter the error.

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

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

Re: [Django] #25412: Migrate command does not create index with operator class for CharField

2015-12-10 Thread Django

#25412: Migrate command does not create index with operator class for CharField
+-
 Reporter:  synasius|Owner:  synasius
 Type:  Bug |   Status:  closed
Component:  Migrations  |  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
+-

Comment (by Tim Graham ):

 In [changeset:"722fae4b5159b2810e252e3385936f86f04eb09b" 722fae4b]:
 {{{
 #!CommitTicketReference repository=""
 revision="722fae4b5159b2810e252e3385936f86f04eb09b"
 [1.9.x] Fixed #25412 -- Fixed missing PostgreSQL index on Char/TextField
 when using AlterField.

 Thanks to Emanuele Palazzetti for the help.

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

Re: [Django] #25412: Migrate command does not create index with operator class for CharField

2015-12-10 Thread Django

#25412: Migrate command does not create index with operator class for CharField
+-
 Reporter:  synasius|Owner:  synasius
 Type:  Bug |   Status:  closed
Component:  Migrations  |  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
+-

Comment (by Tim Graham ):

 In [changeset:"905e94a07e557f470fd1d01e7cd067cdae2b7794" 905e94a0]:
 {{{
 #!CommitTicketReference repository=""
 revision="905e94a07e557f470fd1d01e7cd067cdae2b7794"
 [1.8.x] Fixed #25412 -- Fixed missing PostgreSQL index on Char/TextField
 when using AlterField.

 Thanks to Emanuele Palazzetti for the help.

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

Re: [Django] #25872: Title attribute for related widget links lacks escaping (and breaks html)

2015-12-10 Thread Django

Comment (by a1tus):

There're not so much places in admin that need escaping (quite easy to
wrap them all with `{% filter %}` in a few minutes). On the other hand
it's hard to say how often django developers would use it.
I use translations quite rare in my work but anyway I think this `escape`
attribute would be useful and will improve readability. Also introducing
it can force some of us to remember about escaping our translations :)
One more thing is that it can be added, as I see, without breaking any
compatibility so I don't see any downsides.

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

Re: [Django] #25412: Migrate command does not create index with operator class for CharField

2015-12-10 Thread Django

#25412: Migrate command does not create index with operator class for CharField
+-
 Reporter:  synasius|Owner:  synasius
 Type:  Bug |   Status:  closed
Component:  Migrations  |  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 Tim Graham ):

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


Comment:

 In [changeset:"3a36c8079544c83dcdea4e52181efcd2d1e86b9c" 3a36c807]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a36c8079544c83dcdea4e52181efcd2d1e86b9c"
 Fixed #25412 -- Fixed missing PostgreSQL index on Char/TextField when
 using AlterField.

 Thanks to Emanuele Palazzetti for the help.
 }}}

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

Re: [Django] #25872: Title attribute for related widget links lacks escaping (and breaks html)

2015-12-10 Thread Django

#25872: Title attribute for related widget links lacks escaping (and breaks 
html)
-+
 Reporter:  a1tus|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by claudep):

 Thanks for these thorough findings. I think we should now evaluate the
 feasibility to add some (`escape`?) keyword to trans/blocktrans tags.

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

Re: [Django] #25619: Make runserver use HTTP 1.1

2015-12-10 Thread Django

#25619: Make runserver use HTTP 1.1
---+
 Reporter:  gabn88 |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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
---+

Comment (by claudep):

 Seems this ticket depends on #5897 (setting Content-Length on non-
 streaming responses).

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

Re: [Django] #21221: Widgets and Admin's Media should use the configured staticfiles storage to create the right path to a file

2015-12-10 Thread Django

#21221: Widgets and Admin's Media should use the configured staticfiles storage 
to
create the right path to a file
-+-
 Reporter:  Guilherme Gondim |Owner:  codingjoe
  |
 Type:  New feature  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  staticfiles, admin,  | Triage Stage:  Ready for
  CachedFilesMixin, media, widgets   |  checkin
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:"cf546e11ac76c8dec527e39ff8ce8249a195ab42" cf546e1]:
 {{{
 #!CommitTicketReference repository=""
 revision="cf546e11ac76c8dec527e39ff8ce8249a195ab42"
 Fixed #21221 -- Made form Media and static template tag use staticfiles if
 installed.
 }}}

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

Re: [Django] #25882: Deletion on ForeignKey raises TypeError

2015-12-10 Thread Django

#25882: Deletion on ForeignKey raises TypeError
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysql| 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):

 * keywords:   => mysql


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

Re: [Django] #25882: Deletion on ForeignKey raises TypeError

2015-12-10 Thread Django

#25882: Deletion on ForeignKey raises TypeError
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   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 charettes):

 From looking at the stacktrace it looks like you need to run your tests
 against a backend that doesn't have the
 
[https://github.com/django/django/blob/59b57e672c2f5a685804cce253d2c5314c45c5fa/django/db/models/sql/subqueries.py#L67-L71
 update_can_self_select] feature.

 The only core backend that has this feature turned off is
 
[https://github.com/django/django/search?utf8=%E2%9C%93&q=update_can_self_select
 MySQL].

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

Re: [Django] #25900: CommonMiddleware's USE_ETAGS broken

2015-12-10 Thread Django

#25900: CommonMiddleware's USE_ETAGS broken
-+-
 Reporter:  derekjamescurtis |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ETags| Triage Stage:  Ready for
 |  checkin
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:"364d7d969039bd14d3072a5ed035b88b44d855fd" 364d7d9]:
 {{{
 #!CommitTicketReference repository=""
 revision="364d7d969039bd14d3072a5ed035b88b44d855fd"
 [1.9.x] Fixed #25900 -- Fixed regression in CommonMiddleware ETag support.

 Backport of 6be9589eb34f79914666c9d9e1e15bdb7fc44df2 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/074.6ce422c7c968ca7de02bec7d4ea8ed1d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25882: Deletion on ForeignKey raises TypeError

2015-12-10 Thread Django

#25882: Deletion on ForeignKey raises TypeError
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   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 raphaelmerx):

 I can't capture the bug in a test, neither on master nor on 1.9. Am I
 understanding something wrong?

 {{{#!diff
 diff --git a/tests/delete_regress/models.py
 b/tests/delete_regress/models.py
 index f0145de..6d77c31 100644
 --- a/tests/delete_regress/models.py
 +++ b/tests/delete_regress/models.py
 @@ -139,3 +139,14 @@ class OrderedPerson(models.Model):

  class Meta:
  ordering = ['name']
 +
 +
 +class Catalog(models.Model):
 +name = models.CharField(max_length=255)
 +
 +class Reader(models.Model):
 +name = models.CharField(max_length=255)
 +catalog = models.ForeignKey(Catalog, models.CASCADE)
 +
 +class ReaderHasMedia(models.Model):
 +reader = models.ForeignKey(Reader, models.CASCADE)
 diff --git a/tests/delete_regress/tests.py b/tests/delete_regress/tests.py
 index 2128733..8b36509 100644
 --- a/tests/delete_regress/tests.py
 +++ b/tests/delete_regress/tests.py
 @@ -345,3 +345,11 @@ class OrderedDeleteTests(TestCase):
  OrderedPerson.objects.create(name='Bob', lives_in=h)
  OrderedPerson.objects.filter(lives_in__address='Foo').delete()
  self.assertEqual(OrderedPerson.objects.count(), 0)
 +
 +class DoubleForeignKeyTests(TestCase):
 +def test_double_foreign_key(self):
 +from .models import Catalog, Reader, ReaderHasMedia
 +c = Catalog.objects.create(name='aaa')
 +r = Reader.objects.create(name='bbb', catalog=c)
 +ReaderHasMedia.objects.create(reader=r)
 +
 
ReaderHasMedia.objects.filter(reader__catalog=Catalog.objects.get(pk=1)).delete()

 }}}

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

Re: [Django] #25900: CommonMiddleware's USE_ETAGS broken

2015-12-10 Thread Django

#25900: CommonMiddleware's USE_ETAGS broken
-+-
 Reporter:  derekjamescurtis |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ETags| 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 Tim Graham ):

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


Comment:

 In [changeset:"6be9589eb34f79914666c9d9e1e15bdb7fc44df2" 6be9589e]:
 {{{
 #!CommitTicketReference repository=""
 revision="6be9589eb34f79914666c9d9e1e15bdb7fc44df2"
 Fixed #25900 -- Fixed regression in CommonMiddleware ETag support.
 }}}

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

Re: [Django] #25104: Documentation assumes that there's a httpd.conf

2015-12-10 Thread Django

#25104: Documentation assumes that there's a httpd.conf
--+
 Reporter:  ChristianKleineidam   |Owner:  za
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+
Changes (by za):

 * owner:   => za
 * 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/077.fb52d4932a995d158a8e9c2826c89893%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25892: Optimize SeparateDatabaseAndState.database_backwards() by caching intermediate state

2015-12-10 Thread Django

#25892: Optimize SeparateDatabaseAndState.database_backwards() by caching
intermediate state
--+
 Reporter:  amosonn   |Owner:  amosonn
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  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:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5805 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/065.a9bd22252b6af8a70f3d20a7ac37af3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25911: The decorator override_settings resets SETTINGS_MODULE variable

2015-12-10 Thread Django

#25911: The decorator override_settings resets SETTINGS_MODULE variable
---+--
 Reporter:  kwist  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  override_settings  | 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:

 Could you elaborate on why this is a problem?

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

Re: [Django] #25912: New feature Bitwise operators ( Binary Left Shift Operator and Binary Right Shift Operator)

2015-12-10 Thread Django

#25912: New feature Bitwise operators ( Binary Left Shift Operator and Binary 
Right
Shift Operator)
---+
 Reporter:  anabelensc |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by anabelensc):

 * Attachment "add_bitwise_operators.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/068.638a9b1aae5eb9256f401da8daf4cbb1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25912: New feature Bitwise operators ( Binary Left Shift Operator and Binary Right Shift Operator)

2015-12-10 Thread Django

#25912: New feature Bitwise operators ( Binary Left Shift Operator and Binary 
Right
Shift Operator)
---+
 Reporter:  anabelensc |  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
---+
 Hello,
 I think is a good idea to add binary left shift operator and binary right
 shift operator to make queries.

 So the F() objects in addition to bitand and bitor operators, will be able
 to support binary left shift operator (bitleftshift) and binary right
 shift operator (bitrightshift).

 And then use (bitleftshift) and (bitrightshift) in the same way like the
 others operators, example the use:

 F('somefield').bitleftshift(16)
 F('somefield').bitrightshift(16)

 I've done a patch to add that and I've run the test suite using SQLite,
 you can see the files to attach.

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

Re: [Django] #25855: Improve runserver migration notification output.

2015-12-10 Thread Django

#25855: Improve runserver migration notification output.
-+-
 Reporter:  kezabelle|Owner:  emre
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by emre):

 Sorry, trac is a new thing for me :-)

 thanks for the heads up.

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

[Django] #25911: The decorator override_settings resets SETTINGS_MODULE variable

2015-12-10 Thread Django

#25911: The decorator override_settings resets SETTINGS_MODULE variable
---+---
 Reporter:  kwist  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.9
 Severity:  Normal |   Keywords:  override_settings
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 {{{#!python
 from django.conf import UserSettingsHolder, settings

 # output 'service.settings.local'
 print settings.SETTINGS_MODULE

 # from code override_settings
 override = UserSettingsHolder(settings._wrapped)

 # output None
 print override.SETTINGS_MODULE

 # output 'service.settings.local'
 print override.default_settings.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/048.2345260459ddfab773041e7af269b178%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25099: Cleanup HttpRequest representations in error reporting

2015-12-10 Thread Django

#25099: Cleanup HttpRequest representations in error reporting
-+-
 Reporter:  vzima|Owner:  vzima
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   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
-+-

Comment (by Tim Graham ):

 In [changeset:"428164fc81a8bf619d6a4fd92d3350c174e311a0" 428164fc]:
 {{{
 #!CommitTicketReference repository=""
 revision="428164fc81a8bf619d6a4fd92d3350c174e311a0"
 [1.9.x] Refs #25099 -- Added removal of build_request_repr() to 1.9
 release notes.

 Backport of 071af825398bab08246aa28c227514ed37cf4244 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.566fafc5ebc7ae75903f11b135949da9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25099: Cleanup HttpRequest representations in error reporting

2015-12-10 Thread Django

#25099: Cleanup HttpRequest representations in error reporting
-+-
 Reporter:  vzima|Owner:  vzima
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   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
-+-

Comment (by Tim Graham ):

 In [changeset:"071af825398bab08246aa28c227514ed37cf4244" 071af825]:
 {{{
 #!CommitTicketReference repository=""
 revision="071af825398bab08246aa28c227514ed37cf4244"
 Refs #25099 -- Added removal of build_request_repr() to 1.9 release notes.
 }}}

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

Re: [Django] #25899: manage.py tests requires database creation privileges

2015-12-10 Thread Django

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   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 timgraham):

 [https://github.com/django/django/pull/5812 Doc proposal] for the testings
 docs.

 Maybe a subsection under Oracle in `docs/ref/databases.txt` could also be
 added if we need more details about those Oracle specific settings?

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

Re: [Django] #25904: --fake-initial does not work for ManyToMany with through Model

2015-12-10 Thread Django

#25904: --fake-initial does not work for ManyToMany with through Model
+--
 Reporter:  maciej-pawlisz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 maciej-pawlisz):

 It was Django 1.9. From what I see when `initial` is `True`, django
 proceeds to checking db schema and this check fails. Actually it fails
 with every `ManyToManyField`, because it is added in `AddField` operation,
 but is not present in database schema:
 djang.db.migrations.executor.py:291
 {{{
 db_field = model._meta.get_field(operation.name).column
 fields =
 self.connection.introspection.get_table_description(self.connection.cursor(),
 table)
 if db_field not in (f.name for f in fields):
 return False, project_state
 }}}
 Easy fix would be adding this line before that check:
 {{{
  if isinstance(operation.field,models.ManyToMany):
 continue

 }}}
 But maybe the bug is somewhere else ie. why
 `model._meta.get_field(operation.name).column` is not None for
 ManyToManyField ?

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

Re: [Django] #24949: Force to_field and probably other fields to unicode during migration deconstruction

2015-12-10 Thread Django

Comment (by patrys):

It's also the case if your app does not have an `AppConfig` file and your
`INSTALLED_APPS` is a list of byte strings.

As I've noted in #25906, I'm not sure working around problems like this at
Django level is worth it. It will add a lot of seemingly no-op code that
in edge cases could silently cover entire classes of unrelated problems.

I think it would be a sane thing for Django to warn about things being the
wrong type and do nothing about it. Affected apps and projects will
continue to work in Python 2 and fail in Python 3 but they do that already
(they may not know or care). A warning should give enough information to
fix the problem (or file a bug with app's upstream).

I was affected and it took me a couple of months to find out. Our entire
test suite passed with flying colours and things only broke when squashing
migrations. With a proper validator warning it becomes a five minute fix.

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

Re: [Django] #25904: --fake-initial does not work for ManyToMany with through Model

2015-12-10 Thread Django

#25904: --fake-initial does not work for ManyToMany with through Model
+--
 Reporter:  maciej-pawlisz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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
+--
Changes (by timgraham):

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


Comment:

 Did you set the version on the ticket correctly? I might expect that
 behavior in Django 1.8 but if you generated the migrations with Django
 1.9, then they should have the
 [https://docs.djangoproject.com/en/1.9/topics/migrations/#initial-
 migrations initial] attribute set such that this shouldn't happen.

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

Re: [Django] #25894: Evaluation of zero-length slices of queryset.values() fails

2015-12-10 Thread Django

#25894: Evaluation of zero-length slices of queryset.values() fails
-+-
 Reporter:  debnet   |Owner:  sir-
 |  sigurd
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   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/064.f8f57b0d0b5c8963dab3fc6f0afb6a19%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25910: Model constructors accept read-only property names

2015-12-10 Thread Django

#25910: Model constructors accept read-only property names
-+-
 Reporter:  xlq  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model db | 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_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 1
 * needs_docs:   => 0


Comment:

 A test is also needed.

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

Re: [Django] #25906: `squashmigrations` generates migrations that don't work with Python 3

2015-12-10 Thread Django

#25906: `squashmigrations` generates migrations that don't work with Python 3
+--
Reporter: patrys |Owner: nobody
Type: Bug | Status: closed
Component: Migrations | 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 timgraham):

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

Comment:

We have the same problem (bytes/unicode discrepancy) in other places since
Django 1.7 and another solution has been proposed in #24949 so I'll add a
note about this there and mark this as a duplicate. We don't know whether
or not a user intends migrations to work on both Python 2 and 3, so
starting to throw errors when it's not really an error could be annoying.
If you disagree with the solution proposed in #24949, could you leave a
comment there?

I created #25909 for the `unicode_literals` proposal.

Thanks for raising the issue!

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

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

Re: [Django] #25910: Model constructors accept read-only property names

2015-12-10 Thread Django

#25910: Model constructors accept read-only property names
--+
 Reporter:  xlq   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal| Resolution:
 Keywords:  model db  |   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by xlq):

 * Attachment "django-model-ctor-prop.diff" added.

 Patch to fix the problem in the simplest possible way

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

Re: [Django] #25855: Improve runserver migration notification output.

2015-12-10 Thread Django

#25855: Improve runserver migration notification output.
-+-
 Reporter:  kezabelle|Owner:  emre
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 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):

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


Comment:

 Don't forget to uncheck the appropriate ticket flags after updating a
 patch ("Needs tests" in this case). Also, you don't need to add a patch on
 the ticket when you also send a pull request. Thanks!

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

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

[Django] #25910: Model constructors accept read-only property names

2015-12-10 Thread Django

#25910: Model constructors accept read-only property names
--+--
Reporter: xlq | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) |Version: 1.9
Severity: Normal| Keywords: model db
Triage Stage: Unreviewed| Has patch: 1
Easy pickings: 0 | UI/UX: 0
--+--
A model's constructor uses left-over keyword arguments (that weren't
matched to fields) to set properties on the model instance. If the
property's setter raises AttributeError (e.g. if it's a read-only
property), that exception is ignored. This can lead to bugs when, for
example, a field is changed to a property of the same name.

It looks like this behaviour (from 2007) might be unintentional: the
try...except looks like it's only supposed to catch the AttributeError
from getattr, not from the following settattr.

Fixing this is backwards-incompatible, but trying to set a read-only
property in this way is most probably a bug anyway.

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

Re: [Django] #24949: Force to_field and probably other fields to unicode during migration deconstruction

2015-12-10 Thread Django

#24949: Force to_field and probably other fields to unicode during migration
deconstruction
+
 Reporter:  MarkusH |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 timgraham):

 #25906 notes that this can also affect `AppConfig.app_name` when squashing
 migrations.

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

Re: [Django] #25894: Evaluation of zero-length slices of queryset.values() fails (was: Paginator fails with QuerySet returning no values)

2015-12-10 Thread Django

#25894: Evaluation of zero-length slices of queryset.values() fails
-+-
 Reporter:  debnet   |Owner:  sir-
 |  sigurd
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   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 debnet):

 * component:  Core (Other) => Database layer (models, ORM)


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

Re: [Django] #25855: Improve runserver migration notification output.

2015-12-10 Thread Django

#25855: Improve runserver migration notification output.
-+-
 Reporter:  kezabelle|Owner:  emre
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by emre):

 * Attachment "0001-Fixed-25855-Added-more-accurate-info-to-
 migration.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/067.ae632a53e737e8f646366d1cc204eadd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25855: Improve runserver migration notification output.

2015-12-10 Thread Django

#25855: Improve runserver migration notification output.
-+-
 Reporter:  kezabelle|Owner:  emre
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by emre):

 Just added the related unit tests and updated the pull request on github:

 https://github.com/django/django/pull/5765

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

Re: [Django] #25909: Add unicode_literals import to apps.py generated by startapp

2015-12-10 Thread Django

#25909: Add unicode_literals import to apps.py generated by startapp
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.9
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5811 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.8a96d46f7d865b5a12ed347eb58f3453%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25908: migrations fail when default function is removed

2015-12-10 Thread Django

#25908: migrations fail when default function is removed
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  1.9
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Correct, this is a
 [https://docs.djangoproject.com/en/stable/topics/migrations/#historical-
 models documented restriction]. You can use `squashmigrations` if you wish
 to remove old references.

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

[Django] #25909: Add unicode_literals import to apps.py generated by startapp

2015-12-10 Thread Django

#25909: Add unicode_literals import to apps.py generated by startapp
-+-
   Reporter:  timgraham  |  Owner:  timgraham
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  1.9
  (Other)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Similar to what's done for `models.py` (#24950), the import will help
 migrations generated using Python 2 to work on Python 3 (#25906).

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

[Django] #25908: migrations fail when default function is removed

2015-12-10 Thread Django

#25908: migrations fail when default function is removed
---+
 Reporter:  kaselis|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Whenever you set a default value for a model field to a function and make
 a migration, you can't remove the function afterwards. Migration fails to
 find the function in the module.

 For example if you make a migration of this code:
 {{{
 #!div style="font-size: 80%"
 {{{#!python
 def my_value():
 return 'a'

 class MyModel(models.Model):
 myfield = models.CharField(max_length=10, default=my_value)
 }}}
 }}}

 you can't remove `my_value` function even if you remove `default` from the
 field. And then you have to leave something like this in your code for
 migrations to work:
 {{{#!div style="font-size: 80%"
 def my_value(): pass
 }}}
 or
 {{{#!div style="font-size: 80%"
 my_value = lambda: None
 }}}

 It is not a problem for me, as my project is small and I don't mind
 recreating migrations without default function, but I see this as an issue
 because you might have to leave some dead code in your app, just for the
 migrations to work.

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

Re: [Django] #25906: `squashmigrations` generates migrations that don't work with Python 3

2015-12-10 Thread Django

#25906: `squashmigrations` generates migrations that don't work with Python 3
+--
 Reporter:  patrys  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 patrys):

 I don't think changing the project template will help anyone who faces
 this problem as it means they already have a settings file. IMO Django
 should tell users to fix their settings and refuse to create broken
 migrations.

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

Re: [Django] #25906: `squashmigrations` generates migrations that don't work with Python 3

2015-12-10 Thread Django

#25906: `squashmigrations` generates migrations that don't work with Python 3
+--
 Reporter:  patrys  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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
+--
Changes (by timgraham):

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


Comment:

 It's another case of #24949 (we could coerce the `app_name` bytestring),
 but an alternative is to add `from __future__ import unicode_literals` to
 the `apps.py` in the project template as we do for other files. I think
 the latter solution could be backported to 1.9. Should we create a
 separate ticket for that and close this as a duplicate of #24949?

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

Re: [Django] #25907: Alternative Way of Specifying URL Patterns

2015-12-10 Thread Django

#25907: Alternative Way of Specifying URL Patterns
-+--
 Reporter:  srkunze  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 timgraham):

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


Comment:

 You could propose it on the DevelopersMailingList (I couldn't find a past
 discussion from a quick seach), but I doubt we'd want to add another way
 of defining URLs. If you really want this in your own projects, you could
 possibly write an implantation that lives in each app's `urls.py` file and
 "autodiscovers" the URLs defined by your views according to whatever
 convention you want to use.

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

Re: [Django] #25905: Unsafe usage of urljoin() within FileStorageSystem

2015-12-10 Thread Django

#25905: Unsafe usage of urljoin() within FileStorageSystem
--+
 Reporter:  free-Runner   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  File uploads/storage  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  file, storage | 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):

 * type:  Bug => Cleanup/optimization
 * component:  Core (Other) => File uploads/storage
 * 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/069.5ea5e3972af915489574f2c5c13d5542%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25872: Title attribute for related widget links lacks escaping (and breaks html)

2015-12-10 Thread Django

#25872: Title attribute for related widget links lacks escaping (and breaks 
html)
-+
 Reporter:  a1tus|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   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 a1tus):

 I'm back with my super ''grep'' investigation!

 I've checked Django 1.9 templates.
 In contrib.admin we have 20 usages of `blocktrans` tag and 88 usages of a
 simple `trans` tag.

 Possibly unsafe usages of `blocktrans`:
 {{{
 # admin\change_list_results.html (1 hit)
 Line 18: {% if num_sorted_fields > 1 %}{{
 header.sort_priority }}{% endif %}

 # admin\index.html (1 hit)
 Line 20: {{ app.name }}

 # admin\related_widget_wrapper.html (3 hits)
 Line 8: title="{% blocktrans %}Change selected {{ model }}{% endblocktrans
 %}">
 Line 15: title="{% blocktrans %}Add another {{ model }}{% endblocktrans
 %}">
 Line 22: title="{% blocktrans %}Delete selected {{ model }}{%
 endblocktrans %}">
 }}}

 ... and `trans`:
 {{{
 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\actions.html
 (4 hits)
 Line 4: {%
 trans "Go" %}
 Line 4: {%
 trans "Go" %}
 Line 11: {% blocktrans with cl.result_count as
 total_count %}Select all {{ total_count }} {{ module_name }}{%
 endblocktrans %}
 Line 54: 

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\change_list_results.html
 (2 hits)
 Line 17: 
 Line 19: 

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\delete_confirmation.html
 (5 hits)
 Line 41: 

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\delete_selected_confirmation.html
 (5 hits)
 Line 44: 

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\login.html
 (4 hits)
 Line 61:  

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\pagination.html
 (2 hits)
 Line 11: {% if cl.formset and cl.result_count %}{% endif %}

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\related_widget_wrapper.html
 (3 hits)
 Line 9: 
 Line 16: 
 Line 23: 

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\search_form.html
 (2 hits)
 Line 7: 

 
C:\Users\alTus\Desktop\Django-1.9\django\contrib\admin\templates\admin\submit_line.html
 (5 hits)
 Line 3: {% if show_save %}{% endif %}
 Line 8: {% if show_save_as_new %}{% endif %}
 Line 9: {% if show_save_and_add_another %}{% endif %}
 Line 10: {% if show_save_and_continue %}{% endif %}
 }}}

 Some of the usages (like "save") seem to be quite safe but anyway I think
 that some solid approach in escaping translated string is needed.

 Also as I've seen the method of force escaping blocktrans contents is
 already used in admin for js code.
 For example `{% filter escapejs %}` in tabulars:
 {{{
 
 (function($) {
   $("#{{ inline_admin_formset.formset.prefix|escapejs }}-group .inline-
 related").stackedFormset({
 prefix: "{{ inline_admin_formset.formset.prefix|escapejs }}",
 deleteText: "{% filter escapejs %}{% trans "Remove" %}{% endfilter
 %}",
 addText: "{% filter escapejs %}{% blocktrans with
 verbose_name=inline_admin_formset.opts.verbose_name|capfirst %}Add another
 {{ verbose_name }}{% endblocktrans %}{% endfilter %}"
   });
 })(django.jQuery);
 
 }}}

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

Re: [Django] #24116: Refactor AdminSite.check_dependencies with the checks framework

2015-12-10 Thread Django

#24116: Refactor AdminSite.check_dependencies with the checks framework
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  vincepandolfo
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by vincepandolfo):

 * owner:  nobody => vincepandolfo
 * 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/067.cc0fb4c7e9ac84e3d96ef78042cc85bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25907: Alternative Way of Specifying URL Patterns

2015-12-10 Thread Django

#25907: Alternative Way of Specifying URL Patterns
-+
 Reporter:  srkunze  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Core (URLs)  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Other frameworks (like MVC 5) provide an inline-way of specifying the URL
 pattern for a view.

 Would it be possible to introduce such thing for Django?


 Internally, we are working on something like this in order to accelerate
 development and maintenance for our production system.

 Manually looking up URLs in the url.py and then jump to the actual view
 class is quite error-prone and tedious.


 Internally, we evaluate two alternatives:

 1) via class attribute: url
 2) via decorator on class


 {{{
 # alternative 1
 class ThingView(DetailView):
 url = '/thing(?P\d+)'
 template_name = 'thing.html'

 # alternative 2
 @url('/thing/(?P\d+)'):
 class ThingView(DetailView):
 template_name = 'thing.html'
 }}}

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

[Django] #25906: `squashmigrations` generates migrations that don't work with Python 3

2015-12-10 Thread Django

#25906: `squashmigrations` generates migrations that don't work with Python 3
+
 Reporter:  patrys  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.9
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 When I run `squashmigrations` I get something similar to the following:

 {{{
 class Migration(migrations.Migration):

 replaces = [(b'registration', '0001_initial'), (b'registration',
 '0002_auto_20151203_1158')]
 ...
 }}}

 Notice how app names are passed as `bytes` instances.

 Now in Python 3 a `bytes` objects is never equal to its Unicode (`str`)
 representation. This inequality makes Django consider the squashed
 migration conflicting with the migrations it replaces.

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

Re: [Django] #25894: Paginator fails with QuerySet returning no values

2015-12-10 Thread Django

#25894: Paginator fails with QuerySet returning no values
-+--
 Reporter:  debnet   |Owner:  sir-sigurd
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  1.9
 Severity:  Release blocker  |   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 sir-sigurd):

 * has_patch:  0 => 1


Comment:

 PR -- https://github.com/django/django/pull/5808

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

70 matches

Mail list logo