Profile tab access does not respect the "roles" setting

Here's a simple patch that filters out profile type tabs if the user doesn't have the right roles.

Sorry, the above patch doesn't work properly with caching. The tab set gets cached and not updated for each user.

The work has to be done in the access handler. The check is here: \Drupal\profile\ProfileAccessControlHandler::checkCreateAccess

      $bundle = ProfileType::load($entity_bundle);
      if (!empty(array_filter($bundle->getRoles()))) {
        $result = AccessResult::allowedIf(!empty(array_intersect($account->getRoles(), $bundle->getRoles())));
      }

Thanks, mglaman. I updated the access function, using code from \Drupal\profile\ProfileAccessControlHandler::checkCreateAccess. I also added a check to make sure that at least one role had been selected for the profile before testing the role intersection.

What's the status of this patch? As administrator, I only want to see profile tabs for roles belonging to the current user.

This patch works nicely for me :). We should fix the failing tests...

Oh wait, the tests are fine for 8.7 & PHP7.2. Go! :)

We definitely need tests for this.

+++ b/src/Access/ProfileAccessCheck.php
@@ -50,6 +50,10 @@ class ProfileAccessCheck implements AccessInterface {
+    if (!empty(array_diff($profile_type->getRoles(), ["0"])) && empty(array_intersect($user->getRoles(), $profile_type->getRoles()))) {

I don't understand this line and the magic ["0"]

array_diff($profile_type->getRoles(), ["0"]))

Is this just to check if it's restricted?

Let's update the title and summary as well. #7 sums it up nicely:

As administrator, I only want to see profile tabs for roles belonging to the current user.

Marked #3052434: Profile does not respect the specified roles as expected as a duplicate.

I just posted a patch for review in https://www.drupal.org/project/profile/issues/3064457#comment-1317309 that should also address this issue.

The permissions are checked first, and if the access is allowed using the permissions, then the role setting isn't checked.
Using the patch, the access can be granted using either the permissions or the roles setting.

Actually, I wonder if we should simply update ProfileAccessControlHandler and override checkAccess() there to also check the role setting, even if the permissions allow the operation (just like checkCreateAccess()) although the role setting wasn't probably designed for that.

jsacksick and myself spent a long time reviewing this bug. Turns out that the access logic has been broken since beta1.

There are two problems:
1) We check roles for "create" access, but not "update" / "delete" access.
2) When checking "update" / "delete" access, we need to check against the entity owner, not $account, so that admins can't see the tab on the user pages either.

Before beta1 we had checkAccess() and it used the entity owner to perform the check. It's obvious that we're missing test coverage (despite having two kernel access tests), which caused this regression to happen.

I got rid of ProfileAccessTest and moved all the access tests into ProfileRoleAccessTest.

I'm not 100% satisfied with the signature of testProfileRoutesAccessCheck() wanted to pass an array of roles instead of booleans for the 2 last parameters but dataProviders are actually called before setUp().

Coding standard fixes... I don't really understand the tests failure (the failing test passes for me locally).

Sorry for the noise!

Coding standard fixes.

Expanded testProfileCreate() a bit.

Thank you jsacksick, just in time for one last release candidate.

Cleaned up testProfileCreate() pre-commit to be a bit clearer.