[#22923] - [3.9.1] [com_fields] Make sure disabled fields are not added to the request at all
- Fixed in Code Base
- 7 Mar 2019
- Medium
- Build: staging
- # 22923
- Diff
- zero-24:disabled_fields
User tests: Successful: Unsuccessful:
Pull Request for Issue #22038 & #22519
Summary of Changes
Make sure disabled fields are not added to the request at all
Testing Instructions
- Create a custom field for your articles.
- Check that ACL is set to edit this field only at super user (this is the default) and set it for Editor to denied
- create an Article as an Editor (Usergroup)
- You can't save the Article because of an Error "Invalid Field"
Expected result
Error is gone
Actual result
Documentation Changes Required
none.
cc @laoneo Please let us know you opinion / technical insight here. As disabled should not be used for security we might also need to change more places too?
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End Plugins |
It does not work with media and repeatable types.
It does not work with media and repeatable types.
What does not work? And what is different for that types?
I get the invalid field error message.
We added this function in #19884, which fixed some issues that checks couldn't be done if fields was loaded or not. Where exactly is the error thrown? Because the field should be added in a disabled state, so validate should not check that at all. This change is not fixing the cause. I think there is something wrong in the Controller or Form class itself.
Where exactly is the error thrown?
https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Form/Form.php#L2070-L2081
I have tested this item
First I have created a custom field and I saw the error on article saving
I used a editor user trying to submit an article. The field had superuser permits
Then I applied the patch but nothing happened, the error was still there
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/22923.
| Labels |
Added:
?
|
||
Just run into this issue for the front-end profile.edit view in 3.9.2. I assume all components using custom fields with configurable permissions will have the same issue.
An alternative solution that seems to work for me is to set the field value to null. Either always or only when the field is disabled. But I don't really know why bool(false) is selected over null, nor why the missing field values are being injected, so I can't really offer a concrete opinion over this
This problem is also manifesting itself in Edit User Profile when we have User Fields defined as Read Only through setting the permission on Edit Custom Field on Denied.
The fields are then shown in Edit User Profile, but as soon as the form is submitted, all Read Only fields are blanked out and made invalid.
I really hope this can be fixed in next drop.
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-03-07 17:22:48 |
| Closed_By | ⇒ | HLeithner |
thx
Seems to work as desired,
also tested with checkboxes field and with multi-select field (list with multiple on)
Also the logic of this seems correct
you would add the presence of the field via "normalizing" code to detect empty fields that are not posted (checkboxes, multi-select, other??)
thus to make possible to submit empty values for them,
but when they are disabled (due to ACL) the proper thing is to keep their existing DB value and this works
Thx for the test!
when they are disabled (due to ACL) the proper thing is to keep their existing DB value and this works
Just a note, I found out that this does not work for the new Subfields
Meaning that saving a subfields type that contains a disabled/hidden child field (due to ACL), will empty the value for that child field, instead of keeping the existing value for it
I have tested this item✅ successfully on 7abc845
Now the field works as expected, thank you!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/22923.