[Django] #30577: feature request: custom rendering for readonly fields in admin

[Django]

#30577: feature request: custom rendering for readonly fields in admin
-----------------------------------------+------------------------
Reporter: David | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
The new view permission is extremely useful, and encourages more use of
the Django Admin tool. It has highlighted a limitation in the rendering of
`readonly_fields` that can be easily addressed. At the moment,
`readonly_fields` (or all fields when the user has only `can_view`) can
only have custom rendering or formatting if they are custom properties or
new fields (created in the ModelAdmin), existing fields can't be changed.
In my use-case I have a number of rich text enhanced `TextField`s, which
when rendered as read-only show up as HTML and can't be marked safe. In
this case creating a custom field in the `ModelAdmin` where the Field can
be output with `mark_safe()` doesn't work as the original field needs to
exist for users with change permissions, the only other way is to include
the field twice which creates UX issues.

If, in ModelAdmin, you could override the formatting/output of a read-only
field it would address this issue. Alternatively, as mentioned in the
comments of #14802, the idea of Fields having a method that is called by
admin to handle the read-only HTML rendering would also do the trick as is
related.

--
Ticket URL: <https://code.djangoproject.com/ticket/30577>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------

Reporter: David | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.2

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 Carlton Gibson):

Hi David.

This is interesting. I think I see where you're coming from but, could I
ask you to put together an minimal project that demonstrates exactly the
issue you're seeing — perhaps with some screenshots etc — so we can make
sure we're 100% clear?

I'm not sure about an adjustment here. I think it would depend on exactly
what's being proposed. Do you have a specific implementation idea?

It may be that there's a work-around.

bf39978a53f117ca02e9a0c78b76664a41a54745 introduced a check on the widget
for a `read_only` attribute, when rendering `AdminReadonlyField`

{{{
if field in self.form.fields:
widget = self.form[field].field.widget
# This isn't elegant but suffices for contrib.auth's
# ReadOnlyPasswordHashWidget.
if getattr(widget, 'read_only', False):
return widget.render(field, value)
}}}

