People install this module, select 'read-only' when they create a field, probably the first field they've ever made, never enter a default value, never enter a value in the form field, and then complain that the field does nothing.

I have had a very confusing support discussion about this where the user was never actually using/seeing one of the provided field widgets (select, autocomplete, etc..), and then was surprised that nothing happened.

I kept asking "how are you using the field?", "what value is submitted", "what did you select in the field?" etc... and the responses just did not make sense to me. Eventually traced it back to using the 'read-only' widget, and then eventually found this mystery widget is provided by this module.

Not sure what to suggest as I haven't used the module. I can't even imagine what the practical use of a read-only widget is - how do you set a default value? Switch back and forth between widgets? Why not use field permissions to deactivate or hide the usual widget?

Comments

danielb’s picture

danielb commented

I installed and tested this module and found that changing the widget type to 'hidden' or 'read-only' and then resaving nodes seems to empty the field? So I can't even figure it out :/ Nevermind, it works fine on text fields so there might be an incompatibility with the field type I was using.

damien tournoud’s picture

damien tournoud commented

The read-only widget is precisely designed in cases where you want the field not to be editable (ie. you don't have edit access to the field) but you still want to show the content of the field to the user.

Use cases include:

- some data comes from some other authoritative data source (an ERP, etc.);
- only some type of users have access to the field, but the other types of users need to see the content of the field in the edit form to have more context

This is definitely an advanced module that will have a limited usefulness if you build the site just through the UI.

danielb’s picture

danielb commented
Category: task » support

The read-only widget is precisely designed in cases where you want the field not to be editable (ie. you don't have edit access to the field) but you still want to show the content of the field to the user.

Yes I realise this, but from the experience I heard about it seems they never realised a value had to be set somehow in the first place. They did intend for the final result to be a field that wasn't changeable by the author, though.

- only some type of users have access to the field, but the other types of users need to see the content of the field in the edit form to have more context

Ah, so the author can see the field value to understand the behavior of the node, but not be able to change it. However, I don't understand how the users that would have access to the field would receive the normal widget?

Regarding my own experience with a possibly incompatible field type:
Would it be fair to say that a field module that relies on it's own widgets because of hook_field_widget_form_alter() adding a #value_callback to expand values on the form field, cannot be compatible with this module?

damien tournoud’s picture

damien tournoud commented

Would it be fair to say that a field module that relies on it's own widgets because of how they preprocess and validate the form field cannot be compatible with this module? Specifically the field storage is multiple columns, so the value is an array.

No, this module should work for every field type. Of course, you would need a way to get the data inside the field in the first place.

This module is currently not dealing with this part at all, which is probably what's confusing the users. We might be able to fix the unfortunate interaction between the default value entry and this widget.

danielb’s picture

danielb commented

Thanks Damien, that's very helpful. I know it's totally not your fault if this module is used incorrectly, just thought you should know in case it inspires you to do anything, or if it comes up again you'll know this happened.

We might be able to fix the unfortunate interaction between the default value entry and this widget.

By this I assume you mean that the default value cannot be altered once this widget is in effect, not that the user is able to set a default value and then switch widgets.
It seems that switching back and forth between widgets may be a perfectly valid usage, and certainly that was my first instinct to try that.

joachim’s picture

joachim commented

It sounds like what users were actually after was this: #1671202: Add a widget/widget alteration for 'read-only on edit'

joachim’s picture

joachim commented
Issue summary: View changes

edit