On April 18th, 2018 Joomla version 3.8.7 was released. In this release is a new com_fields feature that will extend the use cases for com_fields massively.
What functionality does this new feature add?
In short: The change allows you to configure whether to show a field on a form based on the field's permission.
Previously, all fields where displayed in a user's profile edit / registration form. Even when the logged in user did not have edit permissions for the field. The field would be displayed as read-only (greyed out). The same for article fields and the article edit / create form.
You could hide the fields from these forms by setting the access level for the field to the ACL group the user was member to, but that leads to the (possible) undesirable effect that also the value set in the field is only shown to logged in users with the appropriate access level.
Use Case User Registration
On my website I use Custom Fields that allow authors to upload an avatar, set follow me links to their profile, upload a background image for their blog profile page and set an about me description. The values set should have an Access Level of Public: when displaying a blog to a visitor (public), the values in the fields should show in the blog: the avatar, the follow me links and the about me text.
Only members of the author ACL have create field value permissions.
Now when a new user registers on my website, all Custom Fields where added as read-only to the form. Cluttering the form with (for a normal user) useless 'greyed-out' fields.
Use Case Articles
A blog site uses ochOpenGraph to add images that should be added to the blog as twitter:image and og:image tags. The images must comply to the website's design principles and for that reason, uploading and selecting these images will be limited to and done by publishers. The images set should have Access Level of Public: when e.g. Facebook scrapes the blog (public) the image url should be readable.
Only members of the Publisher ACL should be able to add these images (via the back-end / front-end) to the blog.
New when an author adds a new blog, the Custom Fields where added as read-only to the article create / edit form. Adding useless information for these authors leading to questions and confusing: "Why are they there if I cannot use them?
As you can see there was no way to hide these read-only fields on forms for users, leading to confusion and unwanted 'support calls'.
Here comes change 'Improved handling of read-only field data in com_fields #20068'
What I have done in this change is add an option to both the field Groups and Field (options tab): 'Display When Read-Only'
How does this work?
The default behavior is to show read-only fields on forms (in order to not break Backward / Compatibility).
On the Group level you can set the 'Display When Read-Only' option to Yes or to No. The value set will be used for all fields in that group.
On the Field you can set the 'Display When read-Only' option to Inherit, Yes or No.
Inherit will use the value set on the group the field is member of, Yes will force the displaying of the field when read-only regardless of the value set in the group, No will force the hiding of the field regardless of the value set in the group.
So back to the Use Cases:
Use Case User Registration
I have set the Group 'Display When Read-Only' to No for the group the fields avatar, follow me, about me and background image are member of.
When a new user registers or an existing user edit's his / her profile, these fields will not be displayed. No use in showing them as they are read-only and there for useless for these users.
But when an author edits his / her profile, the fields will display because the fields can be filled / edited!
Use Case Articles
I have set the Group 'Display When Read-Only' to No for the group the fields that only publishers have write permissions for.
So when an author creates a new blog or edits an existing blog these fields will not show on the form because they are read-only.
But when a publisher edits or creates a blog the fields show on the form and the publisher can use them to add the correct images / information.
So there you have it.
A simple change that extends the usage of com_fields to a lot more use cases.
What do you think, a valuable change?
Love to hear from you when you use this feature on your site!