date:20171005

Re: [Django] #28685: Visual issue with Select2 input widget

2017-10-05 Thread Django

#28685: Visual issue with Select2 input widget
-+--
 Reporter:  Antoine Lorence  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 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:  1
-+--
Changes (by Antoine Lorence):

 * Attachment "chrome_2017-10-06_08-51-37.png" added.

 Chrome screenshot

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

Re: [Django] #28685: Visual issue with Select2 input widget

2017-10-05 Thread Django

#28685: Visual issue with Select2 input widget
-+--
 Reporter:  Antoine Lorence  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 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:  1
-+--
Changes (by Antoine Lorence):

 * Attachment "firefox_2017-10-06_08-52-32.png" added.

 Firefox screenshot example

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

Re: [Django] #28685: Visual issue with Select2 input widget

2017-10-05 Thread Django

#28685: Visual issue with Select2 input widget
-+--
 Reporter:  Antoine Lorence  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 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:  1
-+--
Changes (by Antoine Lorence):

 * Attachment "opera_2017-10-06_08-48-42.png" added.

 Opera screenshot

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

[Django] #28685: Visual issue with Select2 input widget

2017-10-05 Thread Django

#28685: Visual issue with Select2 input widget
---+
   Reporter:  Antoine Lorence  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  contrib.admin|Version:  2.0
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  1|
---+
 Playing with the new Django 2.0 feature, Select2 widget in admin, I
 noticed a bad position of the last element of the first line in the input
 box itself. Please see the 3 little screenshots attached, each one
 correspond to a different browser (Firefox, Chrome, Opera).
 I do not paste my code here, since I consider it's irrelevant, please ask
 if you need.

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

Re: [Django] #28636: Allow customizing the translation fallback language

2017-10-05 Thread Django

#28636: Allow customizing the translation fallback language
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:  Accepted
  internationalization, request  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I think that this makes sense, please make it a pull request after
 tests/docs have been added.
 Adding new settings is not something we are doing lightly, though, but I
 don't really see how we could avoid that for your use case. Maybe other
 reviewers will suggest ideas.

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

Re: [Django] #28423: Refer to GinIndex instead of RunSQL in ArrayField docs. Add GinIndex refs to HStoreField and JSONField docs.

2017-10-05 Thread Django

#28423: Refer to GinIndex instead of RunSQL in ArrayField docs. Add GinIndex 
refs
to HStoreField and JSONField docs.
-+-
 Reporter:  Phil Krylov  |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  postgres gin | Triage Stage:  Accepted
  arrayfield jsonfield hstorefield   |
  index  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by b. wit):

 * owner:  walter => (none)
 * status:  assigned => new


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

Re: [Django] #6148: Add generic support for database schemas

2017-10-05 Thread Django

#6148: Add generic support for database schemas
-+-
 Reporter:  Ian Kelly|Owner:  Anssi
 |  Kääriäinen
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle postgresql| Triage Stage:  Accepted
  mysql schemas  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Brenecki):

 * cc: Adam Brenecki (added)


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

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

[Django] #28684: Removing an index from an IntegerField causes a KeyError exception

2017-10-05 Thread Django

