Re: [Django] #26005: uri_to_iri() perfoms percent decoding incorrectly

2016-04-06 Thread Django
#26005: uri_to_iri() perfoms percent decoding incorrectly
---+---
 Reporter:  Chronial   |Owner:  varunnaganathan
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---

Comment (by Chronial):

 @timgraham I created A PR against 1.8.x:
 https://github.com/django/django/pull/6426

 This now correctly implements the algorithm from the RFC, except for step
 4: The implementation is supposed to re-encode some unicode characters
 “that are not appropriate” for IRIs. I added a note about that to the
 docstring.

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


Re: [Django] #26470: Checks performed during Permission creation should use the check framework.

2016-04-06 Thread Django
#26470: Checks performed during Permission creation should use the check 
framework.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"a872194802c2bacb067c2b9c9cb76361e2071c0f" a872194]:
 {{{
 #!CommitTicketReference repository=""
 revision="a872194802c2bacb067c2b9c9cb76361e2071c0f"
 Fixed #26470 -- Converted auth permission validation to system checks.

 Thanks Tim for the review.
 }}}

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


Re: [Django] #26470: Checks performed during Permission creation should use the check framework.

2016-04-06 Thread Django
#26470: Checks performed during Permission creation should use the check 
framework.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #24972: Removing unique_together constraint makes migration fail on Django 1.8.2 with MySQL

2016-04-06 Thread Django
#24972: Removing unique_together constraint makes migration fail on Django 1.8.2
with MySQL
-+-
 Reporter:  adambrenecki |Owner:
 |  adambrenecki
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.9
 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 timgraham):

 Please open a new ticket with steps to reproduce (such as a sample
 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/070.68de7fdb5e1a022b0e44093a4a3c5954%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24972: Removing unique_together constraint makes migration fail on Django 1.8.2 with MySQL

2016-04-06 Thread Django
#24972: Removing unique_together constraint makes migration fail on Django 1.8.2
with MySQL
-+-
 Reporter:  adambrenecki |Owner:
 |  adambrenecki
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.9
 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
-+-
Changes (by adamn):

 * version:  1.8 => 1.9


Comment:

 This still seems to be a problem.

 MySQL 5.6
 Django 1.9.4
 Python 3.5

 In this case I'm dropping a unique_with constraint on a table called
 "stream_streamaccess"
 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('stream', '0002_auto_20160406_1501'),
 ]

 operations = [
 migrations.AlterUniqueTogether(
 name='streamaccess',
 unique_together=set([]),
 ),
 ]

 }}}
 {{{
 Running migrations:
   Rendering model states... DONE
   Applying stream.0003_auto_20160406_2130...Traceback (most recent call
 last):
   File "/var/www/centr/manage.py", line 13, in 
 execute_from_command_line(sys.argv)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 353, in
 execute_from_command_line
 utility.execute()
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 345, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/core/management/base.py", line 348, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/core/management/base.py", line 399, in execute
 output = self.handle(*args, **options)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/core/management/commands/migrate.py", line 200, in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 92, in migrate
 self._migrate_all_forwards(plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 121, in
 _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 198, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/migrations/migration.py", line 123, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/migrations/operations/models.py", line 359, in
 database_forwards
 getattr(new_model._meta, self.option_name, set()),
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/backends/base/schema.py", line 318, in
 alter_unique_together
 self._delete_composed_index(model, fields, {'unique': True},
 self.sql_delete_unique)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/backends/mysql/schema.py", line 87, in
 _delete_composed_index
 return super(DatabaseSchemaEditor, self)._delete_composed_index(model,
 fields, *args)
   File "/var/virtualenvs/centr/lib/python3.5/site-
 packages/django/db/backends/base/schema.py", line 347, in
 _delete_composed_index
 ", ".join(columns),
 ValueError: Found wrong number (0) of constraints for
 stream_streamaccess(stream_id, user_id, role)
 }}}

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


Re: [Django] #26470: Checks performed during Permission creation should use the check framework.

2016-04-06 Thread Django
#26470: Checks performed during Permission creation should use the check 
framework.
--+
 Reporter:  charettes |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

 * needs_better_patch:  1 => 0


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

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


Re: [Django] #26470: Checks performed during Permission creation should use the check framework.

2016-04-06 Thread Django
#26470: Checks performed during Permission creation should use the check 
framework.
--+
 Reporter:  charettes |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  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 charettes):

 Just ported the permission names max length checks as well.

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

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


Re: [Django] #26474: Add source of minified javascript files

