Re: [Django] #27217: makemigrations crashes with "'SpatialRefSysMixin' has no attribute '_meta'" on PostGIS

[Django]

#27217: makemigrations crashes with "'SpatialRefSysMixin' has no attribute 
'_meta'"
on PostGIS
-+
 Reporter:  MVSatish |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by MVSatish):

 Hi,

 Is there a patch for this bug?

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

Re: [Django] #27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False

[Django]

#27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False
-+-
 Reporter:  strycore |Owner:
 Type:   |  alasdairnicol
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  1.10
  checks)|
 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:"190cd0e49f967d2ec0b6c50a63f0d58d13319611" 190cd0e4]:
 {{{
 #!CommitTicketReference repository=""
 revision="190cd0e49f967d2ec0b6c50a63f0d58d13319611"
 [1.10.x] Fixed #27238 -- Disabled check_pattern_startswith_slash if
 settings.APPEND_SLASH=False.

 Thanks strycore for the report and timgraham for suggesting the
 solution.

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

Re: [Django] #27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False

[Django]

#27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False
-+-
 Reporter:  strycore |Owner:
 Type:   |  alasdairnicol
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  1.10
  checks)|
 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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"911d9f4ed1a39f945769b7198a419850378f9824" 911d9f4e]:
 {{{
 #!CommitTicketReference repository=""
 revision="911d9f4ed1a39f945769b7198a419850378f9824"
 Fixed #27238 -- Disabled check_pattern_startswith_slash if
 settings.APPEND_SLASH=False.

 Thanks strycore for the report and timgraham for suggesting the
 solution.
 }}}

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

Re: [Django] #18392: Use utf8mb4 encoding with MySQL 5.5

[Django]

#18392: Use utf8mb4 encoding with MySQL 5.5
-+-
 Reporter:  EmilStenstrom|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  utf8mb4 mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 The skips for the tests added in 1a9f6db5ffd2d5e71d73340ab59476572e05a728
 should be removed or modified when completing this ticket. Should we skip
 them conditionally based on the test charset or should we require running
 the MySQL tests with utf8mb4?

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

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

Re: [Django] #27219: Emoji don't work in TextFields using Oracle backend

[Django]

#27219: Emoji don't work in TextFields using Oracle backend
-+-
 Reporter:  dmedvinsky   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle, unicode  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1a9f6db5ffd2d5e71d73340ab59476572e05a728" 1a9f6db5]:
 {{{
 #!CommitTicketReference repository=""
 revision="1a9f6db5ffd2d5e71d73340ab59476572e05a728"
 Fixed #27219 -- Changed cx_Oracle client encoding to AL32UTF8 to allow
 4-byte characters.
 }}}

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

Re: [Django] #27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False

[Django]

#27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False
-+-
 Reporter:  strycore |Owner:
 Type:   |  alasdairnicol
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  1.10
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by alasdairnicol):

 * status:  new => assigned
 * owner:  nobody => alasdairnicol
 * has_patch:  0 => 1


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

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

Re: [Django] #27244: Incorrect thousand separator for the Greek locale (el)

[Django]

#27244: Incorrect thousand separator for the Greek locale (el)
--+
 Reporter:  kappataumu|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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 claudep):

 * has_patch:  0 => 1
 * version:  1.10 => 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/068.f0517372ff394429f2dd4d4653f86cbf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

[Django]

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:  Accepted
  aggregate annotate |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * cc: charettes (added)
 * version:  1.10 => master
 * stage:  Unreviewed => Accepted


Comment:

 > Before the annotate() call, add only() naming all the fields. Or maybe
 even drop the PK, if that makes sense.

 The trick `only()` won't work as `pk` is always implicitly selected
 (`only('field')` == `only('field', 'pk')`).

 The only solution I can think of is disabling the optimization for
 unmanaged models but the real issue here is really that unmanaged models
 are not meant to be used to deal with database views. The fact that Django
 enforces the presence of a primary key and views are not allowed to have
 one really highlights the conceptual clash.

 As Django doesn't provide any way to interact with views and even suggests
 `managed`
 
[https://docs.djangoproject.com/en/1.10/ref/models/options/#django.db.models.Options.managed
 can be used for this purpose] I think we should simply disable the
 optimization for this specific 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/063.57b88374a219e922135d9a7d29c18513%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26166: Accessing a widget via an index on a BoundField results in unnecessary iteration

[Django]

#26166: Accessing a widget via an index on a BoundField results in unnecessary
iteration
--+
 Reporter:  seddonym  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Forms |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:  forms, boundfield | 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):

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


Comment:

 Please reopen if not.

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

Re: [Django] #27248: Running migrations one-by-one fails after adding django.contrib.sites to INSTALLED_APPS.

[Django]

#27248: Running migrations one-by-one fails after adding django.contrib.sites to
INSTALLED_APPS.
-+-
 Reporter:  doctoryes|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.sites|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migrations   | Triage Stage:
  django_site|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I believe this is fixed in Django 1.10 by
 61a16e02702fff4665969388f3b61af8cb1a20ae. If not, please reopen.

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

[Django] #27248: Running migrations one-by-one fails after adding django.contrib.sites to INSTALLED_APPS.

[Django]

