Access denied to Form field: set as disabled (eca_form_field_disable)

Many ECA action plugins use the access method to verify, whether the action is executable. It's a design problem of ECA that leads to this confusion. In your case, the form field named as "op" most probably doesn't exist. Guess you're trying to disable the submit button of the article form. Try using "submit" as form field name instead of "op" in your config and let me know here whether that works for you or not.

The "Build form" event should already be the right one to react upon, when it's about manipulating submit buttons. I'm currently not sure whether "node_article_form" is the correct form ID, but could be. Otherwise, you could also try to set for entity type ID "node", bundle "article" and operation "default, edit".

Many ECA action plugins are using the access method to determine, whether an action is executable. That's a design problem of ECA, that leads to this confusion. In your case, the form field named as "op" most probably doesn't exist and thus leads to an access denied result.

Guess you're trying to disable the Save button in the article form. Try using "submit" as field name instead of "op", and please let me know here whether that works or not.

The "Build form" event should already be the right one when it's about manipulating submit buttons in an entity form. I'm not sure whether "node_article_form" is the correct form ID - maybe it is, but if not, you could also try with entity type "node", bundle "article" and operation "default, edit".

Changing the value in "Field name" on the eca_form_field_disable to `submit` worked, thanks for that tip!

Maybe the help text could be improved, I wouldn't have thought that `op` was correct if not for a message in the ui telling me to use the name attribute.

The current help text is:

The input name of the form field. This is mostly found in the "name" attribute of an form element. This property supports tokens.

And the input element is:

<input data-drupal-selector="edit-submit" type="submit" id="edit-submit" name="op" value="Save" class="button button--primary js-form-submit form-submit">

In this situation the type attribute was what worked. Is this always the case, or are there situations where we would need to use a different attribute value ?

Thank you for such a quick response!

Agreed, the help text may not be ideal and could be improved. The keyword in the help text is "mostly" ;)

The reason why "submit" works here is not because of the type attribute, it's because the "Save" button is identified with a "submit" array key within the form render array.

Another possible improvement would be to additionally "autodetect" a form field element using the "#name" render array key, some kind of fallback try when it didn't manage to find a form field element yet.

Finally another improvement could be: A text to a forbidden access result could be added to appear in the logs, and the action could add an informative text why access was forbidden. In this case it could tell something like "The targeted form field element does not exist".

Not yet marking as fixed, as I think it makes sense to at least address one possible improvement for this.

Changing the help text / documentation seems like the minimum here. Using submit would have been my first guess, but the way it is currently written is actively misleading.

The field label here ('Field name') is also pretty ambiguous. There's nothing here that is actually telling a user what is needed.

If this action needs the input's #name key from the form render array, why not just say that ?

Thanks again! I'd love to better understand this topic.

If this action needs the input's #name key from the form render array, why not just say that ?

That's not how the action behaves internally. It could be added as a fallback behaviour if it didn't find a form field element otherwise, as suggested in #5. Mostly, form field elements are being identified by their array key within the form render array, prepended by their "#parents" key entries. Nevertheless, we have an obvious room for optimization here, both regarding the description and its internal behaviour.

thank you for taking the time to respond here! I thought I understood by now I'm more lost. It sounded like a user needs to enter a value from the render array, but now it seems that is wrong as well.

Is it possible to explain what a user is supposed to enter in the Field name field on this action in order for the action to run ?

If it's not something that can be explained, or if it's something that changes drastically depending on the situation, then there's not a field label or help text or even documentation that will solve the issue. If this is the case, I'd lean towards identifying this as a bug, rather than a documentation issue.

It sounded like a user needs to enter a value from the render array, but now it seems that is wrong as well.

I just described the internal behavior above, trying to explain why the current behavior is what it is. The user of the plugin is supposed to enter the input name of a form field, as the help text describes. The internal behavior is then supposed to resolve that. However, it's not that easy, because it's not consistent how the form render array is being built up - otherwise it would already work.

Is it possible to explain what a user is supposed to enter in the Field name field on this action in order for the action to run ?

As said, the name which can be found in the according input element as attribute, is what mostly works. Especially when it's a textfield, options etc. or any other sort of form input. Submit buttons however are currently a bit of a special case, and that's why there not part of mostly for now. We could consider improving the behavior as mentioned above.

I agree that we may now handle this as a bug.

I took a closer look into the current behavior, and it turns out that usually, all form submit buttons in a content form share the same name "op". That leads to the fact that the suggested improvement of the internal behavior doesn't make much sense, as finding an element named as "op" would then only return one (of possibly multiple) elements.

The only aspects I could improve in a matter of justified time was by adding a descriptive text when the access result denied is being logged. I also added a sentence into the description for the form's "Field name" specifically for the labeled "Save" and "Preview" buttons, which are mostly found when working on a content form. Hope that might be helpful in the future.

This looks like the best we can do for now. Thanks @mxh

Merged and back ported.

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