Setting ACL for read-only custom User fields

[djc1]

I have a site running Joomla 3.9.2 with several User Custom Fields.
I want a couple of those fields to be read-only, so the Edit Custom Field Value permission is set to Denied.
When a user displays his profile, the read-only field shows up fine, but when the user edits his profile and then goes to save the profile, he will always get a Warning: Invalid Field for the read-only field.

Why is that and how do I get rid of it?

Thanks!

[djc1]

I posted this in the general Administration forum, but it might be better as I think it could be an ACL settings issue:
I have a site running Joomla 3.9.2 with several User Custom Fields.
I want a couple of those fields to be read-only, so the Edit Custom Field Value permission is set to Denied.
When a user displays his profile, the read-only field shows up fine, but when the user edits his profile and then goes to save the profile, he will always get a Warning: Invalid Field for the read-only field.

Why is that and how do I get rid of it?

Thanks!

[nonickch]

This appears to be almost identical to https://github.com/joomla/joomla-cms/pull/22923 : "[3.9.1] [com_fields] Make sure disabled fields are not added to the request at all #22923"

The linked issue refers to articles, but the profile custom fields have exactly the same issue: Even with protostar, the front-end profile.edit doesn't submit a value for the read-only fields (when set to 'show when read only').
The user controller doesn't have a reference to the read-only field in the $data var, but then it fires the 'onContentNormaliseRequestData' and plg_system_fields catches it and injects a bool(false) value for that field

Code: Select all

/**
	 * Normalizes the request data.
	 *
	 * @param   string  $context  The context
	 * @param   object  $data     The object
	 * @param   Form    $form     The form
	 *
	 * @return  void
	 *
	 * @since   3.8.7
	 */
	public function onContentNormaliseRequestData($context, $data, Form $form)
	{
		if (!FieldsHelper::extract($context, $data))
		{
			return true;
		}

		// Loop over all fields
		foreach ($form->getGroup('com_fields') as $field)
		{
			// Make sure the data object has an entry
			if (isset($data->com_fields[$field->fieldname]))
			{
				continue;
			}

			// Set a default value for the field
			$data->com_fields[$field->fieldname] = false;
		}
	}

Then, the form validation is started from the controller and we end up in Form::validateField rejecting that value due to the following codebit:

Code: Select all

// If the field is disabled but it is passed in the request this is invalid as disabled fields are not added to the request
			if ($disabled && $fieldExistsInRequestData){
return new \RuntimeException(\JText::sprintf('JLIB_FORM_VALIDATE_FIELD_INVALID', $element['name']));
}

Some notes/thoughts:

• Replacing that (bool)false with null fixes everything, but I assume there's a reason why false is being assigned. Didn't dig long enough but I did read in a similar git issue that the security team had a say in this.
• Interestingly enough, this only happens when the read-only field is set to 'show when read-only'. If you change that config to 'do not show', the problem goes away. I didn't trace that stack, but I assume plg_system_fields doesn't inject the (bool)false value in this case.
• It's implied, in the linked issue, that this was fixed. I'm not sure if this is a regression or if the fix only applied in articles. If it's the latter, we need a generic solution as contacts (or any other vanilla or 3rd party components using com_fields) should, in theory, have the same issue as well.