okay, just did a deep dive :)

I think I know where the issue comes from:
FieldsHelper::getFields calls $fields = self::$fieldsCache->getItems();

which calls protected function getListQuery() from the model (./administrator/components/com_fields/models/fields.php).

In there is the following code:

                // Implement View Level Access
                if (!$app->isClient('administrator') || !$user->authorise('core.admin'))
                {
                        $groups = implode(',', $user->getAuthorisedViewLevels());
                        $query->where('a.access IN (' . $groups . ') AND (a.group_id = 0 OR g.access IN (' . $groups . '))');
                }

As you can see it sets the $query->where for the $user object which is not the user given in FieldsHelper::getFields (the user you want the fields for), but the currently logged in user (which is guest > therefore the fields with an access level other then public / guest are NOT shown...

I'm not sure if I do understand the problem correctly, but that access check is done for the current logged in user because we don't want to serve fields the person has no access for.
If you want that logic for the current user, then you probably have to do that by your own.

My use case:
I have a component that shows an author avatar on his articles
The author avatar is a field that the user can fill with his avatar, only author have the avatar field.

the article page is viewed by guest when browsing your website, so the call to fetch the avatar for the article author only works when the guest user has access rights to this field.

This is the case not only for my own fields plugin, but for ALL fields that have access rights set and are set to com_user.user and where the displaying user is guest. The way it is implemented now is that the field (in my case the avatar) will only display on the article if the author himself is logged in...

I think this is not correct! setting the field value should be checked against logged in user, getting the value (getField) should not (at least in this use case)

I think the logic should be the same as for the user object (that is where the com_user.user fields are coupled with)
When displaying an article, the authorname is read from the user object. It is displayed even tho the guest who is looking at the article does not have access to the user object. Only the author himself (or somebody with sufficient rights) can change the authorname (and other user values).

If the same logic that is now implemented for fields was applied to the user object, then no article would show the authorname. That would then only be shown to the author himself when logged in and looking at his article.

Sory for the 'storm' on folow ups :)

Yet another use case where this goes wrong...

for articles I create a new field: imagefield (type media) > access public.
I want to have author's fill this field with an image that can be displayed in the text of their article.

the field is inserted in the article with the (field x} tag

the author adds the image in the field et voilà, the {field x} is correctly replaced with the image.

so far so good :)

but now I want to limit that functionality (field) to editors only so I set the access to the imagefield to editor.
when the author opens his article, he cannot set this field as it is not available for him, the editor can change the article and add the imagefield...

so far so good.

But when looking at the article from a guest (front-end) perspective, the image is not shown....
Setting the imagefield access to public > the image is shown again...

So this is not only com_users.user related but impact the usability of all fields :S

You should not use the access property but the edit.value permission. So only users which do have that permission can change the avatar.

I think you have a fundamental confusion about viewlevels and actions.

• The viewlevel defines who can see the content of the field. From what I understood you want it (the picture) to be visible to anyone. So you set the access level to "Public".
• The actions are set in the "Permissions" tab, and define who can edit the field. As @laoneo said you need to adjust the "edit.value" action here so only the author or editor user group can edit the value of that field. All other users will still see the field in the form, but will be unable to edit anything in it.

I'm closing this issue as it is expected behavior.

okay, my bad... been at it to long :) thanks for thinking along!

Hi @Bakual and @laoneo , I have posted a follow up question here: https://groups.google.com/forum/#!topic/joomla-dev-general/n4nZXF-EztU

As you can see there is (I think) room for improvement :)

hi, I have thought about this a lot, but now I am running into a group of customers who do not understand why this is expected behavior :(
It is not logical and renders the Custom users fields useless in their use cases.... and I agree.
So here is me trying to get this improved with a new discussion: https://issues.joomla.org/tracker/joomla-cms/19468
as the discussion here never took off: https://groups.google.com/forum/#!topic/joomla-dev-general/n4nZXF-EztU