#27248: Running migrations one-by-one fails after adding django.contrib.sites to
INSTALLED_APPS.
---+
 Reporter:  doctoryes  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.sites  |Version:  1.8
 Severity:  Normal |   Keywords:  migrations django_site
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 An application we've written added django.contrib.sites to its
 INSTALLED_APPS. In the same release, other migrations were generated that
 needed to be applied. The dependency-ordered migrations list at this point
 pre-migration follows:
 {{{
 migrations:
 - [taggit, 0002_auto_20150616_2121]
 - [course_metadata, 0017_auto_20160815_2135]
 - [course_metadata, 0018_auto_20160815_2252]
 - [sites, 0001_initial]
 - [django_comments, 0001_initial]
 - [django_comments, 0002_update_user_email_field_length]
 - [django_comments, 0003_add_submit_date_index]
 - [publisher_comments, 0001_initial]
 }}}
 We then attempted to run these migrations one-by-one via {{{python
 ./manage.py  }}} commands. (Why? To better record which
 migrations succeeded, which one failed, and which migrations remain
 unapplied, since this migration process runs in an automated pipeline.)
 The first specific app/migration migrate failed with a stack nearly the
 same as the one here:

 https://code.djangoproject.com/ticket/24524#comment:12

 The problem is that the sites code assumed that after being added to
 INSTALLED_APPS, a {{{python ./manage.py migrate}}} command would be run to
 execute all migrations together - and *then* catch a post-migrate signal
 which calls {{{create_default_site}}}. Running individual migrations does
 not work when an application is in this state.

 It looks like some code is in place to attempt to prevent this error, but
 it's either incorrect or not working:

 
https://github.com/django/django/blob/stable/1.8.x/django/contrib/sites/management.py#L12-L18

 The workaround: Issue a {{{python ./manage.py migrate}}} command to exit
 this state. However, the workaround shouldn't be necessary.

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

Re: [Django] #27245: can't revert migration with index_together with one field

[Django]

#27245: can't revert migration with index_together with one field
-+-
 Reporter:  rm_  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (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 timgraham):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => Database layer (models, ORM)


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

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

Re: [Django] #27227: Full text search by UUIDField returns DataError

[Django]

#27227: Full text search by UUIDField returns DataError
-+-
 Reporter:  danclaudiupop|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  UUIDField fts| Triage Stage:
  postgres   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I'm not sure. Maybe you can send a pull request to give an idea of what
 the patch allows?

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

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

Re: [Django] #27231: Initialize forms in ModelAdmin like View (i.e. add get_form_kwargs to contrib.admin)

[Django]

#27231: Initialize forms in ModelAdmin like View (i.e. add get_form_kwargs to
contrib.admin)
--+--
 Reporter:  thauk-copperleaf  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.admin |  Version:  1.10
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

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


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

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

Re: [Django] #27247: Official way to create custom admin commands with subcommands in py2 / py3

[Django]

#27247: Official way to create custom admin commands with subcommands in py2 / 
py3
-+-
 Reporter:  stephanm |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 It's better to ask "is it a bug?" questions on our support channels. See
 TicketClosingReasons/UseSupportChannels. I'm not aware of any
 documentation about subcommands. Maybe it makes sense to add something.
 I'm not sure if that topic is a more Python related than Django related
 though. If you learn something, think it's appropriate for the Django
 docs, and want to write it up, feel free to open a ticket.

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

Re: [Django] #27246: Factor out input template in ClearableFileInput and document template class attributes

[Django]

#27246: Factor out input template in ClearableFileInput and document template 
class
attributes
-+--
 Reporter:  mpauly   |Owner:  mpauly
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

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


Comment:

 We're targeting template-based widget rendering (#15667) for Django 1.11
 which I believe obsoletes this. Feel free to take at the latest pull
 request there and offer feedback.

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

Re: [Django] #27246: Factor out input template in ClearableFileInput and document template class attributes

[Django]

#27246: Factor out input template in ClearableFileInput and document template 
class
attributes
-+--
 Reporter:  mpauly   |Owner:  mpauly
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  1.10
 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 mpauly):

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


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

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

[Django] #27247: Official way to create custom admin commands with subcommands in py2 / py3

[Django]

#27247: Official way to create custom admin commands with subcommands in py2 / 
py3
+
 Reporter:  stephanm|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Hi,

 I found a example on the internet showing how to create  custom admin
 commands with subcommands.

 My app is named "repo", I use django 1.10.1 on Windows and I am just
 trying
 to migrate from python 2.7.12 (32bit) to python 3.5.2 (64bit) on windows 7
 64bit.

 I did also a big switch from optparse to argparse since optparse is gone
 in django 1.10.

 The file repo_sample.py looks like:
 {{{#!py
 # -*- coding: utf-8 -*-
 from __future__ import absolute_import
 from __future__ import division
 from __future__ import print_function
 from __future__ import unicode_literals
 from django.core.management.base import BaseCommand
 import argparse


 class Command(BaseCommand):

 help = "this is a sample"

 def handle(self, *args, **options):
 if "command" in options:
 print("command: %s" % options["command"])
 else:
 print("no command")

 def add_arguments(self, parser):
 parser.formatter_class = argparse.RawDescriptionHelpFormatter
 subparsers = parser.add_subparsers(metavar='command',
dest='command',
help='sub-command help')
 parent_parser = argparse.ArgumentParser(add_help=False)

 subparsers.add_parser("command_1", parents=[parent_parser],
 cmd=self,
   help="This is command_1 no subcommands")
 parser_service = subparsers.add_parser("service",
 parents=[parent_parser], cmd=self,
help="Manage a windows
 service")
 parser_service.add_argument("serviceCmd", choices=["install",
 "delete", "start", "stop", "status"],
  help="Create or deletes a windows
 service..")

 }}}

 Now there is a difference if I run it with python 2 or python 3:
 {{{
 D:\util>manage.py repo_sample
 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC v.1500 32 bit
 (Intel)]
 usage: manage.py repo_sample [-h] [--version] [-v {0,1,2,3}]
  [--settings SETTINGS] [--pythonpath
 PYTHONPATH]
  [--traceback] [--no-color]
  command ...
 manage.py repo_sample: error: too few arguments

 D:\util>py -3 manage.py repo_sample
 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit
 (AMD64)]
 command: None

 D:\util>
 }}}

 As you see, the first call with python 2 gives an error while the python 3
 call behaves differently,
 but I think it should at least behave the same way (so I marked it as
 bug).

 Now I am not sure if argparse behaves differently between python 2.7 and
 python 3.5 and if I made an error.

 But here is my question(s):

  - What is the official ("correct") way to create  custom admin commands
 with subcommands?
  - Do you have some examples in the docs? (I didnt find something)

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

