User tests: Successful: Unsuccessful:
Pull Request for New Feature.
previous discussion of several approaches that led to this solution:
This RFC proposes to extend the configuration of com_fields to better control the displaying of Fields on (component edit / create) Forms. This functionality will greatly extend the use cases for com_fields (and therefore for Joomla!) in ‘real-life’ implementations.
In this PR, #19884 is 'cherry picked' (currently in staging) as this is a required bug fix for com_fields.
This RFC proposes to extend the configuration of com_fields to better control the displaying of Fields on (component edit / create) Forms. This functionality will greatly extend the use cases for com_fields in ‘real-life’ implementations.
I run a large blog site where the blogs are ‘enriched’ with custom fields to add credits, opengraph image / title / description, twitter card image / title / description to the blogs. The access to these field values must be set to public in order for visitors / facebook / twitter etc. to ‘see’ the given values.
These filling of these fields must be limited to the publisher role to avoid mis usage and to comply to site standards (for images).
The fields should be invisible to authors in order to avoid ‘support calls’: what are these fields for, why cannot I edit them, etc.
With the current configuration settings this is not possible:
I run a membership site where users subscribe to a service. Depending on their subscription, values can be set in their user profile via com_fields. The amount of fields for all subscriptions total up to 50 fields.
The values set in these fields should be visible on the front-end (via a special view that reads the user’s set value (via com_fields api)), the access to these fields must be set to public in order for public and guests to see the values for a specific user.
Specific fields should only be visible on the user profile edit form for the groups the user is member of and where these fields should be assigned to.
Furthermore: because the fields access is set to public, when a new user registers on the site, all (!) 50 fields are shown in the registration form as read-only, where the registering user needs to scroll down past all the read-only fields to reach the actual register button. Only the fields that are necessary in the form should be displayed.
The current limitation lies in the fact that the access field is used for both the form AND for the values.
I propose to extend com_fields with an additional parameter: Display on Forms
The Display on Forms setting holds the group that a user needs to be member of in order to be able to see the field on the form.
The Display on Forms setting can be set on field level AND on group level, making the maintenance of large field sets easier as not every field needs to be modified when the Display on Forms setting value changes (can be set on fields group level).
With the proposed change, the following configuration can be set for the com_content fields:
Users that do not have sufficient Access rights to edit the fields will also not see these fields on the article edit / creation form. This will make the edit / create form very UX friendly as only relevant fields are displayed on the form!
With the proposed change, the following configuration can be set for the com_users fields:
The benefit here is that users that do not have sufficient Access rights to edit the fields will also not see these fields on their user profile edit form. This will make the edit form very UX friendly as only relevant fields are displayed on the form!
in italics described above
Fields are always displayed write or read-only
yes, com_fields gets new configuration field
EDIT: changed test instruction
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_fields Language & Strings |
Labels |
Added:
?
?
|
In core we either have access levels for view access and permissions for editing. Just having a user group field is none of them and is for me a step into the wrong direction. I mean the edit.core.value permission defines who can edit the field. What we want to define basically is the behavior when no permissions are available but the user can edit the item in general. So for me, it would be enough to just have a hide/show switcher which defines if the field should be shown or not, when no permission is given.
Under Field Groups, swap Publishing and Options tabs to match under Fields.
Can't seem to control that as this is automatically 'pulled-in' from the groups.xml file. Changing the order in the xml does not change the order in the form? Need to look into this (which for me isn't blocking). First need to get some more traction and direction in these PR's
Tested only with com_content and got all 3 fields with Author and 2 fields (no credits) with Publisher which are different than stated in the testing instructions.
You tested correct, the instructions where a copy and paste from the access_form view level PR. access levels are respecting hierarchy, so publisher also has author rights. when using groups however, publisher is publisher only. Will update test instructions Instructions updated :)
In core we either have access levels for view access and permissions for editing. Just having a user group field is none of them and is for me a step into the wrong direction.
There are two ways of getting this done: via access levels (see other PR) which raised a red flag as that was not the way to do it, and via user groups which... well...
This PR is NOT about edit rights, it is about displaying the field (for the component who utilizes com_fields) on the edit form
What we want to define basically is the behavior when no permissions are available but the user can edit the item in general. So for me, it would be enough to just have a hide/show switcher which defines if the field should be shown or not, when no permission is given.
That was also one of the cases I worked out, but although it does the initial requirement, it 'lacks' potential future use cases. Setting this on a usergroup / access level adds much more flexibility and functionality.
If only we could agree on the how...
The good thing here is that for me doing it via Access Levels or via User groups is both acceptable and doable.
The bad thing is that you can almost see me waving with something that looks like a white flag, but that actually is the towel I am about to throw in :S
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-04-07 14:55:16 |
Closed_By | ⇒ | Quy |
Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/20039
Closed_Date | 2018-04-07 14:55:16 | ⇒ | 2018-04-07 14:55:17 |
Closed_By | Quy | ⇒ | joomla-cms-bot |
Closing in favor for #20068
Under
Field Groups
, swapPublishing
andOptions
tabs to match underFields
.Tested only with
com_content
and got all 3 fields withAuthor
and 2 fields (no credits) withPublisher
which are different than stated in the testing instructions.