Re: [Django] #28703: URL regex for admin's app_index view isn't constructed deterministically

2017-10-14 Thread Django
#28703: URL regex for admin's app_index view isn't constructed deterministically
-+-
 Reporter:  Erik Bryant  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  stable   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I'm not sure if there's a compelling reason to make the proposed change
 but I guess the overhead isn't too large.

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


Re: [Django] #28713: ModelBackend call to get_all_permissions() makes get_user_permissions() return all permissions

2017-10-14 Thread Django
#28713: ModelBackend call to get_all_permissions() makes get_user_permissions()
return all permissions
-+-
 Reporter:  Yuri Kaszubowski |Owner:  nobody
  Lopes  |
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Unreviewed
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:"325d3027dbd4fdb92a926621f2d8852f072ebcb6" 325d3027]:
 {{{
 #!CommitTicketReference repository=""
 revision="325d3027dbd4fdb92a926621f2d8852f072ebcb6"
 [2.0.x] Fixed #28713 -- Prevented ModelBackend.get_all_permissions() from
 mutating get_user_permissions().

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


Re: [Django] #28713: ModelBackend call to get_all_permissions() makes get_user_permissions() return all permissions

2017-10-14 Thread Django
#28713: ModelBackend call to get_all_permissions() makes get_user_permissions()
return all permissions
-+-
 Reporter:  Yuri Kaszubowski |Owner:  nobody
  Lopes  |
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"d98210c25577e7f007605f4960672e887dd452e6" d98210c2]:
 {{{
 #!CommitTicketReference repository=""
 revision="d98210c25577e7f007605f4960672e887dd452e6"
 Fixed #28713 -- Prevented ModelBackend.get_all_permissions() from mutating
 get_user_permissions().
 }}}

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


Re: [Django] #28703: URL regex for admin's app_index view isn't constructed deterministically

2017-10-14 Thread Django
#28703: URL regex for admin's app_index view isn't constructed deterministically
-+-
 Reporter:  Erik Bryant  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  stable   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Erik Bryant):

 That's a good point. We don't plan to test the admin/ URLs. I'll remove
 that one from the list we scrape.

 As for this ticket, should we go ahead with the 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/068.00f58656f49fe9055c279ad93897b788%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28714: Django Makemigrations don't check if field name from indexes exists on model before creating a migration.

2017-10-14 Thread Django
#28714: Django Makemigrations don't check if field name from indexes exists on
model before creating a migration.
-+-
 Reporter:  Gabriel  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  indexes, migrate,| Triage Stage:
  makemigrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Gabriel):

 * Attachment "item_app.zip" added.

 Folder with App named item.

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


[Django] #28714: Django Makemigrations don't check if field name from indexes exists on model before creating a migration.