If you were to override, `ModelAdmin.get_form()` to set a custom widget
(with `read_only=True) on the required field, when the user did not have
the `change` permission, you should 🤔 be able to leverage this to get the
behaviour you need. (If you could put together that test project it would
be easy enough to have a play with this...)

Given these questions, and that #14802 was closed as `wontfix`, I'm going
to close this as `needsinfo` right now. A sample project plus a proposal
is probably needed to progress. With just a sample project, asking on the
DevelopersMailingList might provide some help. Exploring the work-around
would be the shortest route forward.

--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:1>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 2.2
Severity: Normal | Resolution: needsinfo

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 Carlton Gibson):

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

--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:2>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 2.2
Severity: Normal | Resolution: needsinfo

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 Florian Demmer):

* cc: Florian Demmer (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:3>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 2.2
Severity: Normal | Resolution: needsinfo

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 Filipe):

Just ended up here while looking for a way to have a custom widget on a
read-only JSONField and bumping into `ReadOnlyPasswordHashWidget` hackery
on my own...

Wouldn't it be cleaner (and easy) to simple update
https://github.com/django/django/blob/main/django/contrib/admin/templates/admin/includes/fieldset.html#L16-L18
to check for an existing `field.readonly_widget` all the time?

--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:4>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 2.2
Severity: Normal | Resolution: needsinfo

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 Carlos Palol):

* cc: Carlos Palol (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:5>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------

Reporter: David | Owner: nobody
Type: New feature | Status: new

Component: contrib.admin | Version: 5.1
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 ldeluigi):

* cc: ldeluigi (added)
* resolution: needsinfo =>
* status: closed => new
* version: 2.2 => 5.1

Comment:

I'd like to reopen this ticket in favor of another use case scenario:
I have plenty of models that each have many DateTimeFields that are read
only, namely 'updated' and 'created' timestamps.
I want to customize how datetimes are displayed as HTML when they are
read_only, but unfortunately Django admin invokes the hardcoded display
functions to display read_only fields that don't have a widget set with
read_only=True. I don't want to customize it once for each of these
fields, I'd like to make a common abstract class that inherits from
ModelAdmin once for all my forms and have it change the generated HTML for
datetimefields for every subclass.

Using formfield_overrides with a widget with read_only=True isn't enough
because the AdminReadonlyField contents method wants the field to be
explicitly listed in the form fields before checking if read_only is True
on the widget.

I'd like to be able to provide a read only representation of field classes
from a ModelAdmin superclass.
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:6>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 5.1
Severity: Normal | Resolution: needsinfo

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 Mariusz Felisiak):

* resolution: => needsinfo

* status: new => closed

Comment:

Replying to [comment:6 ldeluigi]:

> I'd like to reopen this ticket in favor of another use case scenario:
> I have plenty of models that each have many DateTimeFields that are read
only, namely 'updated' and 'created' timestamps.
> I want to customize how datetimes are displayed as HTML when they are
read_only, but unfortunately Django admin invokes the hardcoded display
functions to display read_only fields that don't have a widget set with
read_only=True. I don't want to customize it once for each of these
fields, I'd like to make a common abstract class that inherits from
ModelAdmin once for all my forms and have it change the generated HTML for
datetimefields for every subclass.
>
> Using formfield_overrides with a widget with read_only=True isn't enough
because the AdminReadonlyField contents method wants the field to be
explicitly listed in the form fields before checking if read_only is True
on the widget.
>
> I'd like to be able to provide a read only representation of field
classes from a ModelAdmin superclass.

Thanks for reopening this ticket, however you didn't answer any of
Carlton's [https://code.djangoproject.com/ticket/30577?replyto=6#comment:1
requests/questions] or provide PoC. Please don't reopen old ticket without
providing required details.
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:7>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody

Type: New feature | Status: closed
Component: contrib.admin | Version: 5.1
Severity: Normal | Resolution: needsinfo

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 Mariusz Felisiak):

* cc: Mariusz Felisiak (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:8>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------

Reporter: David | Owner: nobody
Type: New feature | Status: new

Component: contrib.admin | Version: 5.1
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 ldeluigi):

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

Comment:

Here is the PoC where I've defined an AbstractAdmin that basically
monkeypatches the feature for all subclasses that expose readonly
DateTimeField(s) values:

[https://github.com/ldeluigi/django-poc-20240610]

I'd like to be able to do the same without having to write that ugly and
cumbersome code which as a side effect has to alter the field names of the
model admin disruptively.
In my PoC I can't take advantage of the read_only field on widgets because
I can't define an abstract admin form class that works for every subclass,
because its subclass define DateTimeFields with different names and not
every one of them is read only potentially.
What I need is something that allows me to customize the display of
readonly field based on their type that is only used if they are read only
for whatever reason, including permissions.

Example of possible API to solve the problem:
{{{#!python
class AbstractAdmin(admin.ModelAdmin):
readonly_formfield_overrides = {
DateTimeField: {'widget': MyCustomReadonlyWidget},
}
}}}
if widgets are not the best choice for readonly representation better work
with functions:
{{{#!python
def datetime_to_html(datetime: datetime | None) -> SafeText:
if datetime is None:
return mark_safe('never')
return ...

class AbstractAdmin(admin.ModelAdmin):
readonly_formfield_overrides = {
DateTimeField: datetime_to_html,
}
}}}
Where `readonly_formfield_overrides` would only be used for non-editable
fields whose type one of the specified for customization
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:9>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 5.1
Severity: Normal | Resolution: needsinfo

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 Sarah Boyce):

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

Comment:

Thank you for providing your insights here Ideluigi, this helps illustrate
a potential approach if we want to take this forward.

From reading the ticket through, I believe before we try to develop a
feature, we want to see a sample project/example of this issue in action.
This will need to be clear what we see and what we want to see instead.
This would be useful in testing but also in investigating workarounds and
whether we have to make customizations in Django.

Based off that we can make an assessment on different approaches to
achieve this and conclude if Django should make this easier.
Then we can start looking at updates to Django 🙂

If you want to discuss your approach, I recommend moving to the
[https://forum.djangoproject.com/c/internals/5 Django forum] as there is a
wider audience who might be able to give you feedback there.
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:10>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody

Type: New feature | Status: closed
Component: contrib.admin | Version: 5.1
Severity: Normal | Resolution: needsinfo

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 ldeluigi):

Follow up in the forum: https://forum.djangoproject.com/t/feature-request-
discussion-custom-rendering-for-readonly-fields-in-admin/32009
(for those who come by this thread)
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:11>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------
Reporter: David | Owner: nobody

Type: New feature | Status: closed
Component: contrib.admin | Version: 5.1
Severity: Normal | Resolution: needsinfo

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 Sarah Boyce):

#35544 is a duplicate
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:12>

[Django]

#30577: feature request: custom rendering for readonly fields in admin

-------------------------------+--------------------------------------

Reporter: David | Owner: nobody
Type: New feature | Status: new

Component: contrib.admin | Version: 5.1
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 Gagan Deep):

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

Comment:

Hello everyone,

I recently added a comment on the [https://forum.djangoproject.com/t
/feature-request-discussion-custom-rendering-for-readonly-fields-in-
admin/32009/5 related Django forum thread] regarding the
[https://github.com/django/django/commit/d755a98b8438c10f3cff61303ceb1fe16d414e9b
removal of the workaround for `ReadOnlyPasswordHashWidget`] that allowed
custom widgets to be used for rendering readonly fields in the Django
admin.

As a result of this change, it's no longer possible to customize the
rendering of readonly fields using widgets. To demonstrate this, I’ve
created a [https://github.com/openwisp/django-readonly-issue-demo-30577
minimal project] comparing Django 5.2 and the latest development version
(installed from the `main` branch on GitHub).

'''Django 5.2: custom widget used for readonly field'''
[[Image(https://raw.githubusercontent.com/openwisp/django-readonly-issue-
demo-30577/refs/heads/main/docs/images/django-5.2.png, height=300px)]]

'''Development version: default admin rendering used'''
[[Image(https://raw.githubusercontent.com/openwisp/django-readonly-issue-
demo-30577/refs/heads/main/docs/images/django-6.0.png, height=300px)]]

At [https://openwisp.org/ OpenWISP], we leveraged this workaround in
Django <= 5.2.x to render the `django-leaflet` widget for users with view-
only permissions. Moreover, we want to [https://github.com/openwisp
/openwisp-controller/issues/848 utilize this functionality to render
properly formatted JSON in the Django admin].

> This will need to be clear what we see and what we want to see instead.

I believe the above screenshots with the [https://github.com/openwisp
/django-readonly-issue-demo-30577 demo project] make the intended outcome
clear.

Since the workaround is no longer allowed, I urge the maintainers to
reconsider this feature request.
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:13>

[Django]

#30577: Custom rendering for readonly fields in admin
-------------------------------+------------------------------------

Reporter: David | Owner: nobody
Type: New feature | Status: new

Component: contrib.admin | Version: 5.1
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 Sarah Boyce):

* stage: Unreviewed => Accepted
* summary: feature request: custom rendering for readonly fields in admin
=> Custom rendering for readonly fields in admin

--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:14>

[Django]

#30577: Custom rendering for readonly fields in admin
-------------------------------+------------------------------------

Reporter: David | Owner: nobody
Type: New feature | Status: new

Component: contrib.admin | Version: 5.1
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 Federico Capoano):

Thank you Sarah for accepting the ticket. Now the question is whether we
want to simply continue supporting the workaround or whether we want to
provide an official cleaner way to implement this, although probably
having both available initially could provide a backward compatibile
upgrade path (eg: previous implementations will continue working, we can
advise to migrate to the new way in the release notes and warn that the
previous workaround is deprecated and will be removed in the next
release).
--
Ticket URL: <https://code.djangoproject.com/ticket/30577#comment:15>