2016-04-06 Thread Django
#26474: Add source of minified javascript files
-+-
 Reporter:  rhertzog |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  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:

 I've asked for thoughts about this on the
 [https://groups.google.com/d/topic/django-
 developers/_-3FBN6-t_0/discussion django-developers] mailing list.

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


Re: [Django] #25420: Bash completion helper always with exit-code 1

2016-04-06 Thread Django
#25420: Bash completion helper always with exit-code 1
-+-
 Reporter:  blueyed  |Owner:  Dunedan
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Dunedan):

 Ah, now with discussion and Github and here it might become slightly
 confusing. Anyway, I posted my general comments already on Github
 (https://github.com/django/django/pull/6389#issuecomment-206457800) and
 just want to add one note here:
  I have not checked the (shipped) Bash completion, but also there it might
 make a difference in case Django fails before reaching the autocompletion
 code (e.g. because of import errors etc).
 That's what I checked and the return code doesn't matter at all (beside
 the weird edge cases with 124 and 127). If the notes from my original
 investigation weren't clear enough regarding that please drop me a note
 and I'll try to clear that out.

 And regarding your zsh completion support I suggest to add different exit
 codes with the ticket implementing the zsh completion.

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


[Django] #26474: Add source of minified javascript files

2016-04-06 Thread Django
#26474: Add source of minified javascript files
--+
 Reporter:  rhertzog  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 In Debian, we like to have the sources of everything that we ship and we
 consider that minified javascript files are not really scripts (which are
 their own source).

 There are currently two problematic files in Django:
 js_tests/qunit/blanket.min.js
 django/contrib/admin/static/admin/js/vendor/xregexp/xregexp.min.js

 To remedy this I would suggest to either:
 - directly use a non-minified file like you do for many other javascript
 files (ex: django/contrib/admin/static/admin/js/SelectFilter2.js)
 - store a non-minified file next to the minified file (same name without
 the ".min" part)

 Thank you for considering this request.

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


Re: [Django] #26473: django/contrib/admin/static/admin/fonts/LICENSE.txt has executable rights in git

2016-04-06 Thread Django
#26473: django/contrib/admin/static/admin/fonts/LICENSE.txt has executable 
rights
in git
--+
 Reporter:  rhertzog  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  closed
Component:  contrib.admin |Version:  1.9
 Severity:  Normal| Resolution:  fixed
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  1
UI/UX:  0 |
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"7d6e6e83675ef62b7aaafc945444a9ac99415540" 7d6e6e8]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d6e6e83675ef62b7aaafc945444a9ac99415540"
 Fixed #26473 -- chmod -x on
 django/contrib/admin/static/admin/fonts/LICENSE.txt
 }}}

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


Re: [Django] #26473: django/contrib/admin/static/admin/fonts/LICENSE.txt has executable rights in git

2016-04-06 Thread Django
#26473: django/contrib/admin/static/admin/fonts/LICENSE.txt has executable 
rights
in git
--+
 Reporter:  rhertzog  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  closed
Component:  contrib.admin |Version:  1.9
 Severity:  Normal| Resolution:  fixed
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  1
UI/UX:  0 |
--+

