Joomla! Issue Tracker | Joomla! CMS #20068 - Custom Fields toggle display on read only rights

? ? ?

Fixed in Code Base
7 Apr 2018
Medium
Build: staging
# 20068
Diff
Ruud68:CustomFieldsToggleDisplayReadOnly

Pending

Pending continuous-integration/drone/pr this build is pending Details

User tests: Successful: Unsuccessful:

Ruud68
3 Apr 2018

Pull Request for New Feature.

This PR is part of Jomla! 3.8.7. Use instructions can be found here: https://onlinecommunityhub.nl/community-tools/improved-handling-of-read-only-field-data-in-com-fields

Summary of Changes

previous discussion of several approaches that led to this solution:

https://issues.joomla.org/tracker/joomla-cms/19473
https://issues.joomla.org/tracker/joomla-cms/19996 (via ACL)
https://issues.joomla.org/tracker/joomla-cms/20039 (via Group membership)

Summary of Changes

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.

Current Limitations

Use Case com_fields and com_content:

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 can't I edit them, etc.

With the current configuration settings this is not possible:

Setting the Access to publisher will prevent the fields from displaying on the article editing / creation form, but will also only display the values set in these fields to publisher only: public / guest will not see the values set.
using show on administrator will partly work, but the publishers need to be able to login via the back-end. The show on parameter is ACL independent (simple toggle). Publishers do not have access to the back-end but need access to these fields via the front-end.
setting the ACL to only allow publishers to Edit Custom Field Value, will display the fields on everybody’s article edit / creation form (including authors) as read-only except for the groups that have the correct permissions. This will clutter the article edit / creation form with a lot of read-only fields with the possibility that in the long list of fields some fields are read-only and some are editable.

Use Case com_fields and com_users:

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 when the user can edit (has Edit Custom Field Value' permission set to aloowed)

Setting access to a field to the specific group that the fields belongs to does not work as this will also make the values set in these fields inaccessible to public. The values can only be seen by the users that have group membership the field access is set to
using show on administrator will now work, because it is a generic toggle that is independent of group ACL membership: They are either all shown or all invisible. Furthermore no users have access to the back-end.
Setting the ACL to only have specific user groups Edit Custom Field Value rights will display all fields on the user profile edit form: most read-only and some where values can be set. Only the fields where values can be set should be shown on the user edit profile form.

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.

Proposed Change

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 when read-only'

The 'Display when read-only' setting toggles whether to display the field on the form when the field is read-only or not.

The 'Display when read-only' 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 when read-only' setting value changes (can be set on fields group level).
Setting the value on field level has authority over the setting in the fields group!

Use Case com_fields and com_content:

With the proposed change, the following configuration can be set for the com_content fields:

Access = Public (as the values set need to be displayed to visitors)
Show on: both (as the fields should be BOTH editable via the back-end AND front-end)
ACL permission: set Edit Custom Field Value permission to publisher (only members of the publisher ACL can set and edit the field values)
(proposed setting) 'Display when read-only': set to 'No'.

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!

Use Case com_fields and com_users:

With the proposed change, the following configuration can be set for the com_users fields:

Access = Public (as the values set need to be displayed to visitors)
Config setting Show on: both (as the fields should be BOTH editable via the back-end AND front-end)
ACL permission: set Edit Custom Field Value permission to public (only members of the public acl can set and edit the field values)
(proposed config setting) 'Display when read-only': set to 'No'.

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!

Testing Instructions

Test Case: com_users

in com_users create a fields group:

title: user details
permissions: Edit Custom Field Value > Registered > allowed
'Display when read-only' (new field): Yes

in Com_users create 3 new fields:

title: address, type text, 'Display when read-only': No, field group: user details
title: town, type text, 'Display when read-only': No, field group: user details
title: country, type: text, 'Display when read-only': Inherit, field group: user details

In the front-end: register a new user account
Without this PR: fields address, town and country are visible on registration form
With this PR: only field country is visible on registration form
In the front-end: login with user account and edit user profile
all fields: address, town, country are visible
try changing the field group 'Display when read-only' setting and the field 'Display when read-only' setting and see if the displaying or not of read-only values is as expected

Test Case: com_content

in com_user: create Viewing Access Levels for Author and Publisher
in com_content create a fields group:

title: Blog info
permissions: Edit Custom Field Value > Publisher > allowed
'Display when read-only' (new field): Yes

in com_content create 3 new fields:

title: opengraph image, type: media, 'Display when read-only' (new field): No, field group: Blog info
title: opengraph description, type: editor, 'Display when read-only' (new field): No, field group: Blog info
title: credits, type: editor, 'Display when read-only' (new field): Inherit, field group: Blog info

Login on the front-end with a user account with author (no editor/ publisher etc.) rights and edit an article created by this user
Without this PR, a tab Blog Info will be shown with all fields on it (read-only)
With this PR, a tab Blog Info will be shown with only the field 'Credits' shown (read-only)
In the back-end change the group for the user to publisher
Repeat step 4
A tab Blog info is shown with all three fields on it.
try changing the field group 'Display when read-only' setting and the field 'Display when read-only' setting and see if the displaying or not of read-only values is as expected

Expected result

in italics described above

Actual result

Fields are always displayed write or read-only

Documentation Changes Required

yes, com_fields gets new configuration field

b2c4d4e 3 Apr 2018

[com_fields] Normalise the request com_fields data (#19884)

8c87352 3 Apr 2018

Custom fields view on form via toggle on read-only rights

Ruud68 - open - 3 Apr 2018

Ruud68 - change - 3 Apr 2018

Status

New

⇒

Pending

joomla-cms-bot - change - 3 Apr 2018

Category

⇒

Administration com_fields Language & Strings

laoneo - comment - 3 Apr 2018

This is for me the approach which brings in less confusion. +1 from me.

Ruud68 - comment - 3 Apr 2018

@laoneo Cool :) can you test if it works? that would be really a +1 :))

