This is consistent with other places in Joomla. If you can't edit a property (edit permission) but are allowed to see it (viewlevel), then it is shown as readonly.
If you don't want to show the field, just adjust the viewlevel to registered (just not public) and it will not be shown anymore in the registration form.

Hi Valuable, but then it will not be shown to guest / visitors of the website when the page tried to show the value (e.g. avatar, about text, follow me links, etc) because the visitor is not 'registered'.
If you want to use the custom user Fields to capture user info based on group membership this is unworkable as every user will see all Fields in their profile of which many are not relevant to them: which leads to confusion and support requests.

Damn autocorrect :( all though bakual = also valuable :)))

This is consistent with other places in Joomla.

This then also limits the 'other places' in Joomla.
when you have custom article fields that you only want e.g. publishers to edit and create, they will be shown as read-only to an author (who is wondering why he is seeing this information in the first place).
For me this could be improved either by:

1. create a 'Create Custom Field value' permission (with a default value = Allowed)
2. change the the Registration Form and Edit User Profile form to not show Fields that the user cannot edit.

I think #2 is only an option when done via a per site template override as changing an tmpl form has possible high impact. This also changes the current behavior (now you see the read-only values, after this change you don't)

For me #1 would be the ultimate solution: this can be added both for Users as for Articles and will not change the current behavior.

In case the Access for a Custom Field is set to public, and

a. the Create Custom Field value = No + Edit Custom Field value = No

• do not show empty (!) Fields
• do show filled (e.g. by administrator or from previous rights) fields

b. the Create Custom Field value = Yes + Edit Custom Field value = No

• same as current fresh install: show all fields as read-only (even the empty ones)

c. the Create Custom Field value = Yes + Edit Custom Field value = Yes

• same as currently: show all fields and allow edit of value (even the empty ones)

What do you think of this proposed solution?
Who should have a look at this? (tag your friends they would say on FaceBook :))
Are there other scenarios possible to address this?

I can create some time to create a PR to address this

What is the usecase where you have a field in the edit profile form which shouldn't be editable by the user but visible to public in the profile view?

I could see to make a difference between registration and profile form, but not sure if that is possible to do. It may be something that is better done using an override.

As for a "create" permission, that already exists and referes to creating a custom field. Imho, it becomes very confusing if you start adding more permissions (eg "edit value in registration").

Hi, here is a (simple) use case:

I have a custom fields plugin where authors can input links to their social profiles. These are then rendered into follow me buttons.
This field should only be available to authors.
So setting the Access to 'Author' group.

Now when an author logs in, the field is displayed in his profile and he can enter the links.
When a registered user logs in the field is NOT visible in his profile page (because this person is not member of the author group): so far so good.

I use the following code to display the rendered filed value for the field for an author to show in his article:

	$user = JFactory::getUser($articleAuthorId);
	$jcFields = FieldsHelper::getFields('com_users.user', $user, true);

The problem now is that when a visitor visits the article, the $jcFields = empty
When I log in with a user with sufficient rights (author), the the $jcFields has all the (rendered) values I can use. The access check is done for the visitor and not for th user passed in the $user object.

I can 'fix' this in two ways:

1. set the Access for the field to public > but then the field will also be displayed in the registration form and in the profile form of all users
2. use to following code to get the field value

	$fieldModel = JModelLegacy::getInstance('Field', 'FieldsModel', array('ignore_request' => true));
	$value = $fieldModel->getFieldValue($jcFieldId, $authorId);

regardless of the access setting, this always returns the value, but the value is as entered in the field, NOT rendered (so it is the links as entered, not the icons). There is NO authorization check done here to validate if the visitor has sufficient access rights to the data!

So I need to (figure out how to) render it myself. (This could also solve this issue)

OR, and this is where the permission 'Create Custom Field Value' comes into play, set access to Public (public should be able to see the contents of the field), but only users with permissions to 'Create Custom Field Value' should be able to see them / create them for their own account.

@laoneo Not sure what to think here. I think com_users is a special case here. I certainly don't want com_users specific code in com_:fields.

@Bakual, as you said, it is consistent with other places like articles, only here (articles) you can set the view access to public as registered users cannot see the Custom articles field in their create / edit form (you need to have author rights to see the create article form). But the issue is the same: maybe you want authors of group x to see some fields that 'regular' users don't see? Now they see them (as read only).

But still, if we can implement this, it will add to the possibilities for custom fields to extend you own components functionality. Before 3.7 I would have created a component (with all overhead involved) to have a user add the follow me buttons, avatar, about text, etc. Now I use the Custom User fields for that, but as discussed there is a limitation in using it because of the 'missing' feature to show or not show in create / edit forms.

It gets messy very fast as soon as two groups can edit the same item and they don't see the same fields.
It can mean those with lower permissions delete the content from the fields that they don't see.

It can mean those with lower permissions delete the content from the fields that they don't see.

It can mean or it means?

Not looked into the 'save' code, but this definitely a test case.

It can mean or it means?

I haven't tested but afaik we had that issue in the past. It's something to keep in mind.

Okay, have been doing some actual coding today. I have it working for com_users (without touching com_users).
I have added a 'Display Custom Field Value' with which you can set the permission to show or not show the fields. (I didn't call it 'Create', because that didn't do justice to this feature)
I have tested this for com_users, will be doing some testing for com_contacts and com_content. These use the same code base so It should work out okay.
When I have tested, I will create a PR so you guys can have a look :)

I haven't tested but afaik we had that issue in the past. It's something to keep in mind.

The change is in public static function prepareForm($context, JForm $form, $data), when no display rights it will NOT add the fields to the form. That would also mean that fields cannot corrupt / get overwritten, etc.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/19468

closed as having Pull Request #19473

okay, PR is done: works (for me) like a charm and extends the Custom Fields with the functionality to better use it in real-life use cases :)

https://issues.joomla.org/tracker/joomla-cms/19473