Update `hasCapability` selector to support meta capabilities

[aaemnnosttv]

Feature Description

With dashboard sharing, Site Kit's permission management on the client needs to be extended to support "meta capabilities", in this case – capabilities that are specific to a given module.

We already have a hasCapability( capability ) selector which works much like current_user_can() on the backend. This issue will extend the syntax of this selector to work closer to the way it works on the backend by adding support for specific meta capabilities, with the ability to support more in the future automatically.

The capabilities are already available to the client as of https://github.com/google/site-kit-wp/issues/4523, this is only about extending the selector.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The hasCapability selector on the core/user store should be updated to be variadic in its definition, such that all arguments after the first (capability) are packed into a single "args" argument (i.e. ...args)
  • If args has a non-zero length, the capability key used for the permission look-up should be used instead:
    • { capability }::{ json_args }
  • e.g. hasCapability( 'foo', 'bar' ) would look up the following capability foo::["bar"] (a string literal) from the object of all capabilities for the current user (returned by getCapabilities)
• All existing usage of hasCapability should continue to work as today
• Tests for hasCapability should be updated to cover this functionality

Implementation Brief

• In assets/js/googlesitekit/datastore/permissions.js, modify the logic of the hasCapability selector:
  • Add a third parameter ...args to the selector function in addition to the state and capability params.
  • If the length of args is not 0, convert it to a JSON string and append it to the capability being checked:

    capability = `${ capability }::${ JSON.stringify( args ) }`;

    Do this before checking if the capability exists in the capabilities array.

Test Coverage

• In assets/js/googlesitekit/datastore/permissions.test.js:
  • Add tests for the hasCapability selector.

QA Brief

QA:Eng

• Verify the changes met AC and IB
• Verify the new unit test cases for hasCapability selector are good enough and are passing
• As a extra mile testing, call the hasCapability selector and pass googlesitekit_manage_module_sharing_options as the capability and search-console as next ...args
• Open the dev tools console and execute window._googlesitekitUserData.permissions
• Verify the selector's return value with googlesitekit_manage_module_sharing_options::['search-console'] value from the console

Changelog entry

• Enable client to check meta-capabilities for Dashboard Sharing permissions.

[tofumatt]

It's not 100% clear from the ACs that we should be converting args into JSON.stringify( args ), but that's certainly what I'm reading into this as well.

IB ✅ from me. ~but I've pinged @aaemnnosttv just to clarify that's the intent.~ Actually, from json_args that must be the intent, okay! Moving to the backlog 🙂

[jimmymadon]

QA:Eng ✅

• Verify the changes meet AC and IB

✅ LGTM

• Verify the new unit test cases for hasCapability selector are good enough and are passing

✅ LGTM - base and meta capabilities covered.

• As a extra mile testing, call the hasCapability selector and pass googlesitekit_manage_module_sharing_options as the capability and search-console as next ...args
• Open the dev tools console and execute window._googlesitekitUserData.permissions
• Verify the selector's return value with googlesitekit_manage_module_sharing_options::['search-console'] value from the console

✅ LGTM