ot2sen - comment - 3 Apr 2018

I have tested this item ? unsuccessfully on 8c87352

First part of testing went fine, read only did show the country on reg as read only and then all 3 field on edit user and they could be edited.

At second part I bumped into an issue when wanting to create an article for author in backend to be able to edit that in front. Article->New is broken with the patch

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20068.}

ot2sen - test_item - 3 Apr 2018 - Tested unsuccessfully

ot2sen - comment - 3 Apr 2018

Screenshot of the error

78b8d0f 4 Apr 2018

fix back-end new article

Ruud68 - change - 4 Apr 2018

Labels

Added: ? ?

Ruud68 - comment - 4 Apr 2018

Goodmorning all :)

At second part I bumped into an issue when wanting to create an article for author in backend to be able to edit that in front. Article->New is broken with the patch

@ot2sen fixed :)

@ggppdk also removed he administrator check, so now also it displays / hides fields on back-end as well (not sure what I was thinking here :)).

@laoneo can you advice?

I can add show_on: site / administrator / both also on field group (currently only on field)
I can move the check for show_on from fieldsplugin.php into helper function where we now do the read-only check. That way we have one helper function that handles the display on forms (yes / no) instead of having this in multiple places (rename displayReadOnlyFieldOnForm to displayFieldonForm).
would an additional setting on field level of 'inverse' (yes, no, inverse) be a good idea? Inverse would inverse the group setting. So that you can set all fields in a group to No via the group setting except the field(s) that have set inverse? So when group = no, inverse would make field yes?

group | field   = display?
------------------------
yes   | yes     = yes
no    | yes     = no
yes   | no      = no
no    | no      = no
yes   | inverse = no
no    | inverse = yes

f474bee 4 Apr 2018

first / seperate check on read-only access

2738876 4 Apr 2018

refactor code so show_on parameter is part of helper function

Ruud68 - comment - 4 Apr 2018

Just refactored code to have generic helper function displayFieldOnForm that handles both the show_on parameter and the display_readonly parameter.

ggppdk - comment - 4 Apr 2018

Just refactored code to have generic helper function displayFieldOnForm ...

Now looks like a much cleaner implementation

602cc08 4 Apr 2018

implement inherit value in fields + language things

Ruud68 - comment - 4 Apr 2018

Added 'Inherit' value in field. So now you can select yes / no / inherit. Inherit is the default value.
Inherit takes the value from the field's group (and if no group the defaults to 'yes')
this way the value set in the field always has the authority over the value set in the group parameter.
thanks @laoneo :)

Now one more question left: should the show_on parameter also have a group setting or do we leave that as is (only field setting)?

b0156d2 4 Apr 2018

loadmodel only when needed

laoneo - comment - 4 Apr 2018

If you consider to add a group setting for show_on, then please do it in a new pr.

Ruud68 - change - 4 Apr 2018

The description was changed

Ruud68 - edited - 4 Apr 2018

Ruud68 - comment - 4 Apr 2018

f you consider to add a group setting for show_on, then please do it in a new pr.

I will not use that setting myself (the display_readonly does it all for me), was just thinking in terms of consistency with this PR.
Let's wait and see how the testing and feedback on this PR rolls, if asked for then we can decide to do it (in separate PR)

70fb494 4 Apr 2018

changed function comment

b983c4f 4 Apr 2018

change values order so default value (inherit) is displayed first

41df5e9 4 Apr 2018

Must use self:: for local static member reference

ot2sen - comment - 4 Apr 2018

I have tested this item ✅ successfully on 41df5e9

Works fine now. Well done :)

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20068.}

ot2sen - comment - 4 Apr 2018

I have tested this item ✅ successfully on 41df5e9

Works fine now. Well done :)

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20068.}

ot2sen - test_item - 4 Apr 2018 - Tested successfully

Ruud68 - comment - 4 Apr 2018

@ot2sen thanks for re-testing and reporting back! Appreciate it :)

Quy - comment - 6 Apr 2018

I have tested this item ✅ successfully on 41df5e9

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20068.}

Quy - test_item - 6 Apr 2018 - Tested successfully

Quy - change - 6 Apr 2018

Status

Pending

⇒

Ready to Commit

Quy - comment - 6 Apr 2018

RTC

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20068.}

mbabker - change - 7 Apr 2018

Status	Ready to Commit	⇒	Fixed in Code Base
Closed_Date	0000-00-00 00:00:00	⇒	2018-04-07 14:32:25
Closed_By		⇒	mbabker
Labels	Added: ?

mbabker - close - 7 Apr 2018

mbabker - merge - 7 Apr 2018

Ruud68 - change - 20 Apr 2018

The description was changed

Ruud68 - edited - 20 Apr 2018

Add a Comment

Older
Newer

Joomla! Issue Tracker - CMS

[#20068] - Custom Fields toggle display on read only rights

This PR is part of Jomla! 3.8.7. Use instructions can be found here: https://onlinecommunityhub.nl/community-tools/improved-handling-of-read-only-field-data-in-com-fields

Summary of Changes

Summary of Changes

Current Limitations

Use Case com_fields and com_content:

Use Case com_fields and com_users:

Proposed Change

Use Case com_fields and com_content:

Use Case com_fields and com_users:

Testing Instructions

Test Case: com_users

Test Case: com_content

Expected result

Actual result

Documentation Changes Required

Add a Comment