Provide form display formatter for greying-out a field or hiding it completely

At a minimum this needs some tests to confirm expected behavior, especially since it is changing the actual access call. This could also potentially be implemented as a separate module, since the access hook needs to only return TRUE from a single hook, not all hooks...

# 19 - the same here. Tested with entity refrence field and enabled 'Create (read-only) own value for field field_list_type' but creator still can change it, even he is not admin.

I can confirm # 16 woks for drupal 9 sites, However does not work for D10 (my current is 10.1.3)

So when I use the same module on D9 site it works as expected (patch #16). However the same does not work on D10. No issues in log, just it is not disabled (greyed out)

Any idea what was changed in D10 in term of permissions ?

Hook hook_field_widget_form_alter is deprecated in Drupal 10
see change record - https://www.drupal.org/node/3180429 →

In general disabled (or “greyed out”) form fields are not good from an accessibility perspective. I would strongly advise against their use.

reroll #13 for Drupal 10 according to #25
Will not work with Drupal 9

We need to support D9 until support is dropped from module itself.
Review MR - https://git.drupalcode.org/project/field_permissions/-/merge_requests/23

Covered unit test for read only permissions.

Merge request !23 from #30 created additional issue described here. Rollback was needed.

3440233 🐛 Call to undefined method getEntity() Active

@van.dordafog thank you your patch #28 works fine for D10.2.5.

However as I already mentioned - #31 - Merge request is not working at all.

Regarding #31/#32:

On Drupal 10.2.x the MR works fine, but with a standard form. I haven't tried the setup of the related issue.

However looking at the code

$op = $form_state->getFormObject()->getEntity()->isNew() ? 'create' : 'edit';
is both in the MR and in the patch #28, so it's strange that the patch works while the MR doesn't.

Hello i have tested the MR23 and it is working fine
Thanks

Another option for people who need this, could be to use the Readonly Field Widget module: https://www.drupal.org/project/readonly_field_widget →

The module provides a "readonly" widget, which can be used with a field and allows rendering the field on the form using one of the field formatters. It works even if the user does not have edit permission to the field.

The good thing about that approach is it's much better from an accessibility perspective, the problem with disabled form elements is that often the way they are rendered by browsers it's not always clear to the user that they cannot interact with the element, often disabled elements do not look visually distinct enough from editable elements.

Hi,

Read only field is always read only. But there are a lot of cases i need read only only for some roles, and some of them have to have writte one.

For example project name cannot be changed once created but PM needs to see it so it is clear he is updating the correct one. Or project start date he needs to see it in edit mode but he cannot change it - for this case read only is good enough but sometimes project name has to be changed or other project settings by program lead which has different role.
That's why this feature is awesome and should be implemented to prod version.

@coaston what I'm trying to do is steer us away from simply making form elements disabled, because, as I noted, that's not great from an accessibility perspective. What I'm saying is that the way the approach taken by the Readonly Field Widget module is good because it doesn't result in "disabled" form elements, it actually just displays the output of the field. Obviously that module is solving a different usecase but the approach taken is a sensible one.

Hello, I modified the number #13 to be usable in the D10 version.

Thanks @Edde20
#39 worked for me. (Drupal 10.3.1)

+1 RTBC

Update patch #39, using the dev version of the module.

I tested #41. It also makes fields read-only on creating new node form and when editing its own nodes.
I think the field should be "read-only" only when content editor role(example) is editing other people's nodes.
Here's my sample fp table for body field.

No it is fine now. If you want edit only yours use own instead.

I'm not sure it's fine, or maybe I've completely misunderstood this approach.
According to the FP table in my previous comment;
Log in as a Content editor and try to create or edit a node, you'll see what I mean.

If you want other users to be able to read the field but not edit it, for example, you must select "read only", if you set "original" permissions, the option will disappear and return to its normal state, i.e., you will be able to edit the field again.

In this case, Role 1 has both options to create or edit the normal field, but in role 2, it can only see those fields, it should not be able to create or edit it.

First of all, do we agree on the purpose? If not, if the patch serves a different purpose, then it's my complete misunderstanding of the main idea.
Sorry for this.

But if we agree on the main idea, then excuse me, the patch does not work, it does not serve the idea.
@edde20 I tested your FP table. Result is the same for me.If a content editor can edit his own content field, he can also edit anyone's content field.If he can't edit anyone's content field(read-only), he can't edit his own content field either(read-only). It didn't work for me.

Update patch #41.

Updated MR with latest code and tests, please review.
https://git.drupalcode.org/project/field_permissions/-/merge_requests/23...

Updated MR with latest code and tests, please review.

hi
the MR 23 worked for me on D10.3.5 + PHP 8.3.
FYI after patching drush cr

Thanks

The issue summary should use the standard template and needs an update. What the MR does is not really described by the issue so its hard to review it. Seems like its doing a more access control level thing and based on that is disabling a field?

Curious what happens if you add a new role? They would inherit the permissions from authenticated user at first right?