Comment (by Tim Graham ):

 In [changeset:"13d1676498b6d4789c352cba48af1ce17b35820f" 13d16764]:
 {{{
 #!CommitTicketReference repository=""
 revision="13d1676498b6d4789c352cba48af1ce17b35820f"
 [1.9.x] Fixed #26473 -- chmod -x on
 django/contrib/admin/static/admin/fonts/LICENSE.txt

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


[Django] #26473: django/contrib/admin/static/admin/fonts/LICENSE.txt has executable rights in git

2016-04-06 Thread Django
#26473: django/contrib/admin/static/admin/fonts/LICENSE.txt has executable 
rights
in git
--+
 Reporter:  rhertzog  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.admin |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Please drop the executable permission on
 django/contrib/admin/static/admin/fonts/LICENSE.txt (in master and in
 1.9.x).

 See
 
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/fonts/LICENSE.txt
 it's written "Executable File" and the release tarballs then embed this
 permission too... leading to lintian errors on the Debian package:
 W: python-django-common: executable-not-elf-or-script usr/share/python-
 django-common/django/contrib/admin/static/admin/fonts/LICENSE.txt

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


Re: [Django] #26466: set_language with next unset and a urlencoded HTTP_REFERER fails redirection

2016-04-06 Thread Django
#26466: set_language with next unset and a urlencoded HTTP_REFERER fails
redirection
--+
 Reporter:  miikkas   |Owner:  miikkas
 Type:  Bug   |   Status:  assigned
Component:  Internationalization  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  set_language  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by miikkas):

 Django's own `urlunquote` had to be used here instead of Python's
 `unquote` – the latter caused unicode problems on Py2 test suite. Anyway,
 the patch has been updated and everything should work now.

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

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


Re: [Django] #24016: Document how to migrate data between two external apps

2016-04-06 Thread Django
#24016: Document how to migrate data between two external apps
---+
 Reporter:  jsma   |Owner:  rixx
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"59ae2292df8daae365f989bdb388b4eb38d5927a" 59ae2292]:
 {{{
 #!CommitTicketReference repository=""
 revision="59ae2292df8daae365f989bdb388b4eb38d5927a"
 [1.9.x] Fixed #24016 -- Added "Migrating data between third-party apps"
 howto.

 Thanks to Markus, Marten and Sergei for help and review.

 Backport of b7ea494d65e4d9703a0a24f0cd708293df88f48b and
 c643b4c9f2acfdcb562bdbec1d74ac797b890b9b 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/062.b8e80bf4a0adfea3be2226bd0bd30f34%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24016: Document how to migrate data between two external apps

2016-04-06 Thread Django
#24016: Document how to migrate data between two external apps
---+
 Reporter:  jsma   |Owner:  rixx
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"c643b4c9f2acfdcb562bdbec1d74ac797b890b9b" c643b4c9]:
 {{{
 #!CommitTicketReference repository=""
 revision="c643b4c9f2acfdcb562bdbec1d74ac797b890b9b"
 Refs #24016 -- Edited "Migrating data between third-party apps" howto.
 }}}

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

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


Re: [Django] #20027: manage.py shebang should reflect used python executable

2016-04-06 Thread Django
#20027: manage.py shebang should reflect used python executable
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Python 3   |  Version:  1.5
 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
---+--

Comment (by rhertzog):

 What about rewriting it at least when "python" does not exist on the PATH?

 When I wrote a test suite for the Debian package, I tested specifically in
 a Python3 only environment (and in Debian, much like most sane distros,
 Python 3 is /usr/bin/python3) and I was astonished that django-admin
 createproject would not create a working ./manage.py...

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


Re: [Django] #26037: Document precedence of USE_X_FORWARDED_HOST and USE_X_FORWARDED_PORT settings (was: HttpRequest.get_host() uses either HTTP_X_FORWARDED_HOST or HTTP_X_FORWARDED_PORT => should use

2016-04-06 Thread Django
#26037: Document precedence of USE_X_FORWARDED_HOST and USE_X_FORWARDED_PORT
settings
-+-
 Reporter:  benoitbryon  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #14131: The pagination module should have some limit, or a warning should be given in the documentation

2016-04-06 Thread Django
#14131: The pagination module should have some limit, or a warning should be 
given
in the documentation
--+
 Reporter:  mlissner  |Owner:  winsmith
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"e043b85b1518c38f1d5fe5671ab0f4eccc569ce8" e043b85b]:
 {{{
 #!CommitTicketReference repository=""
 revision="e043b85b1518c38f1d5fe5671ab0f4eccc569ce8"
 [1.9.x] Refs #14131 -- Documented why paginating large QuerySets may be
 slow.

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


Re: [Django] #14131: The pagination module should have some limit, or a warning should be given in the documentation

2016-04-06 Thread Django
#14131: The pagination module should have some limit, or a warning should be 
given
in the documentation
--+
 Reporter:  mlissner  |Owner:  winsmith
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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


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

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


Re: [Django] #14131: The pagination module should have some limit, or a warning should be given in the documentation

2016-04-06 Thread Django
#14131: The pagination module should have some limit, or a warning should be 
given
in the documentation
--+
 Reporter:  mlissner  |Owner:  winsmith
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"eed658d7c4dda695976c6845346b166960957eba" eed658d7]:
 {{{
 #!CommitTicketReference repository=""
 revision="eed658d7c4dda695976c6845346b166960957eba"
 Refs #14131 -- Documented why paginating large QuerySets may be slow.
 }}}

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


Re: [Django] #25856: JS strftime shim could (sometimes) support %B

2016-04-06 Thread Django
#25856: JS strftime shim could (sometimes) support %B
--+
 Reporter:  kezabelle |Owner:  akoskaaa
 Type:  New feature   |   Status:  closed
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ab2d34ba3fe95d0324d544ca2ca92c2bf0b533aa" ab2d34ba]:
 {{{
 #!CommitTicketReference repository=""
 revision="ab2d34ba3fe95d0324d544ca2ca92c2bf0b533aa"
 Fixed #25856 -- Added %B support to Date.strftime.

 This enables the admin to display the correct localized month name if %B
 is used in the date format.
 }}}

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


Re: [Django] #26472: Allow finer granularity in the ability to silence checks (was: allow model field level silencing of system checks (e.g.: W342))

2016-04-06 Thread Django
#26472: Allow finer granularity in the ability to silence checks
--+
 Reporter:  zsoldosp  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

 * version:  1.8 => master


Comment:

 Agreed, I can see this being useful at the app, model and field level.

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


Re: [Django] #26470: Checks performed during Permission creation should use the check framework.

2016-04-06 Thread Django
#26470: Checks performed during Permission creation should use the check 
framework.
--+
 Reporter:  charettes |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

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


Comment:

 Alright, I'll add them as errors later today in this case.

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

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


Re: [Django] #26466: set_language with next unset and a urlencoded HTTP_REFERER fails redirection

2016-04-06 Thread Django
#26466: set_language with next unset and a urlencoded HTTP_REFERER fails
redirection
--+
 Reporter:  miikkas   |Owner:  miikkas
 Type:  Bug   |   Status:  assigned
Component:  Internationalization  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  set_language  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by miikkas):

 * has_patch:  0 => 1


Comment:

 I have created a fix for the bug and a regression test for the fix. The
 patch is available at the following branch:
 * https://github.com/miikkas/django/tree/ticket_26466

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


Re: [Django] #26426: Add a way to customize a QuerySet's joins (was: Use case for QuerySet.extra: annotate query with the existence of a relation)

2016-04-06 Thread Django
#26426: Add a way to customize a QuerySet's joins
-+-
 Reporter:  yourcelf |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | 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


Old description:

> This ticket is just to document a use case for QuerySet.extra as
> requested by the docs:
> https://docs.djangoproject.com/en/1.9/ref/models/querysets/#extra
>
> I have a Category model like this:
>
> {{{
> class Category(models.Model):
> name = models.CharField(max_length=200)
> followers = models.ManyToManyField(User)
> }}}
>
> I want to get a list of all categories, but to annotate each category
> with whether the currently logged in user is a "follower" of the
> category.  Neither `prefetch_related` nor `annotate` work here, because I
> don't want to fetch nor aggregate over //all// "followers" (potentially
> many), I just want the presence of the current user.  The extra query
> looks like this:
>
> {{{
> Category.objects.filter(...).extra(
> select={'is_following': '''EXISTS(
> SELECT "id" FROM "projects_category_followers" WHERE
> "projects_category_followers"."category_id"="projects_category"."id" AND
> "projects_category_followers"."user_id"=%s
> )'''},
> select_params=(request.user.id,)
> )
> }}}

New description:

 This ticket is just to document a use case for QuerySet.extra as requested
 by the docs:
 https://docs.djangoproject.com/en/1.9/ref/models/querysets/#extra

 I have a Category model like this:

 {{{
 class Category(models.Model):
 name = models.CharField(max_length=200)
 followers = models.ManyToManyField(User)
 }}}

 I want to get a list of all categories, but to annotate each category with
 whether the currently logged in user is a "follower" of the category.
 Neither `prefetch_related` nor `annotate` work here, because I don't want
 to fetch nor aggregate over //all// "followers" (potentially many), I just
 want the presence of the current user.  The extra query looks like this:

 {{{
 Category.objects.filter(...).extra(
 select={'is_following': '''EXISTS(
 SELECT "id" FROM "projects_category_followers" WHERE
 "projects_category_followers"."category_id"="projects_category"."id" AND
 "projects_category_followers"."user_id"=%s
 )'''},
 select_params=(request.user.id,)
 )
 }}}

--

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


Re: [Django] #26472: allow model field level silencing of system checks (e.g.: W342)

2016-04-06 Thread Django
#26472: allow model field level silencing of system checks (e.g.: W342)
--+
 Reporter:  zsoldosp  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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


Comment:

 I don't think the proposed API of a model field argument is a good one
 (this wouldn't allow a project to silence a warnings in third-party app,
 for example), but the idea of finer granularity in the ability to silence
 errors has come up before and would be great.

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


[Django] #26472: allow model field level silencing of system checks (e.g.: W342)

2016-04-06 Thread Django
#26472: allow model field level silencing of system checks (e.g.: W342)
--+
 Reporter:  zsoldosp  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Core (System checks)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
  Proposal 

 Add an optional kwarg to modelfields called
 `silenced_system_check=`, which would default to `None` or an
 empty collection

 As  `CheckMessage` already has access to the object it applies to, it
 should be a matter of adding an extra check in `is_silenced`  to check
 whether the warning id is present in the global system settings or inside
 the modelfield's own silenced system checks

 https://github.com/django/django/blob/master/django/core/checks/messages.py#L54

  Context 

 on a large application that was recently upgraded to 1.8, we wanted to add
 a step to the build to fail is `manage.py check` would report any
 warnings. However, there are many uses of
 `models.ForeignKey(unique=True)`, and thus upgrading all of them right now
 is not feasible. The only option we have is to use
 `settings.SILENCED_SYSTEM_CHECKS`, however, that silencing the warning
 there would apply to any new models/fields that are added, for which we
 would actually be happy to fail the build.

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


Re: [Django] #26470: Checks performed during Permission creation should use the check framework.

2016-04-06 Thread Django
#26470: Checks performed during Permission creation should use the check 
framework.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => Ready for checkin


Comment:

 Those checks were added before the permission name `max_length` was
 increased from 50 to 255 (#8162). Therefore I expect few if any users to
 exceed that limit these days. I don't see much benefit to adding
 truncation logic as proposed.

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


Re: [Django] #26471: Invalid polish translation

2016-04-06 Thread Django
#26471: Invalid polish translation
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.9
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by marcinn):

 Sorry. I didn't know about Transifex. Great tool, btw.

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


Re: [Django] #14131: The pagination module should have some limit, or a warning should be given in the documentation

2016-04-06 Thread Django
#14131: The pagination module should have some limit, or a warning should be 
given
in the documentation
--+
 Reporter:  mlissner  |Owner:  winsmith
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by winsmith):

 * has_patch:  0 => 1


Comment:

 Thanks for your feedback, I added some more information.

 New PR: https://github.com/django/django/pull/6422

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


Re: [Django] #26471: Invalid polish translation

2016-04-06 Thread Django
#26471: Invalid polish translation
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.9
  Internationalization   |
 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
 * resolution:   => invalid


Comment:

 As the new ticket page says, "Use
 [https://www.transifex.com/projects/p/django/ Transifex] for
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations
 bug reports on translations]."

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


Re: [Django] #25420: Bash completion helper always with exit-code 1

2016-04-06 Thread Django
#25420: Bash completion helper always with exit-code 1
-+-
 Reporter:  blueyed  |Owner:  Dunedan
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by blueyed):

 Thanks for fixing this! (by changing it to 0 and not only document it)

 Just for information/reference:

 > Everything is fine as the exit code of the `autocompletion` method is
 never returned to the shell and is not 124 or 127 (as that would change
 what Bash returns for autocompletion).

 I am using the autocompletion in a custom (not yet released) completion
 function for Zsh, and the exit code of 0 helps me to know that it was
 successful.
 I have not checked the (shipped) Bash completion, but also there it might
 make a difference in case Django fails before reaching the autocompletion
 code (e.g. because of import errors etc).

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


