Add TimestampDatetimeWidget settings for readonly

Created on 27 August 2025, 1 day ago

Problem/Motivation

Problem: The TimestampDatetimeWidget class needs a configurable readonly option to allow administrators to control whether the datetime field can be edited by users. Having this as a widget settings provides flexibility for site administrators to provide valuable data to authors like the date and time of the publication yet restrict them from altering it.

Remaining tasks

Solution: Implement a readonly setting that:

  • Provides a checkbox in the widget settings form
  • Displays the current readonly state in the settings summary
  • Disables the datetime input field when readonly is enabled
  • Maintains backward compatibility with existing field configurations
✨ Feature request
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States adam-delaney

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @adam-delaney
  • Pipeline finished with Success
    1 day ago
    Total: 149s
    #583649
  • πŸ‡«πŸ‡·France mably

    Hi @adam-delaney, thanks for your MR.

    Could you tell us a bit more about your use-case please?

  • πŸ‡ΊπŸ‡ΈUnited States adam-delaney

    @mably, thanks for you inquiry. Our specific use case is that our editors and publishers would like to be able to see the publication date data, but they should not be able to alter that data. For example, if a content author needed to report back the publication date of a piece of content for compliance reasons, it would be helpful to be able to see that date using the field widget, but they should not be able to alter that publication date. I see a permission that allows the widget to be displayed, but there is no granular controls for controlling editing. Hope that clarifies the use case.

  • πŸ‡«πŸ‡·France mably

    So, in my point of view, the best solution would be to add a "view only" permission. And tweak the display accordingly.

    What do you think?

  • πŸ‡«πŸ‡·France mably

    So, in my point of view, the best solution would be to add a "view only" permission. And tweak the display accordingly.

    What do you think?

  • πŸ‡«πŸ‡·France mably

    So, in my point of view, the best solution would be to add a "view only" permission. And tweak the display accordingly.

    What do you think?

  • πŸ‡ΊπŸ‡ΈUnited States adam-delaney

    @mably, a few thoughts on the widget and permissions implementation. This widget seems to work differently compared to other field widget implementations I've encountered. Other field widgets don't rely on permissions for widget visibility on the form display. Most widget leverage the form display itself, i.e. if you need to hide the widget you would disable it in manage form display. Additionally, I like the flexibility of having the editing of the widget configurable on a per content type basis, which gives more flexibility on a content type basis. Interested on your thoughts or background on the existing approach.

  • πŸ‡«πŸ‡·France mably

    The view permission should be per node type of course.

    How do you manage multiple form displays ? How do you choose the one to use for a particular user when editing a content ?

  • πŸ‡ΊπŸ‡ΈUnited States adam-delaney

    @mably, oh you are correct the permissions are on a per content type basis. This would allow for flexibility given different roles. I can look at updating the MR to user permissions for editing rather than widget settings.

  • πŸ‡«πŸ‡·France mably

    Sounds like a sensible approach to me.

    Will be happy to review it.

  • Pipeline finished with Canceled
    about 7 hours ago
    #584609
  • Pipeline finished with Success
    about 7 hours ago
    #584613
  • πŸ‡ΊπŸ‡ΈUnited States adam-delaney

    @mably, I've made that update per our conversation. Please feel free to review at your convenience.

Production build 0.71.5 2024