Re: [Django] #27245: can't revert migration with index_together with one field

[Django]

#27245: can't revert migration with index_together with one field
---+--
 Reporter:  rm_|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by rm_):

 If Meta.indexes is supposed to be a generic way to add indexes, then the
 single field for an index is a normal case and there should be no issue.

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

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

[Django] #27246: Factor out input template in ClearableFileInput and document template class attributes

[Django]

#27246: Factor out input template in ClearableFileInput and document template 
class
attributes
-+
 Reporter:  mpauly   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  1.10
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 `ClearableFileInput` uses a template variable in its `render()`
 implementation (see
 https://github.com/django/django/blob/master/django/forms/widgets.py#L405)
 that I would like to factor out as a class attribute.

 This would allow to change the appearance of the 'Select file' button for
 `ClearableFileInput`, by e.g. wrapping it in a div and adding a span. For
 normal `FileInput` that is already possible by overwriting the render
 method, however for `ClearableFileInput` this gets comparably ugly.
 This would be in line with having the other template strings as class
 attributes.

 Also I believe it would be good to document the multiple `template_*`
 class attributes.

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

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

Re: [Django] #27245: can't revert migration with index_together with one field

[Django]

#27245: can't revert migration with index_together with one field
---+--
 Reporter:  rm_|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 `Meta.index_together` is headed toward deprecation in favor of
 `Meta.indexes` (new feature in 1.11). Can the issue be reproduce there? If
 not, I think we can close this as wontfix.

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

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

Re: [Django] #27245: can't revert migration with index_together with one field

[Django]

#27245: can't revert migration with index_together with one field
---+--
 Reporter:  rm_|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by rm_):

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


Old description:

> With django 1.8.14 i added a composite index with one field (lame,
> sorry!) because the field is from an abstract model and it seemed the
> cleanest way to handle that:
>
> {{{
> +class Meta:
> +index_together = ['owner']
> }}}
>
> The migrations got created and applied finely:
> {{{
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import migrations, models
>

> class Migration(migrations.Migration):
>
> dependencies = [
> ('foobar', '0002_auto_20160315_1805'),
> ]
>
> operations = [
> migrations.AlterIndexTogether(
> name='answer',
> index_together=set([('owner',)]),
> ),
> ]
> }}}
>
> Problem is i can't revert the migration:
>
> {{{
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/venv/local/lib/python2.7/site-
> packages/django/core/management/__init__.py", line 354, in
> execute_from_command_line
> utility.execute()
>   File "/venv/local/lib/python2.7/site-
> packages/django/core/management/__init__.py", line 346, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/venv/local/lib/python2.7/site-
> packages/django/core/management/base.py", line 394, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/venv/local/lib/python2.7/site-
> packages/django/core/management/base.py", line 445, in execute
> output = self.handle(*args, **options)
>   File "/venv/local/lib/python2.7/site-
> packages/django/core/management/commands/migrate.py", line 222, in handle
> executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
>   File "/venv/local/lib/python2.7/site-
> packages/django/db/migrations/executor.py", line 112, in migrate
> self.unapply_migration(states[migration], migration, fake=fake)
>   File "/venv/local/lib/python2.7/site-
> packages/django/db/migrations/executor.py", line 168, in
> unapply_migration
> state = migration.unapply(state, schema_editor)
>   File "/venv/local/lib/python2.7/site-
> packages/django/db/migrations/migration.py", line 162, in unapply
> operation.database_backwards(self.app_label, schema_editor,
> from_state, to_state)
>   File "/venv/local/lib/python2.7/site-
> packages/django/db/migrations/operations/models.py", line 415, in
> database_backwards
> return self.database_forwards(app_label, schema_editor, from_state,
> to_state)
>   File "/venv/local/lib/python2.7/site-
> packages/django/db/migrations/operations/models.py", line 411, in
> database_forwards
> getattr(new_model._meta, self.option_name, set()),
>   File "/venv/local/lib/python2.7/site-
> packages/django/db/backends/base/schema.py", line 336, in
> alter_index_together
> self._delete_composed_index(model, fields, {'index': True},
> self.sql_delete_index)
>   File "venv/local/lib/python2.7/site-
> packages/django/db/backends/base/schema.py", line 349, in
> _delete_composed_index
> ", ".join(columns),
> ValueError: Found wrong number (2) of constraints for
> cicero_academy_answeracademy(owner_id)
> }}}
>
> So the easy way to fix this is to don't permit te creation of a migration
> with less than two fields. OTOH it would be quite cool to use the non
> composite way of removing an index if the constraints are not enough.
> Whatever you decide i can spend some time on the fix.

