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
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

adam-delaney created an issue. See original summary.

mably’s picture

Hi @adam-delaney, thanks for your MR.

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

adam-delaney’s picture

@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.

mably’s picture

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?

mably’s picture

[deleted]

mably’s picture

[deleted]

adam-delaney’s picture

@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.

mably’s picture

The view permission should be per node type of course.

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

adam-delaney’s picture

@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.

mably’s picture

Sounds like a sensible approach to me.

Will be happy to review it.

adam-delaney’s picture

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

mably’s picture

Status: Active » Needs review
Issue tags: +Needs tests

Thanks. Looks good to me.

The ideal would be to have a lightweight functional test for this new functionality.

Just checking that the field is disabled when you only have the view permission.

adam-delaney’s picture

@mably, I've added a lightweight functional test to tests the permissions for the module.

mably’s picture

Status: Needs review » Needs work

That's some exhaustive permission testing, thanks a lot @adam-delaney!

There are still a few PHPCS warnings to fix and we should be ready to merge.

adam-delaney’s picture

@mably, I've fixed those phpcs warnings and errors. Thanks for catching that.

adam-delaney’s picture

Status: Needs work » Needs review

  • mably committed f25b1f45 on 3.x authored by adam-delaney
    Issue #3543456 by adam-delaney, mably: Add TimestampDatetimeWidget...
mably’s picture

Status: Needs review » Fixed
Issue tags: -Needs tests

Released in 3.1.0-beta1.

Thanks for this new feature!

adam-delaney’s picture

Thanks @mably, great working with you on this!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.