[Django] #26765: Etags should not be added when no-store is used

[Django]

#26765: Etags should not be added when no-store is used
--+
 Reporter:  marfire   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Core (Cache system)   |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Glancing at the source code, it looks like `CommonMiddleware` (with
 `USE_ETAGS = True`) adds an Etag whenever there isn't one already.

 However, according to [[https://tools.ietf.org/html/rfc7234|RFC 7234]],
 "the ''no-store'' response directive indicates that a cache MUST NOT store
 any part of either the immediate request or response." Since the response
 must not be stored, no compliant cache will be able to issue a conditional
 request, so computing the Etag is wasted effort. (Note that this behavior
 is different from ''no-cache''.)

 The current behavior doesn't do any real harm, but we might as well
 improve the performance of such requests given that the change should be
 relatively easy (simply checking the header value).

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

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

Re: [Django] #26758: Annotate appears broken with Postgres in recent releases

[Django]

#26758: Annotate appears broken with Postgres in recent releases
-+-
 Reporter:  darkpixel|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * cc: charettes (added)


Comment:

 Can you reproduce with the [https://github.com/charettes/django-
 ticketing/commit/78ed6a345e760ea46434690e9385ae4d26fc2810 sample app] I
 provided? Else I'm afraid you'll need to provide more details.

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

[Django] #26764: Session.cycle_key() throws Exception if the session hasn't been accessed

[Django]

#26764: Session.cycle_key() throws Exception if the session hasn't been accessed
--+
 Reporter:  adam-iris |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  contrib.sessions  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 A common use case I see is that a user changes some content then tries to
 view their changes on the website, but they get an older, previously-
 cached page.

 Since the page-level cache key uses the session id, my solution is to call
 `request.session.cycle_key()`. To the user this is presented as a "hard
 reload" -- it clears the session key then redirects back to the current
 page, the page-level cache will miss and the user will get a newly-
 generated version.

 However, this raised an exception:
 {{{ 'SessionStore' object has no attribute '_session_cache' }}}

 Upon inspection, it looks like `SessionBase._session_cache` doesn't get
 initialized except by calling `SessionBase._session`. But the
 `cycle_key()` method accesses `_session_cache` without ensuring that it's
 been initialized.

 My workaround was to prepend a meaningless access call:

 {{{
 request.session.get('foo')
 request.session.cycle_key()
 }}}

 This fixed the exception, but I think the proper fix is for `cycle_key()`
 to initialize (or more carefully check) `_session_cache`.

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

Re: [Django] #26758: Annotate appears broken with Postgres in recent releases

[Django]

#26758: Annotate appears broken with Postgres in recent releases
-+-
 Reporter:  darkpixel|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by darkpixel):

 Updated description with version info.  I'm using PostgreSQL 9.3.12.

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

Re: [Django] #26758: Annotate appears broken with Postgres in recent releases

[Django]

#26758: Annotate appears broken with Postgres in recent releases
-+-
 Reporter:  darkpixel|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by darkpixel:

Old description:

> Brief Summary
>
> The brief overview is:
> * I have a second postgres database that I am reading data from.
> * It's data from a closed-source ticket system we are migrating away
> from.
> * I ran a manage.py inspectdb on it about 2 years ago and have been
> pulling stats from the data since then without trouble
> * The database structure looks *ugly* thanks to the closed-source
> designers, don't blame me... ;)
> * Upgrading from 1.8.4 to 1.9.2 broke one of the queries I was running
>
> Query:
> {{{
> Company.objects.all().annotate(ticketcount=Count('srservice')).exclude(ticketcount=0).order_by('-ticketcount')
> }}}
>
> Error:
> {{{
> >>>
> Company.objects.all().annotate(ticketcount=Count('srservice')).exclude(ticketcount=0).order_by('-ticketcount')
> Traceback (most recent call last):
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
> psycopg2.ProgrammingError: column "company.owner_id" must appear in the
> GROUP BY clause or be used in an aggregate function
> LINE 1: SELECT "company"."owner_id", "company"."company_recid", "com...
>^
>

> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "/home/aaron/.pyenv/versions/3.5.1/lib/python3.5/code.py", line
> 91, in runcode
> exec(code, self.locals)
>   File "", line 1, in 
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 234, in __repr__
> data = list(self[:REPR_OUTPUT_SIZE + 1])
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 258, in __iter__
> self._fetch_all()
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 1074, in _fetch_all
> self._result_cache = list(self.iterator())
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 52, in __iter__
> results = compiler.execute_sql()
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/sql/compiler.py", line 848, in execute_sql
> cursor.execute(sql, params)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/utils.py", line 95, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/utils/six.py", line 685, in reraise
> raise value.with_traceback(tb)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
> django.db.utils.ProgrammingError: column "company.owner_id" must appear
> in the GROUP BY clause or be used in an aggregate function
> LINE 1: SELECT "company"."owner_id", "company"."company_recid", "com...
>^
>
> >>>
> }}}
>
> Generated SQL from the queryset:
> {{{
> SELECT "company"."owner_id", "company"."company_recid",
> "company"."company_id", "company"."company_name", "company"."phonenbr",
> "company"."phonenbr_fax", "company"."website_url", "company"."keywords",
> "company"."account_nbr", "company"."currency_id",
> "company"."time_zone_recid", "company"."sic_code_id",
> "company"."remit_to_recid", "company"."exchange_flag",
> "company"."last_update", "company"."updated_by",
> "company"."company_type_recid", "company"."company_status_recid",
> "company"."tax_code_recid", "company"."currency_recid",
> "company"."owner_level_recid", "company"."billable_flag",
> "company"."userfield_1", "company

Re: [Django] #26758: Annotate appears broken with Postgres in recent releases

[Django]

#26758: Annotate appears broken with Postgres in recent releases
-+-
 Reporter:  darkpixel|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by darkpixel):

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


Old description:

> Brief Summary
>
> The brief overview is:
> * I have a second postgres database that I am reading data from.
> * It's data from a closed-source ticket system we are migrating away
> from.
> * I ran a manage.py inspectdb on it about 2 years ago and have been
> pulling stats from the data since then without trouble
> * The database structure looks *ugly* thanks to the closed-source
> designers, don't blame me... ;)
> * Upgrading from 1.8.4 to 1.9.2 broke one of the queries I was running
>
> Query:
> {{{
> Company.objects.all().annotate(ticketcount=Count('srservice')).exclude(ticketcount=0).order_by('-ticketcount')
> }}}
>
> Error:
> {{{
> >>>
> Company.objects.all().annotate(ticketcount=Count('srservice')).exclude(ticketcount=0).order_by('-ticketcount')
> Traceback (most recent call last):
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
> psycopg2.ProgrammingError: column "company.owner_id" must appear in the
> GROUP BY clause or be used in an aggregate function
> LINE 1: SELECT "company"."owner_id", "company"."company_recid", "com...
>^
>

> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "/home/aaron/.pyenv/versions/3.5.1/lib/python3.5/code.py", line
> 91, in runcode
> exec(code, self.locals)
>   File "", line 1, in 
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 234, in __repr__
> data = list(self[:REPR_OUTPUT_SIZE + 1])
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 258, in __iter__
> self._fetch_all()
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 1074, in _fetch_all
> self._result_cache = list(self.iterator())
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/query.py", line 52, in __iter__
> results = compiler.execute_sql()
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/models/sql/compiler.py", line 848, in execute_sql
> cursor.execute(sql, params)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/utils.py", line 95, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/utils/six.py", line 685, in reraise
> raise value.with_traceback(tb)
>   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
> django.db.utils.ProgrammingError: column "company.owner_id" must appear
> in the GROUP BY clause or be used in an aggregate function
> LINE 1: SELECT "company"."owner_id", "company"."company_recid", "com...
>^
>
> >>>
> }}}
>
> Generated SQL from the queryset:
> {{{
> SELECT "company"."owner_id", "company"."company_recid",
> "company"."company_id", "company"."company_name", "company"."phonenbr",
> "company"."phonenbr_fax", "company"."website_url", "company"."keywords",
> "company"."account_nbr", "company"."currency_id",
> "company"."time_zone_recid", "company"."sic_code_id",
> "company"."remit_to_recid", "company"."exchange_flag",
> "company"."last_update", "company"."updated_by",
> "company"."company_type_recid", "company"."company_status_recid",
> "company"."tax_code_recid", "company"."currency_recid",
> "company"."owner_level_recid", "company"."billab

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
-+-
Changes (by clokep):

 * cc: clokep@… (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/071.a4740aba92ced8a25d91478f994e330b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26763: Control rendering of add/change/delete_related admin buttons

[Django]

#26763: Control rendering of add/change/delete_related admin buttons
---+--
 Reporter:  chrisclark |Owner:  chrisclark
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--

Comment (by chrisclark):

 I think it's also notable that the widget itself is already parameterized
 for this functionality, it's just that it was not carried through to the
 wrapper, which almost, if you squint and don't think about it too hard,
 looks like a bug.

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

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

Re: [Django] #26763: Control rendering of add/change/delete_related admin buttons

[Django]

#26763: Control rendering of add/change/delete_related admin buttons
---+--
 Reporter:  chrisclark |Owner:  chrisclark
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--

Comment (by chrisclark):

 For sure (and I hear you!). Essentially, the UI can be *incredibly*
 confusing in certain circumstances so we need to disable it.

 Here's a very concrete example:

 I've attached a screen shot from our Django admin site. We're an ecommerce
 company, and this is a customer's shipment with a "12% off" offer applied
 to it (the last field in the screenshot).

 For various reasons, sometimes we need to remove the "offer" from a
 shipment. Our support reps get a call from a customer, go to the shipment
 in the Django admin and are *supposed* to set the drop down to --empty--,
 and save the shipment, in order to remove the offer.

 Instead, a handful of times, reps have clicked the red X in order to
 'remove' the offer from the shipment. A totally logical and reasonable
 thing to do, given the UI. But, of course, that deletes *the entire offer*
 from *the entire system*. The offer might be applied to hundreds, or
 thousands of different shipments, and disaster ensues.

 The irony here is that, for safety, we have the FK field from Shipment ->
 Offer set as on_delete=set_null because god forbid deleting an offer also
 deleted all of the shipments. But set_null has the perverse side effect of
 actually ENABLING this X button; it's hidden in the presence of
 on_delete=cascade. Hah! (and there are other, valid, reasons to delete
 offers, and we would never want to delete shipments, so setting
 on_delete=cascade is not a solution for us here).

 This type of UI confusion around these buttons occurs in a dozen or so
 spots around our admin interface.

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

Re: [Django] #26763: Control rendering of add/change/delete_related admin buttons

[Django]

#26763: Control rendering of add/change/delete_related admin buttons
---+--
 Reporter:  chrisclark |Owner:  chrisclark
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by chrisclark):

 * Attachment "example.jpg" added.

 Example of ambiguous UI

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

Re: [Django] #26763: Control rendering of add/change/delete_related admin buttons

[Django]

#26763: Control rendering of add/change/delete_related admin buttons
---+--
 Reporter:  chrisclark |Owner:  chrisclark
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--

Comment (by timgraham):

 Could you add some specifics about the use case? I'll admit I'm a bit
 fatigued about adding endless options in the admin to provide infinite
 customization.

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

Re: [Django] #26763: Control rendering of add/change/delete_related admin buttons

[Django]

#26763: Control rendering of add/change/delete_related admin buttons
---+--
 Reporter:  chrisclark |Owner:  chrisclark
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by chrisclark):

 * Attachment "Screen Shot 2016-06-15 at 9.42.18 AM.png" added.

 Screenshot of feature in question

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

Re: [Django] #26763: Control rendering of add/change/delete_related admin buttons

[Django]

#26763: Control rendering of add/change/delete_related admin buttons
---+--
 Reporter:  chrisclark |Owner:  chrisclark
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by chrisclark):

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


Old description:

> In certain cases, displaying the add/change/delete icons on related
> fields in the Django admin is undesirable, but this behavior can't
> currently be overridden. The proposed change allows configuration of
> which buttons to display by passing kwargs into formfield_for_db.

New description:

 In certain cases, displaying the add/change/delete icons on related fields
 in the Django admin is undesirable, but this behavior can't currently be
 overridden. The proposed change allows configuration of which buttons to
 display by passing kwargs into formfield_for_db.

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

--

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

[Django] #26763: Control rendering of add/change/delete_related admin buttons

[Django]

#26763: Control rendering of add/change/delete_related admin buttons
---+
 Reporter:  chrisclark |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  1
---+
 In certain cases, displaying the add/change/delete icons on related fields
 in the Django admin is undesirable, but this behavior can't currently be
 overridden. The proposed change allows configuration of which buttons to
 display by passing kwargs into formfield_for_db.

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

Re: [Django] #26762: Allow using parts of flatpages without install the app

[Django]

#26762: Allow using parts of flatpages without install the app
---+
 Reporter:  vzima  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.flatpages  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by vzima):

 Personally, I share the carljm's concern ticket:21719#comment:10 that the
 #21719 causes too many imports to be moved inside functions, which leads
 to code that is not as tidy as it should be.

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

Re: [Django] #26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile

[Django]

#26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile
-+-
 Reporter:  hobarrera|Owner:  hobarrera
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  File,| Triage Stage:  Accepted
  SuspiciousFileOperation,   |
  NamedTemporaryFile, regression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 This fix might be problematic. It broke
 
[https://github.com/django/djangoproject.com/blob/ea56005103e941814399b5881feafd12091665f7/fundraising/tests/test_models.py#L28-L46
 a test for djangoproject.com] with the following exception:
 {{{
 ==
 ERROR: test_thumbnail (fundraising.tests.test_models.TestDjangoHero)
 --
 Traceback (most recent call last):
   File
 "/home/tim/code/djangoproject.com/fundraising/tests/test_models.py", line
 42, in test_thumbnail
 self.assertEqual(thumbnail.x, 170)
   File "/home/tim/.virtualenvs/djangoproject-djangoco/lib/python3.4/site-
 packages/sorl/thumbnail/images.py", line 53, in width
 return self.size[0]
 TypeError: 'NoneType' object is not subscriptable
 }}}
 Assigning an absolute file path to a file field as done on line 36 of the
 test isn't tested in Django's test suite. I tried adding a test for this
 but ran into an error like `SuspiciousFileOperation: The joined path
 (/home/tim/code/django/tests/model_fields/4x8.png) is located outside of
 the base path component (/tmp/django_c515u6ay/tmpjxafwpc8)` so maybe this
 isn't a common pattern. The djangoproject.com test uses a file that's
 already in MEDIA_ROOT and can be fixed by replacing the right side of
 `self.h1.logo = image_path` with
 `File(open(image_path, 'rb'))`.

 I'm not too sure what the best behavior is here, so I guess we could wait
 and see if the commit is problematic for any other projects.

 If we reverted this, the alternative seems to be to document that you must
 pass a `name` to `File` as done in
 
[https://github.com/django/django/commit/914c72be2abb1c6dd860cb9279beaa66409ae1b2
 #diff-d6396b594a8f63ee1e12a9278e1999edL57 the Django test suite] in the
 original commit that spawned this ticket. If we keep this commit, then
 those `name` arguments can be removed.

--
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.4db09d79bfb2c4e723986b8c73581f8b%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:  new
Component:  Forms |  Version:  1.9
 Severity:  Normal|   Resolution:
 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
--+

Comment (by bmispelon):

 It might be worth it to effectively cache `BoundField.__iter__()` but in
 your case, can't you use `zip` as a workaround:

 {{{#!python
 for widget, instance in zip(bound_field,
 bound_field.field.queryset.all()):
 instance_widgets.append((instance, copy(widget)))
 }}}

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

[Django]

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"f9b3a6a76f51395a77ab77a8784851549400bbed" f9b3a6a]:
 {{{
 #!CommitTicketReference repository=""
 revision="f9b3a6a76f51395a77ab77a8784851549400bbed"
 [1.10.x] Refs #14030 -- Updated docs per "Improved expression support for
 python values."

 Complements e2d6e14662d780383e18066a3182155fb5b7747b.

 Backport of db613f4f1250971942f766dcf97c22234a3aa14e from master
 }}}

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

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

[Django]

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"99e51bf168a628f67749fcfbd31951c499c403fc" 99e51bf]:
 {{{
 #!CommitTicketReference repository=""
 revision="99e51bf168a628f67749fcfbd31951c499c403fc"
 [1.9.x] Refs #14030 -- Updated docs per "Improved expression support for
 python values."

 Complements e2d6e14662d780383e18066a3182155fb5b7747b.

 Backport of db613f4f1250971942f766dcf97c22234a3aa14e from master
 }}}

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

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

[Django]

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"db613f4f1250971942f766dcf97c22234a3aa14e" db613f4f]:
 {{{
 #!CommitTicketReference repository=""
 revision="db613f4f1250971942f766dcf97c22234a3aa14e"
 Refs #14030 -- Updated docs per "Improved expression support for python
 values."

 Complements e2d6e14662d780383e18066a3182155fb5b7747b.
 }}}

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

Re: [Django] #26759: TLSv1-only SMTP servers not supported under Django 1.9.7 / Python 3.4.4 (win32) / OpenSSL 1.0.2d

[Django]

#26759: TLSv1-only SMTP servers not supported under Django 1.9.7 / Python 3.4.4
(win32) / OpenSSL 1.0.2d
-+-
 Reporter:  RudolfCardinal   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  email SMTP TLS SSL   | Triage Stage:
  SSLEOFError TLSv1  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 This is the first I've heard of the problem, so I can't say myself that
 supporting old protocols is critically important for Django core. Feel
 free to raise it on the DevelopersMailingList. If there's consensus there
 to make a change in Django, we can reopen the 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/072.bf2e132e7196a513ee8bbc7523ece09f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26760: Delete nonexistent migrations from django_migrations table (was: django_migrations table is never cleaned.)

[Django]

#26760: Delete nonexistent migrations from django_migrations table
-+-
 Reporter:  jarekwg  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  django_migrations| Triage Stage:  Accepted
  squash migrations  |
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:

 In #26429 we added a timestamp to merge migration names to reduce the
 likelihood of collisions there. I acknowledge this could happen in other
 situations though.

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

Re: [Django] #26762: Allow using parts of flatpages without install the app (was: Can't reuse code from django.contrib.flatpages)

[Django]

#26762: Allow using parts of flatpages without install the app
---+
 Reporter:  vzima  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.flatpages  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

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


Comment:

 I guess it's in the same spirit as #26401 (same request for the auth app).
 I guess moving the import of the `FlatPage` model to inner imports might
 be the more correct 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/063.4f1fd0540cdda6e2433388a4c2b1cd94%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26762: Can't reuse code from django.contrib.flatpages

[Django]

#26762: Can't reuse code from django.contrib.flatpages
---+
 Reporter:  vzima  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.flatpages  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Our application uses it's own version of `django.contrib.flatpages`. To
 reduce the amount of code needed to reuse flatpages (which is a lot, but
 that's another issue) we reuse as much code from flatpages as we can -
 e.g. `FlatpageForm`, `render_flatpage` and so on. We don't have
 `django.contrib.flatpages` in `INSTALLED_APPS` and we really don't want to
 do that, since it raises a whole other set of issues. It works fine in
 Django 1.8, but stops to work when we switch to Django 1.9 with error

 {{{
 RuntimeError: Model class django.contrib.flatpages.models.FlatPage doesn't
 declare an explicit app_label and isn't in an application in
 INSTALLED_APPS.
 }}}

 The error itself doesn't quite make sense, since we don't use `FlatPage`
 model at all, it just gets loaded.

 There is simple fix which allows flatpages to be at least somewhat reused
 even in 1.9, that is defining the `app_label` in `FlatPage`.
 {{{
 #!diff
 diff --git a/django/contrib/flatpages/models.py
 b/django/contrib/flatpages/models.py
 index 69e84f8..abb19c1 100644
 --- a/django/contrib/flatpages/models.py
 +++ b/django/contrib/flatpages/models.py
 @@ -25,6 +25,7 @@ class FlatPage(models.Model):
  sites = models.ManyToManyField(Site, verbose_name=_('sites'))

  class Meta:
 +app_label = 'flatpages'
  db_table = 'django_flatpage'
  verbose_name = _('flat page')
  verbose_name_plural = _('flat pages')
 }}}

 I'm aware that this is sort of hotfix, since it doesn't solve underlying
 issue, but it would allow flatpages to be used as a library.

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

Re: [Django] #26761: Add 'help_text' property to methods in ModelAdmin.list_display (was: Admin - add 'help_text' property to custom fields)

[Django]

#26761: Add 'help_text' property to methods in ModelAdmin.list_display
---+
 Reporter:  gamesbook  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

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


Old description:

> It would be helpful to allow for a `help_text` property to be supplied to
> a custom field in the admin.
>
> For example:
>
> {{{
> from django.contrib import admin
>
> class AuthorAdmin(admin.ModelAdmin):
> fields = ('name', 'title', 'view_birth_date')
>
> def view_birth_date(self, obj):
> return obj.birth_date
>
> view_birth_date.short_name = 'birth_date'
> view_birth_date.empty_value_display = '???'
> view_birth_date.help_text = 'Authors birthday'
> }}}
>
> This help text could be displayed via a 'hover over' in the header(s) of
> the columns in the admin list display.

New description:

 It would be helpful to allow for a `help_text` property to be supplied to
 a custom field in the admin.

 For example:

 {{{
 from django.contrib import admin

 class AuthorAdmin(admin.ModelAdmin):
 fields = ('name', 'title', 'view_birth_date')

 def view_birth_date(self, obj):
 return obj.birth_date

 view_birth_date.help_text = 'Authors birthday'
 }}}

 This help text could be displayed via a 'hover over' in the header(s) of
 the columns in the admin list display.

--

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

Re: [Django] #26643: AlterModelManagers migration is generated for all Models with custom Managers pointing to the default Django Manager

[Django]

#26643: AlterModelManagers migration is generated for all Models with custom
Managers pointing to the default Django Manager
-+-
 Reporter:  cybojenix|Owner:  schinckel
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Test is added to the 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.86c3335f6918ba859c79cb80400331be%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26761: Admin - add 'help_text' property to custom fields

[Django]

#26761: Admin - add 'help_text' property to custom fields
---+
 Reporter:  gamesbook  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:  admin
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 It would be helpful to allow for a `help_text` property to be supplied to
 a custom field in the admin.

 For example:

 {{{
 from django.contrib import admin

 class AuthorAdmin(admin.ModelAdmin):
 fields = ('name', 'title', 'view_birth_date')

 def view_birth_date(self, obj):
 return obj.birth_date

 view_birth_date.short_name = 'birth_date'
 view_birth_date.empty_value_display = '???'
 view_birth_date.help_text = 'Authors birthday'
 }}}

 This help text could be displayed via a 'hover over' in the header(s) of
 the columns in the admin list display.

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