New description:

 With django 1.8.14 and postgresql 9.4 i added a composite index with one
 field (lame, sorry!) because the field is from an abstract model and it
 seemed the cleanest way to handle that:

 {{{
 +class Meta:
 +index_together = ['owner']
 }}}

 The migrations got created and applied finely:
 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import migrations, models


 class Migration(migrations.Migration):

 dependencies = [
 ('foobar', '0002_auto_20160315_1805'),
 ]

 operations = [
 migrations.AlterIndexTogether(
 name='answer',
 index_together=set([('owner',)]),
 ),
 ]
 }}}

 Problem is i can't revert the migration:

 {{{
   File "manage.py", line 

[Django] #27245: can't revert migration with index_together with one field

[Django]

#27245: can't revert migration with index_together with one field
---+
 Reporter:  rm_|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 With django 1.8.14 i added a composite index with one field (lame, sorry!)
 because the field is from an abstract model and it seemed the cleanest way
 to handle that:

 {{{
 +class Meta:
 +index_together = ['owner']
 }}}

 The migrations got created and applied finely:
 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import migrations, models


 class Migration(migrations.Migration):

 dependencies = [
 ('foobar', '0002_auto_20160315_1805'),
 ]

 operations = [
 migrations.AlterIndexTogether(
 name='answer',
 index_together=set([('owner',)]),
 ),
 ]
 }}}

 Problem is i can't revert the migration:

 {{{
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/venv/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 354, in
 execute_from_command_line
 utility.execute()
   File "/venv/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 346, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/venv/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 394, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/venv/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 445, in execute
 output = self.handle(*args, **options)
   File "/venv/local/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 222, in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File "/venv/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 112, in migrate
 self.unapply_migration(states[migration], migration, fake=fake)
   File "/venv/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 168, in unapply_migration
 state = migration.unapply(state, schema_editor)
   File "/venv/local/lib/python2.7/site-
 packages/django/db/migrations/migration.py", line 162, in unapply
 operation.database_backwards(self.app_label, schema_editor,
 from_state, to_state)
   File "/venv/local/lib/python2.7/site-
 packages/django/db/migrations/operations/models.py", line 415, in
 database_backwards
 return self.database_forwards(app_label, schema_editor, from_state,
 to_state)
   File "/venv/local/lib/python2.7/site-
 packages/django/db/migrations/operations/models.py", line 411, in
 database_forwards
 getattr(new_model._meta, self.option_name, set()),
   File "/venv/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 336, in
 alter_index_together
 self._delete_composed_index(model, fields, {'index': True},
 self.sql_delete_index)
   File "venv/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 349, in
 _delete_composed_index
 ", ".join(columns),
 ValueError: Found wrong number (2) of constraints for
 cicero_academy_answeracademy(owner_id)
 }}}

 So the easy way to fix this is to don't permit te creation of a migration
 with less than two fields. OTOH it would be quite cool to use the non
 composite way of removing an index if the constraints are not enough.
 Whatever you decide i can spend some time on 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/046.aa4ca75ac3212cc6db08be62856c95f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20705: Allow customizing the email field name for PasswordResetForm

[Django]

#20705: Allow customizing the email field name for PasswordResetForm
--+-
 Reporter:  Cloudream |Owner:  mlevental
 Type:  New feature   |   Status:  assigned
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 timgraham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 I left some ideas for improvement on the
 [https://github.com/django/django/pull/7265 PR].

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

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

Re: [Django] #27156: Setting HttpRequest.encoding should clear GET

[Django]

#27156: Setting HttpRequest.encoding should clear GET
---+
 Reporter:  timgraham  |Owner:  PREM1980
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  1.10
 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 PREM1980):

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


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

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

Re: [Django] #27165: CreateModel without indexes always includes options={'indexes': []}

[Django]

#27165: CreateModel without indexes always includes options={'indexes': []}
--+
 Reporter:  timgraham |Owner:  akki
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  1.11  | 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:"358c6f21f8107d830a2f285d49d69bac24a98bdd" 358c6f21]:
 {{{
 #!CommitTicketReference repository=""
 revision="358c6f21f8107d830a2f285d49d69bac24a98bdd"
 Fixed #27165 -- Removed unnecessary CreateModel(... 'indexes': []) in
 migrations.
 }}}

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

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

Re: [Django] #27095: Queries involving postgres Array fields can't include expressions as elements

[Django]

#27095: Queries involving postgres Array fields can't include expressions as
elements
--+
 Reporter:  MatthewWilkes |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  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 PREM1980):

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

Re: [Django] #27244: Incorrect thousand separator for the Greek locale (el)

[Django]

#27244: Incorrect thousand separator for the Greek locale (el)
--+
 Reporter:  kappataumu|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.10
 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 kappataumu):

 PR sent:  https://github.com/django/django/pull/7267. I've pinged @spapas
 for a +1.

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

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

Re: [Django] #27244: Incorrect thousand separator for the Greek locale (el)

[Django]

#27244: Incorrect thousand separator for the Greek locale (el)
--+
 Reporter:  kappataumu|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.10
 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:

 Sure, send a PR and have a colleague give it a +1.

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

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

[Django] #27244: Incorrect thousand separator for the Greek locale (el)

[Django]

