Add constraint for User Role Condition roles so it can be FullyValidatable

Added ConfigExists constraint to user_role condition schema

meghasharma → closed merge request !12279

I’ve assigned this issue to myself. I initially made the changes in the XB core's user.schema.yml, but later realized that the changes should go into Drupal core. I’d appreciate some guidance on how to proceed and push the changes to the correct branch.

I pushed the changes to the Drupal core branch and updated the issue status to 'Needs review'.

Has test failures.

To comply with the new ConfigExists constraint added in the user.schema.yml schema for the roles field of the user_role condition, it was necessary to ensure that the roles referenced in the tests actually exist as valid configuration. In the createEntity() method of the base test class BlockResourceTestBase, I added the conditional creation of the test role. This guarantees that the role exists in the configuration during test execution, satisfying the ConfigExists constraint.

Thanks @jonathandealmeida!

I think this means we would need to completely change how the test would work. Based on the machine name, the whole point is that the role does not exist. However, if we're conditionally creating it, that's no longer the casein the situation under test. In other words, fixing it in this way would basically remove the existing test coverage for non-existent roles.

This test coverage was added originally in #2737719-71: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method → . Quoting that comment:

Apparently another fail sneaked in there. In all Block config entities. The root cause is that same problem that was discovered before (see #41):

    // All blocks can be viewed by the anonymous user by default. An interesting
    // side effect of this is that any anonymous user is also able to read the
    // corresponding block config entity via REST, even if an authentication
    // provider is configured for the block config entity REST resource! In
    // other words: Block entities do not distinguish between 'view' as in
    // "render on a page" and 'view' as in "read the configuration".

But #65 introduced additional assertions to ensure a 403 is returned before the necessary authorization is set up. The work-around I had in place didn't account for that. So, now I have changed the work-around to disallow access by any user until the necessary permission is granted. We still need to fix the root cause though.

Created an issue for that now: #2820315: Blocks' 'view' operation is interpreted as "render on page" instead of "read this config entity" → .

Adding those two issues to the related issues.

Based on the above, I don't think we can go ahead with the workaround of conditionally creating the role. Or, if we did, we would need to test the 4-3s for non-existent roles in some other way.

This is also definitely not novice anymore, so untagging.