2017-10-14 Thread Django
#28714: Django Makemigrations don't check if field name from indexes exists on
model before creating a migration.
-+-
   Reporter:  Gabriel|  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  1.11
  Migrations |   Keywords:  indexes, migrate,
   Severity:  Normal |  makemigrations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using makemigration with indexes on class Meta in the Model Django
 don't check whether the field name in fields parameter exists on Model.

 Because of this both the migration files (in migrations/*.py) and the
 model class on model.py will have a index that referrer to a non existing
 field, so when **manage.py migrate** is run, the expection
 FieldDoesNotExist will be raised, but in this moment the programmer will
 have to edit both the migration file and model class to fix the error,
 especially if is not possible to remove the migrations file or is more
 convenient to edit the migration in projects with many Apps and many
 dependency between those Apps.

 Would be more convenient if makemigration before generate the new
 migration files did this verification.

 Example of model's code with wrong field name ("''names''") on indexes:

 {{{
 class ItemType(models.Model):
 name = models.CharField(_('Name'), unique=True, max_length=255)

 class Meta:
 managed = True
 db_table = 'item_type'
 ordering = ['name']

 indexes = [
 models.Index(fields=['id'],
 name='item_type_index_1'),
 models.Index(fields=['-id'],
 name='item_type_index_2'),
 models.Index(fields=['names'],
 name='item_type_index_3'),
 models.Index(fields=['-names'],
 name='item_type_index_4')
 ]
 }}}

 This code will not raise any exception on **makemigrations**, only the
 generated code on migration file will when **migrate** is used:

 {{{
migrations.AddIndex(
 model_name='itemtype',
 index=models.Index(fields=['names'],
 name='item_type_index_3'),
 ),
 migrations.AddIndex(
 model_name='itemtype',
 index=models.Index(fields=['-names'],
 name='item_type_index_4'),
 ),
 }}}

 Traceback (manage.py migrate):


 {{{
 Traceback (most recent call last):
   File "D:\Project-2015\cultural\manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "C:\Python36\lib\site-packages\django\core\management\__init__.py",
 line 364, in execute_from_command_line
 utility.execute()
   File "C:\Python36\lib\site-packages\django\core\management\__init__.py",
 line 356, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "C:\Python36\lib\site-packages\django\core\management\base.py",
 line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "C:\Python36\lib\site-packages\django\core\management\base.py",
 line 330, in execute
 output = self.handle(*args, **options)
   File "C:\Python36\lib\site-
 packages\django\core\management\commands\migrate.py", line 204, in handle
 fake_initial=fake_initial,
   File "C:\Python36\lib\site-packages\django\db\migrations\executor.py",
 line 115, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "C:\Python36\lib\site-packages\django\db\migrations\executor.py",
 line 145, in _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "C:\Python36\lib\site-packages\django\db\migrations\executor.py",
 line 244, in apply_migration
 state = migration.apply(state, schema_editor)
   File "C:\Python36\lib\site-packages\django\db\migrations\migration.py",
 line 129, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "C:\Python36\lib\site-
 packages\django\db\migrations\operations\models.py", line 788, in
 database_forwards
 schema_editor.add_index(model, self.index)
   File "C:\Python36\lib\site-packages\django\db\backends\base\schema.py",
 line 331, in add_index
 self.execute(index.create_sql(model, self))
   File "C:\Python36\lib\site-packages\django\db\models\indexes.py", line
 65, in create_sql
 sql_parameters = self.get_sql_create_template_values(model,
 schema_editor, using)
   File "C:\Python36\lib\site-packages\django\db\models\indexes.py", line
 48, in 

Re: [Django] #28710: Wrong Basque DATE_FORMAT string

2017-10-14 Thread Django
#28710: Wrong Basque DATE_FORMAT string
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"398a79ceb67be33d9ad63fd8221d3523525d70db" 398a79ce]:
 {{{
 #!CommitTicketReference repository=""
 revision="398a79ceb67be33d9ad63fd8221d3523525d70db"
 [1.11.x] Refs #28710 -- Simplified l10n format test

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


Re: [Django] #28710: Wrong Basque DATE_FORMAT string

2017-10-14 Thread Django
#28710: Wrong Basque DATE_FORMAT string
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"6481795d6367fd5031b00513768d1099424d9421" 6481795d]:
 {{{
 #!CommitTicketReference repository=""
 revision="6481795d6367fd5031b00513768d1099424d9421"
 [2.0.x] Refs #28710 -- Simplified l10n format test

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


Re: [Django] #28710: Wrong Basque DATE_FORMAT string

2017-10-14 Thread Django
#28710: Wrong Basque DATE_FORMAT string
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"c1fa6672dd995e5ab4e06d5132db40ed0f41a47e" c1fa667]:
 {{{
 #!CommitTicketReference repository=""
 revision="c1fa6672dd995e5ab4e06d5132db40ed0f41a47e"
 Refs #28710 -- Simplified l10n format test
 }}}

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

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


Re: [Django] #28711: unordered_list template filter does not work with lazy translations

2017-10-14 Thread Django
#28711: unordered_list template filter does not work with lazy translations
-+
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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 Claude Paroz):

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


Re: [Django] #28643: Complete the ORM Function Library

2017-10-14 Thread Django
#28643: Complete the ORM Function Library
-+-
 Reporter:  Matthew Pava |Owner:  JunyiJ
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 [https://github.com/django/django/pull/9220 PR - Ltrim, Rtrim, Strip, and
 Trim.]

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


[Django] #28713: ModelBackend call to get_all_permissions() makes get_user_permissions() return all permissions

2017-10-14 Thread Django
#28713: ModelBackend call to get_all_permissions() makes get_user_permissions()
return all permissions
--+
   Reporter:  Yuri Kaszubowski Lopes  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.auth|Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 django.contrib.auth.backends.ModelBackend.get_all_permissions() overwrites
 the _user_perm_cache as:


 {{{
 user_obj._perm_cache = self.get_user_permissions(user_obj)  # returns the
 set that is mutable
 user_obj._perm_cache.update(self.get_group_permissions(user_obj))  #
 therefore, the set is changed here
 }}}


 An alternative solution would be:
 {{{
 user_obj._perm_cache = set()
 user_obj._perm_cache.update(self.get_user_permissions(user_obj))
 user_obj._perm_cache.update(self.get_group_permissions(user_obj))
 }}}

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


Re: [Django] #28702: Field.db_type, Field.get_internal_type() and postgresql ::citext

2017-10-14 Thread Django
#28702: Field.db_type, Field.get_internal_type() and postgresql ::citext
--+
 Reporter:  Дилян Палаузов|Owner:  (none)
 Type:  Uncategorized |   Status:  new
Component:  contrib.postgres  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Mads Jensen):

 I think this issue highlights that the section `Custom database types` in
 `docs/howto/custom-model-fields.txt` needs to be adjusted, as `db_type` is
 referenced for `filter` and `exclude` but is not always used for casting.

 The test `test_lookup_cast` for PostgreSQL will also need to be adjusted.

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


Re: [Django] #28702: Field.db_type, Field.get_internal_type() and postgresql ::citext

2017-10-14 Thread Django
#28702: Field.db_type, Field.get_internal_type() and postgresql ::citext
--+
 Reporter:  Дилян Палаузов|Owner:  (none)
 Type:  Uncategorized |   Status:  new
Component:  contrib.postgres  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mads Jensen):

 * stage:  Unreviewed => Accepted


Comment:

 I think the change is necessary to make. The fact that `citext` doesn't
 behave like described in PostgreSQL's documentation is a flaw in the
 original implementation. I'm not sure about the "Backwards compatibility"
 concerns, but haven't other features been bug-fixed in minor releases as
 well, which would qualify for this as well?

 I checked the query for `array_field__contains=['joe']` which is casted
 correctly.

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


[Django] #28712: Add ability to apply separate attributes to ChoiceWidget options

2017-10-14 Thread Django
#28712: Add ability to apply separate attributes to ChoiceWidget options
---+--
   Reporter:  Stephen Swatman  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Forms|Version:  master
   Severity:  Normal   |   Keywords:  ChoiceWidget
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+--
 For `ChoiceWidget` objects the list of options is created in the
 `create_option` method. Currently, options created by this method can
 either inherit attributes from the parent widget or have no attributes at
 all but there is no way to separately assign attributes to options as far
 as I am aware. I would like to suggest introducing the ability to specify
 separate option attributes in the `ChoiceWidget` constructor which are
 applied only to the options in that widget.

 Even more powerful would be the ability to pass callables as attribute
 values which could dynamically compute attributes based on option
 attributes such as names and values.

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


Re: [Django] #28711: unordered_list template filter does not work with lazy translations

2017-10-14 Thread Django
#28711: unordered_list template filter does not work with lazy translations
-+--
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Jonas Haag):

 PR: https://github.com/django/django/pull/9240

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


Re: [Django] #28711: unordered_list template filter does not work with lazy translations

2017-10-14 Thread Django
#28711: unordered_list template filter does not work with lazy translations
-+--
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Description changed by Jonas Haag:

Old description:

> I would expect that the following assertion holds true:
>
> {{
> from django.utils.translation import ugettext_lazy as _
> from django.template.defaultfilters import unordered_list
>
> assert unordered_list(['', _('lazy')]) == unordered_list(['', 'lazy']))
> }}
>
> I.e., `unordered_list` handles lazy translations as if they were strings.
>
> This used to work in Django < 1.8, more specifically before the patch to
> this ticket: https://code.djangoproject.com/ticket/23260
>
> This bug exists in all versions 1.8–master.
>
> Pull request follows.

New description:

 I would expect that the following assertion holds true:

 {{{
 from django.utils.translation import ugettext_lazy as _
 from django.template.defaultfilters import unordered_list

 assert unordered_list(['', _('lazy')]) == unordered_list(['', 'lazy']))
 }}}

 I.e., `unordered_list` handles lazy translations as if they were strings.

 This used to work in Django < 1.8, more specifically before the patch to
 this ticket: https://code.djangoproject.com/ticket/23260

 This bug exists in all versions 1.8–master.

 Pull request follows.

--

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


[Django] #28711: unordered_list template filter does not work with lazy translations

2017-10-14 Thread Django
#28711: unordered_list template filter does not work with lazy translations
---+
   Reporter:  Jonas Haag   |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I would expect that the following assertion holds true:

 {{
 from django.utils.translation import ugettext_lazy as _
 from django.template.defaultfilters import unordered_list

 assert unordered_list(['', _('lazy')]) == unordered_list(['', 'lazy']))
 }}

 I.e., `unordered_list` handles lazy translations as if they were strings.

 This used to work in Django < 1.8, more specifically before the patch to
 this ticket: https://code.djangoproject.com/ticket/23260

 This bug exists in all versions 1.8–master.

 Pull request follows.

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