#27244: Incorrect thousand separator for the Greek locale (el)
--+
 Reporter:  kappataumu|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The thousand separator for the Greek locale is a dot ("."), not a non-
 breaking space ("\xa0"). Other than being Greek, one can verify this like
 so:

 {{{
 import locale
 locale.setlocale(locale.LC_ALL, "el_GR.UTF-8")
 print(locale.nl_langinfo(locale.THOUSEP))
 }}}

 A related issue (https://code.djangoproject.com/ticket/23967) previously
 fixed a number of incorrect settings (see PR and discussion at
 https://github.com/django/django/pull/3696) but apparently this slipped
 through. Interestingly, the correct thousand separator is also documented
 in one of the links shared (see http://www.localeplanet.com/java/el-GR/).

 I can submit a PR if desired.

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

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

Re: [Django] #27234: Clarify the type of the django.server logger's 'request' extra context (was: django.request receives a socket object rather than a request object in logging)

[Django]

#27234: Clarify the type of the django.server logger's 'request' extra context
-+-
 Reporter:  ben-whale|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  django.request   | Triage Stage:  Accepted
  runserver WSGIRequest socket   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted
 * type:  Bug => Cleanup/optimization


Comment:

 I think updating [https://docs.djangoproject.com/en/1.10/topics/logging
 /#django-server the docs] is the correct resolution.

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

[Django]

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:
  aggregate annotate |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jaap3):

 Using only seems to have no effect on the GROUP BY clause.

 I am not sure what you mean by "drop the PK", Django doesn't allow models
 without a field marked as `primary_key` and will add one if you don't
 specify one.

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

Re: [Django] #27219: Emoji don't work in TextFields using Oracle backend

[Django]

#27219: Emoji don't work in TextFields using Oracle backend
-+-
 Reporter:  dmedvinsky   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, unicode  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False (was: Removal of check_pattern_startswith_slash)

[Django]

#27238: Disable check_pattern_startswith_slash if settings.APPEND_SLASH=False
--+
 Reporter:  strycore  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (System checks)  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted
 * easy:  0 => 1


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

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

Re: [Django] #27243: Make reverse_dict.getlist work with fully qualified module names

[Django]

#27243: Make reverse_dict.getlist work with fully qualified module names
-+--
 Reporter:  erob |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by timgraham):

 I guess you might be running into problems because Django 1.10 removed
 support for string `view` arguments in `url()`
 (a25d3ce007b90a0516aed54fc1c5a16510a290e4 and/or
 785cc71d5b3300e2702b0b2fc7316e58ca70b563). I'm not sure whether or not we
 can accommodate the use case, but as-is your patch crashes the test suite.

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

[Django]

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:
  aggregate annotate |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by shaib):

 * cc: shaib (added)


Comment:

 Possible workaround (no time to test ATM): Before the `annotate()` call,
 add `only()` naming all the fields. Or maybe even drop the PK, if that
 makes sense.

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

[Django]

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:
  aggregate annotate |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jaap3):

 Unfortunately I don't have a solution that would just make things work.

 One of the underlying issues here is that Django has never officially
 supported database views in the first place so I don't know how much
 effort should be put into making this work again. The fact that this used
 to work in the past was pure coincidence anyway.

 Come to think of it, this problem might not just limited to database
 views. I believe any (unmanged) model that hasn't set a `PRIMARY KEY`
 constraint at the database level could trigger this issue.

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

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

Re: [Django] #27243: Make reverse_dict.getlist work with fully qualified module names

[Django]

#27243: Make reverse_dict.getlist work with fully qualified module names
-+--
 Reporter:  erob |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by erob):

 I want to make Django 1.10 fully compatible with my urlpatterns
 configuration. I use a custom urlresolver module (notmm.utils.urlmap) to
 allow mapping url patterns to named views:
 {{{
 from notmm.utils.urlmap import RegexURLMap
 urlpatterns = RegexURLMap()
 urlpatterns.add_routes('foobar.views',
  (r'^index.html$', 'index'),
 )
 }}}
 add_routes() automatically create a fully qualified callback object to
 ensure the view function is a callable. However, Django doesn't handle
 fully qualified module names in reverse() without this patch.

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

Re: [Django] #27238: Removal of check_pattern_startswith_slash

[Django]

#27238: Removal of check_pattern_startswith_slash
-+-
 Reporter:  strycore |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (System |  Version:  1.10
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by alasdairnicol):

 We could change the `check_resolver` method so that it passes the regex
 when called recursively.

  * If we call  `check_resolver(resolver, r'^dashboard')` then we shouldn't
 run `check_pattern_startswith_slash`. This would prevent the false
 positives for strycore's example.
  * If we call `check_resolver(resolver, r'^dashboard/')` or
 `check_resolver(resolver, None)` (initial call) then it is ok to run
 `check_pattern_startswith_slash`.

 I haven't tried writing a patch for this yet. Modifying the check_resolver
 method like this might be overly complex. I like the simplicity of
 checking `settings.APPEND_SLASH` as Tim suggested.

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

Re: [Django] #27243: Make reverse_dict.getlist work with fully qualified module names

[Django]

#27243: Make reverse_dict.getlist work with fully qualified module names
-+--
 Reporter:  erob |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

 * needs_tests:  0 => 1


Comment:

 Can you please summarize the discussion and explain what use case this
 solves? Tests are also needed.

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

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

Re: [Django] #27243: Make reverse_dict.getlist work with fully qualified module names

[Django]

#27243: Make reverse_dict.getlist work with fully qualified module names
-+--
 Reporter:  erob |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by erob):

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


Comment:

 For discussion of this issue see: https://groups.google.com/forum/#!topic
 /django-users/FVH1sA_j1tM

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

[Django] #27243: Make reverse_dict.getlist work with fully qualified module names

[Django]

#27243: Make reverse_dict.getlist work with fully qualified module names
-+
 Reporter:  erob |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Core (URLs)  |Version:  1.10
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 The function _reverse_with_prefix in django/urls/resolvers.py  doesn't
 handle fully qualified module names. This patch ensure that reverse()
 works 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/047.423a3b6b4033cfb19e6b282b66e0d1e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27243: Make reverse_dict.getlist work with fully qualified module names

[Django]

#27243: Make reverse_dict.getlist work with fully qualified module names
-+
 Reporter:  erob |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Core (URLs)  |Version:  1.10
 Severity:  Normal   | Resolution:
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  1|  Easy pickings:  0
UI/UX:  0|
-+
Changes (by erob):

 * Attachment "resolvers.diff" added.


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

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

Re: [Django] #27240: Passing custom parameters to formset forms in admin

[Django]

#27240: Passing custom parameters to formset forms in admin
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, form, | Triage Stage:
  formset, parameter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by arogachev):

 @knbk Thanks, I think this can be also done in `def
 get_formsets_with_inlines(self, request, obj=None):` or `def
 get_inline_formsets(self, request, formsets, inline_instances, obj=None):`
 in regular `admin.ModelAdmin`.

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

