JSON:API filtering or some permissions are not working as expected

As a test I gave a non-administrator role of that example user (UUID 5) all profiles permissions and removed one by one to find the permission which might be the cause for the unexpected behavior.

When I remove the permission "Administer profiles" the JSON:API result (filter by uid.id) went empty array. But this is of cause problematic, because that permission is correctly labeled as "danger only give trusted users". All other non-administrative permission where still enabled.

This leads me to believe that some permission checks are wrong wired here.

I added an image which shows the point were _somehow_ the applyAccessConditions() method of the TemporaryQueryGuard decides to add the unsolvable condition.

Okay, I keept digging and got to the point were the stange condition is added. The TemporaryQueryGuard has a static method called getAccessConditionForKnownSubsets(...) which tests 3 things (if all other access checks were neutral or granted or so). a "published" subset, a "enabled" subset and an "owner" subset. If all 3 of these fail, than it adds the unsovable condition.

Well, as far as I can tell, the "published" check returns neutral the "enabled" is false and the "owner" check returns neutral as well, which leads to the unsolvable condition of profile_id < 1 AND profile_id > 1.

I have - at this point - no idea how I can solve that, to make it usable.

I believe this can be solved by implementing this hook in your project:

use Drupal\Core\Access\AccessResult;
use Drupal\Core\Entity\EntityTypeInterface;
use Drupal\Core\Session\AccountInterface;

/**
 * Implements hook_jsonapi_ENTITY_TYPE_filter_access().
 */
function mymodule_jsonapi_profile_filter_access(EntityTypeInterface $entity_type, AccountInterface $account) {
  // Allow JSON:API filtering with profiles.
  return [
    JSONAPI_FILTER_AMONG_PUBLISHED => AccessResult::allowedIfHasPermission($account, 'access user profiles'),
  ];
}

Thank you. I'll try it.

Thanks @FMB it worked. I still have no idea, why we need this hook.

@FMB: Perhaps we need to add this to the Profile module directly?

Just so we understand what is happening here: by default, JSON:API relies on getAdminPermission() to grant JSONAPI_FILTER_AMONG_ALL. In our case, this permission is "administer profile types".

For a given use case where we only need to grant read-only access without granting too many privileges, both JSONAPI_FILTER_AMONG_ALL and "administer profile types" are too broad.

@jsacksick the question here, is whether the hook in #6 would be sensible default, or is tied to a specific use case. Whichever choice we make, we should document it in the README file. It looks like ro-no-lo and myself would consider this as sensible default and would be in favour of including in into the Profile module, but there might be other use cases I cannot think of right now, so one might argue documenting this would be enough. I tried to compare with what other modules that define content entities would do, but I found nothing.