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
Issue fork publication_date-3543456
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
Comment #3
mably commentedHi @adam-delaney, thanks for your MR.
Could you tell us a bit more about your use-case please?
Comment #4
adam-delaney commented@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.
Comment #5
mably commentedSo, 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?
Comment #6
mably commented[deleted]
Comment #7
mably commented[deleted]
Comment #8
adam-delaney commented@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.
Comment #9
mably commentedThe 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?
Comment #10
adam-delaney commented@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.
Comment #11
mably commentedSounds like a sensible approach to me.
Will be happy to review it.
Comment #12
adam-delaney commented@mably, I've made that update per our conversation. Please feel free to review at your convenience.
Comment #13
mably commentedThanks. 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.
Comment #14
adam-delaney commented@mably, I've added a lightweight functional test to tests the permissions for the module.
Comment #15
mably commentedThat'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.
Comment #16
adam-delaney commented@mably, I've fixed those phpcs warnings and errors. Thanks for catching that.
Comment #17
adam-delaney commentedComment #19
mably commentedReleased in 3.1.0-beta1.
Thanks for this new feature!
Comment #20
adam-delaney commentedThanks @mably, great working with you on this!