[Django]

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:
  aggregate annotate |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Do you have a solution in mind?

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

Re: [Django] #27240: Passing custom parameters to formset forms in admin

[Django]

#27240: Passing custom parameters to formset forms in admin
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, form, | Triage Stage:
  formset, parameter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by knbk):

 `InlineModelAdmin` has a `get_formset()` method in which you can do the
 same.

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

Re: [Django] #27240: Passing custom parameters to formset forms in admin

[Django]

#27240: Passing custom parameters to formset forms in admin
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, form, | Triage Stage:
  formset, parameter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by arogachev):

 @knbk I understand that approach with class attribute is not elegant. As
 for your soultion - I need to do it for formset form (`AttachmentForm`),
 not admin form. Admin form is different in my case and called
 `EnterpriseAdminForm`. Formset has no `get_form` related method, only
 `get_form_kwargs(self, index):` method. which has no reference to
 `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/067.09da67cf33a1ac61a1021bf79c5a102b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27225: Cache-Control's max-age doesn't match Expires for responses taken from cache

[Django]

#27225: Cache-Control's max-age doesn't match Expires for responses taken from
cache
---+
 Reporter:  renskiy|Owner:  renskiy
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/7246 PR]

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

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

Re: [Django] #27240: Passing custom parameters to formset forms in admin

[Django]

#27240: Passing custom parameters to formset forms in admin
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, form, | Triage Stage:
  formset, parameter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by knbk):

 I'm currently using the following pattern to solve the same problem with
 forms:

 {{{
 def get_form(self, request, obj=None, **kwargs):
 Form = super().get_form(request, obj=None, **kwargs)
 return functools.partial(Form, user=request.user)
 }}}

 Using a class attribute can suffer from thread-safety issues when handling
 concurrent requests.

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

Re: [Django] #27240: Passing custom parameters to formset forms in admin (was: Docs - Passing custom parameters to formset forms in admin)

[Django]

#27240: Passing custom parameters to formset forms in admin
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, form, | Triage Stage:
  formset, parameter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by arogachev):

 * component:  contrib.admin => Documentation


Old description:

> I have `Enterprise` model and related model `Attachment`. Attachments are
> managed using formsets in both frontend and backend.
>
> I use custom form to handle attachments, and it uses additional `user`
> kwarg:
>
> {{{#!python
> def __init__(self, *args, **kwargs):
> self.user = kwargs.pop('user', None)
> super(AttachmentForm, self).__init__(*args, **kwargs)
> }}}
>
> I need to fill this parameter with `request.user` value. In frontend I
> use the method recommended in
> [https://docs.djangoproject.com/en/1.9/topics/forms/formsets/#passing-
> custom-parameters-to-formset-forms docs] (code omitted for brevity).
>
> {{{#!python
> enterprise = Enterprise()
> AttachmentFormSet = generic_inlineformset_factory(Attachment,
> form=AttachmentForm, max_num=3, validate_max=True)
> if request.method == 'POST':
> attachment_formset = AttachmentFormSet(request.POST, request.FILES,
> instance=enterprise, form_kwargs = {'user': request.user})
> else:
> attachment_formset = AttachmentFormSet(instance=enterprise,
> form_kwargs = {'user': request.user})
> }}}
>
> But docs do not cover how achieve the same thing in backend using Django
> Admin.
>
> In admin I have:
>
> {{{#!python
> class AttachmentInline(GenericTabularInline):
> model = Attachment
> form = AttachmentForm
>
> class EnterpriseAdmin(MyCompareVersionAdmin):
> inlines = [AttachmentInline]
> }}}
>
> It's unclear where and how we need to grab and pass `request.user`
> parameter to `AttachmentForm`. After some trial and error, I ended up
> with this workaround:
>
> {{{#!python
> class EnterpriseAdmin(admin.ModelAdmin):
> inlines = [AttachmentInline]
>
> def save_related(self, request, form, formsets, change):
> AttachmentForm.user = request.user
> super(EnterpriseAdmin, self).save_related(request, form,
> formsets, change)
> }}}
>
> Related modifications in `AttachmentForm`:
>
> {{{#!python
> user = None
>
> def __init__(self, *args, **kwargs):
> user = kwargs.pop('user', None)
> if user:
> self.user = user
> super(AttachmentForm, self).__init__(*args, **kwargs)
> }}}
>
> So I turned `user` to class attribute and set it from kwargs only if it's
> passed and it's not `None`.
>
> It works, but I don't like this approach and It looks like a hack for me.
>
> I think the solution on how to properly do it should be added to the docs
> in the same section along with frontend solution.

New description:

 I have `Enterprise` model and related model `Attachment`. Attachments are
 managed using formsets in both frontend and backend.

 I use custom form to handle attachments, and it uses additional `user`
 kwarg:

 {{{#!python
 def __init__(self, *args, **kwargs):
 self.user = kwargs.pop('user', None)
 super(AttachmentForm, self).__init__(*args, **kwargs)
 }}}

 I need to fill this parameter with `request.user` value. In frontend I use
 the method recommended in
 [https://docs.djangoproject.com/en/1.9/topics/forms/formsets/#passing-
 custom-parameters-to-formset-forms docs] (code omitted for brevity).

 {{{#!python
 enterprise = Enterprise()
 AttachmentFormSet = generic_inlineformset_factory(Attachment,
 form=AttachmentForm, max_num=3, validate_max=True)
 if request.method == 'POST':
 attachment_formset = AttachmentFormSet(request.POST, request.FILES,
 instance=enterprise, form_kwargs = {'user': request.user})
 else:
 attachment_formset = AttachmentFormSet(instance=enterprise,
 form_kwargs = {'user': request.user})
 }}}

 But docs do not cover how achieve the same thing in backend using Django
 Admin.

 In admin I have:

 {{{#!python
 class AttachmentInline(GenericTabularInline):
 model = Attachment
 form = AttachmentForm

 class EnterpriseAdmin(MyCompareVersionAdmin):
 inlines = [AttachmentInline]
 }}}

 It's unclear where and how we need to grab and pass `request.user`
 parameter to `AttachmentForm`. After some trial and error, I ended up with
 this workaround:

 {{{#!python
 class EnterpriseAdmin(admin.ModelAdmin):
 inlines = [AttachmentInline]

 def save_related(self, 

Re: [Django] #27240: Passing custom parameters to formset forms in admin

[Django]

#27240: Passing custom parameters to formset forms in admin
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, form, | Triage Stage:
  formset, parameter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by arogachev:

Old description:

> I have `Enterprise` model and related model `Attachment`. Attachments are
> managed using formsets in both frontend and backend.
>
> I use custom form to handle attachments, and it uses additional `user`
> kwarg:
>
> {{{#!python
> def __init__(self, *args, **kwargs):
> self.user = kwargs.pop('user', None)
> super(AttachmentForm, self).__init__(*args, **kwargs)
> }}}
>
> I need to fill this parameter with `request.user` value. In frontend I
> use the method recommended in
> [https://docs.djangoproject.com/en/1.9/topics/forms/formsets/#passing-
> custom-parameters-to-formset-forms docs] (code omitted for brevity).
>
> {{{#!python
> enterprise = Enterprise()
> AttachmentFormSet = generic_inlineformset_factory(Attachment,
> form=AttachmentForm, max_num=3, validate_max=True)
> if request.method == 'POST':
> attachment_formset = AttachmentFormSet(request.POST, request.FILES,
> instance=enterprise, form_kwargs = {'user': request.user})
> else:
> attachment_formset = AttachmentFormSet(instance=enterprise,
> form_kwargs = {'user': request.user})
> }}}
>
> But docs do not cover how achieve the same thing in backend using Django
> Admin.
>
> In admin I have:
>
> {{{#!python
> class AttachmentInline(GenericTabularInline):
> model = Attachment
> form = AttachmentForm
>
> class EnterpriseAdmin(MyCompareVersionAdmin):
> inlines = [AttachmentInline]
> }}}
>
> It's unclear where and how we need to grab and pass `request.user`
> parameter to `AttachmentForm`. After some trial and error, I ended up
> with this workaround:
>
> {{{#!python
> class EnterpriseAdmin(admin.ModelAdmin):
> inlines = [AttachmentInline]
>
> def save_related(self, request, form, formsets, change):
> AttachmentForm.user = request.user
> super(EnterpriseAdmin, self).save_related(request, form,
> formsets, change)
> }}}
>
> Related modifications in `AttachmentForm`:
>
> {{{#!python
> user = None
>
> def __init__(self, *args, **kwargs):
> user = kwargs.pop('user', None)
> if user:
> self.user = user
> super(AttachmentForm, self).__init__(*args, **kwargs)
> }}}
>
> So I turned `user` to class attribute and set it from kwargs only if it's
> passed and it's not `None`.
>
> It works, but I don't like this approach and It looks like a hack for me.
>
> I think the solution on how to properly do it should be added to the docs
> in the same section along with frontend solution.
>
> I'm not sure If I can't find the proper way to do that or it's really not
> implemented for admin.

New description:

 I have `Enterprise` model and related model `Attachment`. Attachments are
 managed using formsets in both frontend and backend.

 I use custom form to handle attachments, and it uses additional `user`
 kwarg:

 {{{#!python
 def __init__(self, *args, **kwargs):
 self.user = kwargs.pop('user', None)
 super(AttachmentForm, self).__init__(*args, **kwargs)
 }}}

 I need to fill this parameter with `request.user` value. In frontend I use
 the method recommended in
 [https://docs.djangoproject.com/en/1.9/topics/forms/formsets/#passing-
 custom-parameters-to-formset-forms docs] (code omitted for brevity).

 {{{#!python
 enterprise = Enterprise()
 AttachmentFormSet = generic_inlineformset_factory(Attachment,
 form=AttachmentForm, max_num=3, validate_max=True)
 if request.method == 'POST':
 attachment_formset = AttachmentFormSet(request.POST, request.FILES,
 instance=enterprise, form_kwargs = {'user': request.user})
 else:
 attachment_formset = AttachmentFormSet(instance=enterprise,
 form_kwargs = {'user': request.user})
 }}}

 But docs do not cover how achieve the same thing in backend using Django
 Admin.

 In admin I have:

 {{{#!python
 class AttachmentInline(GenericTabularInline):
 model = Attachment
 form = AttachmentForm

 class EnterpriseAdmin(MyCompareVersionAdmin):
 inlines = [AttachmentInline]
 }}}

 It's unclear where and how we need to grab and pass `request.user`
 parameter to `AttachmentForm`. After some trial and error, I ended up with
 this workaround:

 {{{#!python
 class EnterpriseAdmin(admin.ModelAdmin):
  

Re: [Django] #27242: Add get_object_or_none to django.shortcuts

[Django]

#27242: Add get_object_or_none to django.shortcuts
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  object, model,   | Triage Stage:
  shortcut   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by arogachev):

 Sorry. I tried to use search to find if similar issues are already exist
 (I was pretty sure about that), but din't find them.

 Now it's clear to me - it needs to be included in own codebase.

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

Re: [Django] #27238: Removal of check_pattern_startswith_slash

[Django]

#27238: Removal of check_pattern_startswith_slash
-+-
 Reporter:  strycore |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (System |  Version:  1.10
  checks)|
 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):

 * cc: alasdairnicol (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 The original ticket is #23813. Maybe it's enough to disable the check if
 `setting.APPEND_SLASH = False`?

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

Re: [Django] #27242: Add get_object_or_none to django.shortcuts

[Django]

#27242: Add get_object_or_none to django.shortcuts
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  object, model,   | Triage Stage:
  shortcut   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Duplicate of #2659, #11352.

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

Re: [Django] #27239: Unexpected behavior on get_FIELDNAME_display when as int as value

[Django]

#27239: Unexpected behavior  on get_FIELDNAME_display when as int as value
-+-
 Reporter:  levivm   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  choice, field| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Duplicate of #20749 which suggests to add a system check to prohibit using
 incorrect types in `choices`.

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

Re: [Django] #27239: Unexpected behavior on get_FIELDNAME_display when as int as value

[Django]

#27239: Unexpected behavior  on get_FIELDNAME_display when as int as value
-+-
 Reporter:  levivm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  choice, field| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by levivm):

 Replying to [comment:1 claudep]:
 > Why would you use integer values for a CharField in the first place?

 Because it's possible. If Django allows you to assign it, so, it should
 take care of that 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/064.1d46583f1708eee3b17858cfa17308e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27239: Unexpected behavior on get_FIELDNAME_display when as int as value

[Django]

#27239: Unexpected behavior  on get_FIELDNAME_display when as int as value
-+-
 Reporter:  levivm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  choice, field| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Why would you use integer values for a CharField in the first place?

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

[Django]

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:
  aggregate annotate |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jaap3):

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


Comment:

 I've been able to work around this by defining my own `DatabaseWrapper`
 and `DatabaseFeatures` (which inherits from the ones in
 `django.db.backends.postgresql`) and setting
 `allows_group_by_selected_pks` to  `False`. However, this disables this
 feature for all models not just the ones backed by a view, so it's not
 ideal.

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

Re: [Django] #27242: Add get_object_or_none to django.shortcuts

[Django]

#27242: Add get_object_or_none to django.shortcuts
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  object, model,   | Triage Stage:
  shortcut   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by arogachev:

Old description:

> Quite often we need to find object of certain model and return `None` if
> it does not exist. I suggest to add this to `django.shortcuts`:
>
> {{{#!python
> def get_object_or_none(klass, *args, **kwargs):
> queryset = _get_queryset(klass)
> try:
> return queryset.get(*args, **kwargs)
> except queryset.model.DoesNotExist:
> return None
> }}}
>
> Yes, we can easily create this in our own code, but maybe consider to add
> this to the core?

New description:

 Quite often we need to find object of certain model and return `None` if
 it does not exist. I suggest to add this to `django.shortcuts` similar to
 `get_object_or_404`:

 {{{#!python
 def get_object_or_none(klass, *args, **kwargs):
 queryset = _get_queryset(klass)
 try:
 return queryset.get(*args, **kwargs)
 except queryset.model.DoesNotExist:
 return None
 }}}

 Yes, we can easily create this in our own code, but maybe consider to add
 this to the core?

--

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

Re: [Django] #27242: Add get_object_or_none to django.shortcuts

[Django]

#27242: Add get_object_or_none to django.shortcuts
-+-
 Reporter:  arogachev|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  object, model,   | Triage Stage:
  shortcut   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by arogachev):

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


Old description:

> I think quite often we need to find object of certain model and return
> `None` if it does not exist. I suggest to add this to `django.shortcuts`:
>
> {{{#!python
> def get_object_or_none(klass, *args, **kwargs):
> queryset = _get_queryset(klass)
> try:
> return queryset.get(*args, **kwargs)
> except queryset.model.DoesNotExist:
> return None
> }}}
>
> Yes, we can easily create this in our own code, but maybe consider to add
> this to the core?

New description:

 Quite often we need to find object of certain model and return `None` if
 it does not exist. I suggest to add this to `django.shortcuts`:

 {{{#!python
 def get_object_or_none(klass, *args, **kwargs):
 queryset = _get_queryset(klass)
 try:
 return queryset.get(*args, **kwargs)
 except queryset.model.DoesNotExist:
 return None
 }}}

 Yes, we can easily create this in our own code, but maybe consider to add
 this to the core?

--

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

[Django] #27242: Add get_object_or_none to django.shortcuts

[Django]

#27242: Add get_object_or_none to django.shortcuts
--+-
 Reporter:  arogachev |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:  object, model, shortcut
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 I think quite often we need to find object of certain model and return
 `None` if it does not exist. I suggest to add this to `django.shortcuts`:

 {{{#!python
 def get_object_or_none(klass, *args, **kwargs):
 queryset = _get_queryset(klass)
 try:
 return queryset.get(*args, **kwargs)
 except queryset.model.DoesNotExist:
 return None
 }}}

 Yes, we can easily create this in our own code, but maybe consider to add
 this to the core?

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

[Django] #27241: Annotate doesn't work with PostgreSQL views anymore

[Django]

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.10
  (models, ORM)  |   Keywords:  postgresql view
 Severity:  Normal   |  aggregate annotate
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Using annotate on (unmanaged) models backed by views has stopped working
 and now throws a:

 `psycopg2.ProgrammingError: column "..." must appear in the GROUP BY
 clause or be used in an aggregate function...`

 This is caused by the fix to ticket #19259.

 Queries with an aggregation now only list the PK field in the `GROUP BY`
 clause, but this doesn't work for views because they cannot have primary
 keys in PostgreSQL.

 Now Django doesn't officially support views, or models without a primary
 key, but it did work before so it's somewhat of a regression.

 I ran into this problem because I'm working on a legacy database and have
 models that are backed by a view using the `db_table` Meta option.

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

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