{"action":"created","issue":{"url":"https://api.github.com/repos/joomla/joomla-cms/issues/20039","repository_url":"https://api.github.com/repos/joomla/joomla-cms","labels_url":"https://api.github.com/repos/joomla/joomla-cms/issues/20039/labels{/name}","comments_url":"https://api.github.com/repos/joomla/joomla-cms/issues/20039/comments","events_url":"https://api.github.com/repos/joomla/joomla-cms/issues/20039/events","html_url":"https://github.com/joomla/joomla-cms/pull/20039","id":310244002,"number":20039,"title":"Custom fields view on form via params","user":{"login":"Ruud68","id":2733197,"avatar_url":"https://avatars1.githubusercontent.com/u/2733197?v=4","gravatar_id":"","url":"https://api.github.com/users/Ruud68","html_url":"https://github.com/Ruud68","followers_url":"https://api.github.com/users/Ruud68/followers","following_url":"https://api.github.com/users/Ruud68/following{/other_user}","gists_url":"https://api.github.com/users/Ruud68/gists{/gist_id}","starred_url":"https://api.github.com/users/Ruud68/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Ruud68/subscriptions","organizations_url":"https://api.github.com/users/Ruud68/orgs","repos_url":"https://api.github.com/users/Ruud68/repos","events_url":"https://api.github.com/users/Ruud68/events{/privacy}","received_events_url":"https://api.github.com/users/Ruud68/received_events","type":"User","site_admin":false},"labels":[{"id":198658453,"url":"https://api.github.com/repos/joomla/joomla-cms/labels/Language%20Change","name":"Language Change","color":"eb6420","default":false},{"id":60721348,"url":"https://api.github.com/repos/joomla/joomla-cms/labels/PR-staging","name":"PR-staging","color":"c7def8","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-03-31T14:18:25Z","updated_at":"2018-04-03T07:47:45Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/joomla/joomla-cms/pulls/20039","html_url":"https://github.com/joomla/joomla-cms/pull/20039","diff_url":"https://github.com/joomla/joomla-cms/pull/20039.diff","patch_url":"https://github.com/joomla/joomla-cms/pull/20039.patch"},"body":"Pull Request for New Feature.\r\n\r\n### Summary of Changes\r\nprevious discussion of several approaches that led to this solution:\r\n\r\n- https://issues.joomla.org/tracker/joomla-cms/19473\r\n- https://issues.joomla.org/tracker/joomla-cms/19996\r\n\r\n### Summary of Changes\r\n\r\nThis 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.\r\n\r\nIn this PR, #19884 is 'cherry picked' (currently in staging) as this is a required bug fix for com_fields.\r\n\r\n## Current Limitations\r\nThis 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.\r\n### Use Case com_fields and com_content:\r\nI 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.\r\n\r\nThese filling of these fields must be limited to the publisher role to avoid mis usage and to comply to site standards (for images).\r\n\r\nThe fields should be invisible to authors in order to avoid ‘support calls’: what are these fields for, why cannot I edit them, etc.\r\n\r\nWith the current configuration settings this is not possible:\r\n- 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.\r\n- 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.\r\n- 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.\r\n### Use Case com_fields and com_users:\r\n\r\nI 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.\r\n\r\nThe 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.\r\n\r\nSpecific 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.\r\n\r\n- 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\r\n-  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.\r\n- 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.\r\n\r\nFurthermore: 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.\r\n## Proposed Change\r\nThe current limitation lies in the fact that the access field is used for both the form AND for the values.\r\n\r\nI propose to extend com_fields with an additional access view level: Access Form\r\n\r\nThe Access Form holds the ACL group that a user needs to be member of in order to be able to see the field on the form.\r\n\r\nThe Access Form 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 Access Form value changes (can be set on fields group level).\r\n### Use Case com_fields and com_content:\r\n\r\nWith the proposed change, the following configuration can be set for the com_content fields:\r\n1. Access = Public (as the values set need to be displayed to visitors)\r\n2. Show on: both (as the fields should be BOTH editable via the back-end AND front-end)\r\n3. ACL permission: set Edit Custom Field Value permission to publisher (only members of the publisher acl can set and edit the field values)\r\n4. (proposed setting) Access Form: set to publisher (only publishers will have the fields on the article edit / creation form.\r\n\r\nUsers 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!\r\n### Use Case com_fields and com_users:\r\n\r\nWith the proposed change, the following configuration can be set for the com_users fields:\r\n1. Access = Public (as the values set need to be displayed to visitors)\r\n2. Config setting Show on: both (as the fields should be BOTH editable via the back-end AND front-end)\r\n3. ACL permission: set Edit Custom Field Value permission to public (only members of the public acl can set and edit the field values)\r\n4. (proposed config setting) Display on Forms: set to ‘subscription group’ (only subscribers to the ‘subscription group’ will have the fields on their user profile edit form.\r\n\r\nThe 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!\r\n\r\n### Testing Instructions\r\n#### Test Case: com_users\r\n1. in com_users create a fields group:\r\n-  title: user details\r\n- permissions: Edit Custom Field Value > public > allowed\r\n- Access Form (new field): Public\r\n2. in Com_users create 3 new fields:\r\n- title: address, type text, access form: registered, field group: user details\r\n- title: town, type text, access form: registered, field group: user details\r\n- title: country, type: text, access form: public, field group: user details\r\n3. In the front-end: register a new user account\r\n_Without this PR: fields address, town and country are visible on registration form\r\nWith this PR: only field country is visible on registration form_\r\n4. In the front-end: login with user account en edit user profile\r\n_all fields: address, town, country are visible_\r\n5. In back-end:change com_user field town > Access Form = Author\r\n6. In the front-end: login with user account and edit user profile\r\n_Fields: address and country are visible, town is not visible for this user_\r\n7. change user group access to author, login with this user and edit user profile:\r\n_all fields: address, town, country are visible_\r\n\r\n#### Test Case: com_content\r\n\r\n1. in com_user: create Viewing Access Levels for Author and Publisher\r\n2. in com_content create a fields group:\r\n-  title: Blog info\r\n-  permissions: Edit Custom Field Value > Author > allowed\r\n-  Access Form (new field): Author\r\n3. in com_content create 3 new fields:\r\n- title: opengraph image, type: media, access form: publisher, field group: Blog info\r\n- title: opengraph description, type: editor, access form: publisher, field group: Blog info\r\n- title: credits, type: editor, access form: author, field group: Blog info\r\n4. Login on the front-end with a user account with author (no editor/ publisher etc.) rights and edit an article created by this user\r\n_Without this PR, a tab Blog Info will be shown with all fields on it\r\nWith this PR, a tab Blog Info will be shown with only the field 'Credits' shown_\r\n5. In the back-end change the group for the user to publisher\r\n6. Repeat step 4\r\n_A tab Blog info is shown with all three fields on it._\r\n\r\n### Expected result\r\nin _italics_ described above\r\n\r\n### Actual result\r\nFields are always displayed write or read-only\r\n\r\n### Documentation Changes Required\r\nyes, com_fields gets new configuration field\r\n"},"comment":{"url":"https://api.github.com/repos/joomla/joomla-cms/issues/comments/378159625","html_url":"https://github.com/joomla/joomla-cms/pull/20039#issuecomment-378159625","issue_url":"https://api.github.com/repos/joomla/joomla-cms/issues/20039","id":378159625,"user":{"login":"Ruud68","id":2733197,"avatar_url":"https://avatars1.githubusercontent.com/u/2733197?v=4","gravatar_id":"","url":"https://api.github.com/users/Ruud68","html_url":"https://github.com/Ruud68","followers_url":"https://api.github.com/users/Ruud68/followers","following_url":"https://api.github.com/users/Ruud68/following{/other_user}","gists_url":"https://api.github.com/users/Ruud68/gists{/gist_id}","starred_url":"https://api.github.com/users/Ruud68/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Ruud68/subscriptions","organizations_url":"https://api.github.com/users/Ruud68/orgs","repos_url":"https://api.github.com/users/Ruud68/repos","events_url":"https://api.github.com/users/Ruud68/events{/privacy}","received_events_url":"https://api.github.com/users/Ruud68/received_events","type":"User","site_admin":false},"created_at":"2018-04-03T07:47:45Z","updated_at":"2018-04-03T07:47:45Z","author_association":"CONTRIBUTOR","body":"> Under Field Groups, swap Publishing and Options tabs to match under Fields.\r\n\r\nCan'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\r\n\r\n>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.\r\n\r\nYou 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 :)\r\n\r\n> 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.\r\n\r\nThere 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...\r\nThis PR is NOT about **edit** rights, it is about **displaying** the field (for the component who utilizes com_fields) on the edit form\r\n\r\n> 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.\r\n\r\nThat 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.\r\n\r\nIf only we could agree on the how...\r\n\r\nThe good thing here is that for me doing it via Access Levels or via User groups is both acceptable and doable.\r\nThe 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\r\n\r\n"}}
{"actor":{"display_login":"Ruud68"}}