Re: [Django] #26471: Invalid polish translation

2016-04-06 Thread Django
#26471: Invalid polish translation
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.9
  Internationalization   |
 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 marcinn):

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


Old description:

> Polish translation of "Authentication and authorization" is invalid.
>
> There is:
> {{{
> msgid "Authentication and Authorization"
> msgstr "Autentykacja i autoryzacja"
> }}}
>
> but should be
>
> {{{
> msgid "Authentication and Authorization"
> msgstr "Uwierzytelnianie i autoryzacja"
> }}}
>
> There is no valid word "autentykacja" in Polish. Please patch
> translations.

New description:

 Polish translation of "Authentication and authorization" is invalid.

 There is:
 {{{
 msgid "Authentication and Authorization"
 msgstr "Autentykacja i autoryzacja"
 }}}

 but should be

 {{{
 msgid "Authentication and Authorization"
 msgstr "Uwierzytelnianie i autoryzacja"
 }}}

 There is no valid word "autentykacja" in Polish. Please patch
 translations.

 Please refer to:
   * http://archive.is/1kauQ
   * https://pl.wikipedia.org/wiki/Uwierzytelnianie

--

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


[Django] #26471: Invalid polish translation

2016-04-06 Thread Django
#26471: Invalid polish translation
--+
 Reporter:  marcinn   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Polish translation of "Authentication and authorization" is invalid.

 There is:
 {{{
 msgid "Authentication and Authorization"
 msgstr "Autentykacja i autoryzacja"
 }}}

 but should be

 {{{
 msgid "Authentication and Authorization"
 msgstr "Uwierzytelnianie i autoryzacja"
 }}}

 There is no valid word "autentykacja" in Polish. Please patch
 translations.

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