#28684: Removing an index from an IntegerField causes a KeyError exception
---+---
   Reporter:  Daniel Valdivia  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Uncategorized|Version:  1.11
   Severity:  Normal   |   Keywords:  migration
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
 While attempting to remove a `db_index` from a `IntegerField` through a
 migration the following way



 {{{

 class Migration(migrations.Migration):

 dependencies = [
 ('chat', '0005_auto_20170518_2103'),
 ]

 operations = [
 migrations.AlterField(
 model_name='channel',
 name='participant_count',
 field=models.IntegerField(blank=True, default=0),
 ),
 ]

 }}}


 A `KeyError: 'type'` is thrown



 {{{
 [standard:dpc] === Starting migration
 [standard:dpc] Operations to perform:
 [standard:dpc]   Apply all migrations: chat
 [standard:dpc] Running migrations:
 [standard:dpc]   Applying chat.0006_auto_20171005_1800...
 Traceback (most recent call last):
   File "./manage.py", line 15, in 
 execute_from_command_line(sys.argv)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 364, in
 execute_from_command_line
 utility.execute()
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 356, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/core/management/base.py", line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/core/management/base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django_tenants/management/commands/migrate_schemas.py", line 63,
 in handle
 executor.run_migrations(tenants=tenants)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django_tenants/migration_executors/standard.py", line 15, in
 run_migrations
 run_migrations(self.args, self.options, self.codename, schema_name)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django_tenants/migration_executors/base.py", line 30, in
 run_migrations
 MigrateCommand(stdout=stdout, stderr=stderr).execute(*args, **options)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/core/management/base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 204, in handle
 fake_initial=fake_initial,
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/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 "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/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 "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 244, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/db/migrations/migration.py", line 129, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/db/migrations/operations/fields.py", line 216, in
 database_forwards
 schema_editor.alter_field(from_model, from_field, to_field)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 515, in alter_field
 old_db_params, new_db_params, strict)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/db/backends/postgresql/schema.py", line 112, in
 _alter_field
 new_db_params, strict,
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 572, in _alter_field
 index_names = self._constraint_names(model, [old_field.column],
 index=True, type_=Index.suffix)
   File "/Users/dvaldivia/esdev/django/pyenv/lib/python2.7

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

2017-10-05 Thread Django

#28596: Oracle crashes with query with 2^16+1 bind parameters.
-+-
 Reporter:  Markus Stenberg  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Mariusz Felisiak ):

 In [changeset:"20d678542645deaac9c4b34eeb352b324a910fe2" 20d67854]:
 {{{
 #!CommitTicketReference repository=""
 revision="20d678542645deaac9c4b34eeb352b324a910fe2"
 [2.0.x] Fixed #28596 -- Fixed QuerySet.bulk_create() and cascade deletion
 crash on Oracle when using more than 65535 parameters.

 Thanks Tim Graham for the review.
 Backport of 1b823b8f182e8f31b8c9db281311ef718299eda7 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.679f68c3a07769226fb11c1659b8afff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

2017-10-05 Thread Django

#28596: Oracle crashes with query with 2^16+1 bind parameters.
-+-
 Reporter:  Markus Stenberg  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 GitHub ):

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


Comment:

 In [changeset:"1b823b8f182e8f31b8c9db281311ef718299eda7" 1b823b8]:
 {{{
 #!CommitTicketReference repository=""
 revision="1b823b8f182e8f31b8c9db281311ef718299eda7"
 Fixed #28596 -- Fixed QuerySet.bulk_create() and cascade deletion crash on
 Oracle when using more than 65535 parameters.

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

Re: [Django] #18416: Query fails when SimpleLazyObject evaluates to None

2017-10-05 Thread Django

Comment (by Ben Youngblut):

I also am curious if anyone came up with a good solution for this. I use
my own custom user object, and also a organization object that are both
attached to the request in middlewares as `SimpleLazyObjects` that have a
`None` value if they are not logged in or if the logged in user is not
part of an organization. Currently attaching to models is a real pain
{{{
Action.objects.create(
organization=request.organization if request.organization else None,
...
)
}}}
And what is really bad is that if you forget this and don't test with a
user without an organization it can easily go unnoticed!

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

Re: [Django] #27546: Replace hardcoded class names in repr-methods

2017-10-05 Thread Django

#27546: Replace hardcoded class names in __repr__-methods
-+-
 Reporter:  Mads Jensen  |Owner:  Adiyat
 Type:   |  Mubarak
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"ee7ab1b6e2439f79f3594925a6bf539aabaec8e1" ee7ab1b6]:
 {{{
 #!CommitTicketReference repository=""
 revision="ee7ab1b6e2439f79f3594925a6bf539aabaec8e1"
 Refs #27546 -- Replaced hardcoded class name in ForNode.__repr__().
 }}}

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

Re: [Django] #28682: Allow QuerySet.update() to return the IDs of the matched rows (was: QuerySet.update() : return the IDs of the matched rows)

2017-10-05 Thread Django

#28682: Allow QuerySet.update() to return the IDs of the matched rows
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Tim Graham):

 * status:  new => closed
 * resolution:   => wontfix
 * type:  Uncategorized => New feature


Comment:

 We can't change the return type of `QuerySet.update()` as proposed -- that
 would be backwards incompatible and it would make writing code that works
 across different databases more difficult. Perhaps #21461 would solve your
 use 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/072.73944ee01a1c32bff985b9b57240de25%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28683: GIS Length function generates incorrect queries when evaluated multiple times (was: Problems with the GIS Length annotation function (django.contrib.gis.db.models.functions.Length

2017-10-05 Thread Django

#28683: GIS Length function generates incorrect queries when evaluated multiple
times
--+--
 Reporter:  Kordian Kowalski  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  GIS   |  Version:  1.11
 Severity:  Normal|   Resolution:  duplicate
 Keywords:  gis geometry  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

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


Comment:

 Duplicate of #28353 which is fixed in Django 2.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/074.9af5ab82f655e091be918eb5c6bc684a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

2017-10-05 Thread Django

#28672: CheckboxSelectMultiple does not correctly bind to the form attribute 
passed
in when rendered outside its containing form
-+--
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.8
 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 Tim Graham):

 * resolution:  worksforme => invalid


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

Re: [Django] #28682: QuerySet.update() : return the IDs of the matched rows

2017-10-05 Thread Django

#28682: QuerySet.update() : return the IDs of the matched rows
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-
Description changed by Дилян Палаузов:

Old description:

> By coincidence all backends that can_return_ids_from_bulk_insert, which
> happens to be only Postgresql, can also return ids from UPDATE:
>
> UPDATE ... SET ... RETURNING id;
>
> * update QuerySet.update() to return the PKs of the updated rows
> * update the documentation of QuerySet.update(), stating the specific
> return type for PG
> * possibly rename can_return_ids_from_bulk_insert to can_return_ids or
> can_return_anything(_from_select_insert_update_delete)?

New description:

 By coincidence all backends that can_return_ids_from_bulk_insert, which
 happens to be only Postgresql, can also return ids from UPDATE:

 UPDATE ... SET ... RETURNING id;

 * update QuerySet.update() to return the PKs of the updated rows
 * update the documentation of QuerySet.update(), stating the specific
 return type for PG
 * possibly rename can_return_ids_from_bulk_insert to can_return_ids or
 can_return_anything(_from_select_insert_update_delete)?

 Like this:
 {{{
 diff --git a/django/db/models/sql/compiler.py
 b/django/db/models/sql/compiler.py
 --- a/django/db/models/sql/compiler.py
 +++ b/django/db/models/sql/compiler.py
 @@ -1230,11 +1230,11 @@ class SQLInsertCompiler(SQLCompiler):
  else:
  result.append("VALUES (%s)" % ",
 ".join(placeholder_rows[0]))
  params = [param_rows[0]]
 -col = "%s.%s" % (qn(opts.db_table), qn(opts.pk.column))
  r_fmt, r_params = self.connection.ops.return_insert_id()
  # Skip empty r_fmt to allow subclasses to customize behavior
 for
  # 3rd party backends. Refs #19096.
  if r_fmt:
 +col = "%s.%s" % (qn(opts.db_table), qn(opts.pk.column))
  result.append(r_fmt % col)
  params += [r_params]
  return [(" ".join(result),
 tuple(chain.from_iterable(params)))]
 @@ -1341,6 +1341,9 @@ class SQLUpdateCompiler(SQLCompiler):
  where, params = self.compile(self.query.where)
  if where:
  result.append('WHERE %s' % where)
 +if self.connection.features.can_return_ids_from_bulk_insert:
 +opts = self.query.get_meta()
 +result.append("RETURNING %s.%s" % (qn(opts.db_table),
 qn(opts.pk.column)))
  return ' '.join(result), tuple(update_params + params)

  def execute_sql(self, result_type):
 @@ -1352,6 +1355,8 @@ class SQLUpdateCompiler(SQLCompiler):
  """
  cursor = super().execute_sql(result_type)
  try:
 +if self.connection.features.can_return_ids_from_bulk_insert:
 # for Postgresql return the
 +return
 self.connection.ops.fetch_returned_insert_ids(cursor) # PKs of the matched
 columns
  rows = cursor.rowcount if cursor else 0
  is_empty = cursor is None
  finally:
 diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
 --- a/docs/ref/models/querysets.txt
 +++ b/docs/ref/models/querysets.txt
 @@ -2241,7 +2241,8 @@ retrieves the results and then checks if any were
 returned.

  Performs an SQL update query for the specified fields, and returns
  the number of rows matched (which may not be equal to the number of rows
 -updated if some rows already have the new value).
 +updated if some rows already have the new value).  On Postgresql it
 returns
 +instead a list with the primary keys of the matched rows.

  For example, to turn comments off for all blog entries published in 2010,
  you could do this::
 }}}

--

-- 
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.16bd7d86d0

Re: [Django] #18707: Test client doesn't allow testing 500 responses content

2017-10-05 Thread Django

#18707: Test client doesn't allow testing 500 responses content
---+
 Reporter:  ricardokirkner@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.6
 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 Stephane "Twidi" Angel):

 By the way I found a solution. I need this in a whole test case so:


 {{{#!python
 from unittest.mock import patch
 from django.test import TestCase

 class MyTestCase(TestCase):

 @classmethod
 def setUpClass(cls):
 super().setUpClass()
 cls.patched_signal =
 patch('django.core.signals.got_request_exception.connect')
 cls.patched_signal.start()

 @classmethod
 def tearDownClass(cls):
 cls.patched_signal.stop()
 super().tearDownClass()

 }}}

 With this the signal is not connected so the "problematic" code is not
 called.

 Note: this also works by patching
 `django.test.client.Client.store_exc_info`

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

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

2017-10-05 Thread Django

#28672: CheckboxSelectMultiple does not correctly bind to the form attribute 
passed
in when rendered outside its containing form
-+--
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.8
 Severity:  Normal   |   Resolution:  worksforme
 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 Dylan Young):

 Confirmed that it's an issue with crispy-forms==1.5.2 and not Django.
 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/068.8a0628b7ae66e4755e2cdaf969b82535%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

2017-10-05 Thread Django

#28672: CheckboxSelectMultiple does not correctly bind to the form attribute 
passed
in when rendered outside its containing form
-+--
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.8
 Severity:  Normal   |   Resolution:  worksforme
 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 Dylan Young):

 Hmmm... I'll dig deeper.  Maybe this is an issue with crispy-forms that
 needs to be submitted.

 As for your other note, this is in fact a data loss bug: every bit of data
 in that CheckboxSelectMultiple is lost on submit, barring an additional
 layer that saves dirty data in the form client-side for recovery.

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

Re: [Django] #28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) returns False

2017-10-05 Thread Django

#28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) 
returns
False
-+-
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Dylan Young):

 I don't have time to spin up a new Django environment to verify every bug
 when there are those familiar with the codebase that know if a bug has
 been fixed.

 If, on the other hand, no one know, I'm happy to follow up, as I stated in
 my comment.  If you don't want bugs submitted, don't have a public bug
 tracker.

 That said, glad it's been 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/068.19d6d36f8a05cccec17b4a5717352390%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18707: Test client doesn't allow testing 500 responses content

2017-10-05 Thread Django

#18707: Test client doesn't allow testing 500 responses content
---+
 Reporter:  ricardokirkner@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.6
 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 Stephane "Twidi" Angel):

 I like the proposal from `Peter Zsoldos`.

 Having to use selenium for this is a non-sense. The behavior of django in
 tests should be near the behavior in reality, else what is the point of
 tests...

 We have a logic based on the request headers to handle the error responses
 (including the 500) and we *have* to test it, like we test other errors.

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

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

Re: [Django] #18707: Test client doesn't allow testing 500 responses content

2017-10-05 Thread Django

#18707: Test client doesn't allow testing 500 responses content
---+
 Reporter:  ricardokirkner@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.6
 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 Stephane "Twidi" Angel):

 * cc: Stephane "Twidi" Angel (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/082.730e1e37764f1d800fbfbe6c622a013e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28683: Problems with the GIS Length annotation function (django.contrib.gis.db.models.functions.Length)

2017-10-05 Thread Django

#28683: Problems with the GIS Length annotation function
(django.contrib.gis.db.models.functions.Length)
--+--
 Reporter:  Kordian Kowalski  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  GIS   |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  gis geometry  | 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 Kordian Kowalski:

Old description:

> In my use case, I am creating a Prefetch object that includes an
> annotation with the GIS Length function as its base queryset.
> The prefetch object is then being reused in multiple requests.
> Only the first request succeeds, all subsequent requests fail with
> following error messages:
> `django.db.utils.ProgrammingError: function st_length(geography, boolean,
> boolean) does not exist`
> `django.db.utils.ProgrammingError: function st_length(geography, boolean,
> boolean, boolean) does not exist`
> `django.db.utils.ProgrammingError: function st_length(geography, boolean,
> boolean, boolean, boolean) does not exist`
> As you can see, there is an additional boolean value being passed in each
> request.
> I have narrowed down the issue to the following line
> (django/contrib/gis/db/models/functions.py:347) :
> {{{
> def as_postgresql(self, compiler, connection):
> (...)
> self.source_expressions.append(Value(self.spheroid))
> }}}
> The additional boolean seems to be appended to params list every time the
> prefetch object is compiled.
> Also it seems that the problem may be affecting only postgres backends.
>
> Steps to reproduce:
> - create a model with a `django.contrib.gis.db.models.GeometryField`
> - create a queryset with Length annotation: `qs =
> MyModel.objects.annotate(my_length=Length('geometry'))`
> - run `qs.all()` multiple times, all subsequent requests after the first
> one will fail with the aforementioned message.

New description:

 In my use case, I am creating a Prefetch object that includes an
 annotation with the GIS Length function as its base queryset.
 The prefetch object is then being reused in multiple requests.
 Only the first request succeeds, all subsequent requests fail with
 following error messages:
 `django.db.utils.ProgrammingError: function st_length(geography, boolean,
 boolean) does not exist`
 `django.db.utils.ProgrammingError: function st_length(geography, boolean,
 boolean, boolean) does not exist`
 `django.db.utils.ProgrammingError: function st_length(geography, boolean,
 boolean, boolean, boolean) does not exist`
 As you can see, there is an additional boolean value being passed in each
 request.
 I have narrowed down the issue to the following line
 (django/contrib/gis/db/models/functions.py:347) :
 {{{
 def as_postgresql(self, compiler, connection):
 (...)
 self.source_expressions.append(Value(self.spheroid))
 }}}
 The additional boolean seems to be appended to params list every time the
 prefetch object is compiled.
 Also it seems that the problem may be affecting only postgres backends.

 Steps to reproduce:
 - create a model with a `django.contrib.gis.db.models.GeometryField`
 (called `geometry` for this example)
 - create a queryset with Length annotation: `qs =
 MyModel.objects.annotate(my_length=Length('geometry'))`
 - run `qs.all()` multiple times, all subsequent requests after the first
 one will fail with the aforementioned message.

--

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

[Django] #28683: Problems with the GIS Length annotation function (django.contrib.gis.db.models.functions.Length)

2017-10-05 Thread Django

#28683: Problems with the GIS Length annotation function
(django.contrib.gis.db.models.functions.Length)
+--
   Reporter:  Kordian Kowalski  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  GIS   |Version:  1.11
   Severity:  Normal|   Keywords:  gis geometry
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
 In my use case, I am creating a Prefetch object that includes an
 annotation with the GIS Length function as its base queryset.
 The prefetch object is then being reused in multiple requests.
 Only the first request succeeds, all subsequent requests fail with
 following error messages:
 `django.db.utils.ProgrammingError: function st_length(geography, boolean,
 boolean) does not exist`
 `django.db.utils.ProgrammingError: function st_length(geography, boolean,
 boolean, boolean) does not exist`
 `django.db.utils.ProgrammingError: function st_length(geography, boolean,
 boolean, boolean, boolean) does not exist`
 As you can see, there is an additional boolean value being passed in each
 request.
 I have narrowed down the issue to the following line
 (django/contrib/gis/db/models/functions.py:347) :
 {{{
 def as_postgresql(self, compiler, connection):
 (...)
 self.source_expressions.append(Value(self.spheroid))
 }}}
 The additional boolean seems to be appended to params list every time the
 prefetch object is compiled.
 Also it seems that the problem may be affecting only postgres backends.

 Steps to reproduce:
 - create a model with a `django.contrib.gis.db.models.GeometryField`
 - create a queryset with Length annotation: `qs =
 MyModel.objects.annotate(my_length=Length('geometry'))`
 - run `qs.all()` multiple times, all subsequent requests after the first
 one will fail with the aforementioned message.

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

Re: [Django] #28636: Allow customizing the translation fallback language (was: Allow customizing the fallback language from the locale middleware)

2017-10-05 Thread Django

#28636: Allow customizing the translation fallback language
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:  Accepted
  internationalization, request  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  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.3ba18a797d626c1f92e09e4c315379db%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28636: Allow customizing the fallback language from the locale middleware

2017-10-05 Thread Django

#28636: Allow customizing the fallback language from the locale middleware
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:  Accepted
  internationalization, request  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Denis Anuschewski):

 I think I have an even better approach:
 
https://github.com/denisiko/django/commit/faeb8a4db34121a9cfe61b281849b084dfbe6625

 Of course there is missing documentation and unit tests at this point. But
 first I would like to get some feedback. What do you think Claude Paroz?

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

Re: [Django] #28685: Visual issue with Select2 input widget

Re: [Django] #28685: Visual issue with Select2 input widget

Re: [Django] #28685: Visual issue with Select2 input widget

[Django] #28685: Visual issue with Select2 input widget

Re: [Django] #28636: Allow customizing the translation fallback language

Re: [Django] #28423: Refer to GinIndex instead of RunSQL in ArrayField docs. Add GinIndex refs to HStoreField and JSONField docs.

Re: [Django] #6148: Add generic support for database schemas

[Django] #28684: Removing an index from an IntegerField causes a KeyError exception

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

Re: [Django] #18416: Query fails when SimpleLazyObject evaluates to None

Re: [Django] #27546: Replace hardcoded class names in repr-methods

Re: [Django] #28682: Allow QuerySet.update() to return the IDs of the matched rows (was: QuerySet.update() : return the IDs of the matched rows)

Re: [Django] #28683: GIS Length function generates incorrect queries when evaluated multiple times (was: Problems with the GIS Length annotation function (django.contrib.gis.db.models.functions.Length

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

Re: [Django] #28682: QuerySet.update() : return the IDs of the matched rows

Re: [Django] #18707: Test client doesn't allow testing 500 responses content

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

Re: [Django] #28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) returns False

Re: [Django] #18707: Test client doesn't allow testing 500 responses content

Re: [Django] #18707: Test client doesn't allow testing 500 responses content

Re: [Django] #28683: Problems with the GIS Length annotation function (django.contrib.gis.db.models.functions.Length)

[Django] #28683: Problems with the GIS Length annotation function (django.contrib.gis.db.models.functions.Length)

Re: [Django] #28636: Allow customizing the translation fallback language (was: Allow customizing the fallback language from the locale middleware)

Re: [Django] #28636: Allow customizing the fallback language from the locale middleware

26 matches

Site Navigation

Mail list logo

Footer information