IBX-9266: Added REST endpoint loading available site accesses for location

[barw4]

🎫 Issue	IBX-9266

Related PRs:

ibexa/fieldtype-richtext#267

Description:

A new endpoint is exposed as /api/ibexa/v2/siteaccess/load-non-admin-for-location/{locationId} that utilizes the existing SiteaccessResolverInterface that fetches eligible site accesses for a given location.

Example response

{
  "SiteAccessesList": {
    "_media-type": "application/vnd.ibexa.api.SiteAccessesList+json",
    "values": [
      {
        "_media-type": "application/vnd.ibexa.api.SiteAccess+json",
        "name": "__default_site_access__",
        "provider": "Ibexa\\Core\\MVC\\Symfony\\SiteAccess\\Provider\\StaticSiteAccessProvider"
      },
      {
        "_media-type": "application/vnd.ibexa.api.SiteAccess+json",
        "name": "__second_site_access__",
        "provider": "Ibexa\\Core\\MVC\\Symfony\\SiteAccess\\Provider\\StaticSiteAccessProvider"
      },
      {
        "_media-type": "application/vnd.ibexa.api.SiteAccess+json",
        "name": "ger",
        "provider": "Ibexa\\Core\\MVC\\Symfony\\SiteAccess\\Provider\\StaticSiteAccessProvider"
      },
      {
        "_media-type": "application/vnd.ibexa.api.SiteAccess+json",
        "name": "eng",
        "provider": "Ibexa\\Core\\MVC\\Symfony\\SiteAccess\\Provider\\StaticSiteAccessProvider"
      },
      {
        "_media-type": "application/vnd.ibexa.api.SiteAccess+json",
        "name": "ku6\"H",
        "provider": "Ibexa\\Core\\MVC\\Symfony\\SiteAccess\\Provider\\StaticSiteAccessProvider"
      }
    ]
  }
}

For QA:

Documentation:

[alongosz]

Conceptually I think this is the proper placement for the endpoint.
Other remarks:

[alongosz]

My preference here would be SiteAccessList similarly as we refer to it on other places afair and the same as ContentInfoList, LocationList, etc.

[barw4]

The issue is that we also use SiteAccessesList in a lot of places in directly related services, e.g.: https://github.com/ibexa/admin-ui/blob/main/src/lib/Siteaccess/NonAdminSiteaccessResolver.php#L33 (a lot of other places in admin-ui), therefore I wanted to stay consistent with it as I'm directly using this service. But obviously I can change it if you prefer it your way.

[alongosz]

and the same remark for the object itself as in the previous comment.

[Steveb-p]

Not gonna lie, this URI terrifies me 😅

load-non-admin-for-location? Seems like extremely specific. It definitely violates the REST principle by putting some "action" (load) as part of the URI.

I'd suggest at the very least changing the part I mentioned.

If possible, I'd prefer this endpoint to be more generic. In my opinion ideal URI would look like this:

/site-access/by-location/{locationId}?resolver_type=non_admin

I would suggest to allow picking a specific type of resolver we're looking for by using a query parameter instead of creating separate links for each and every one (if/when they become needed).

[barw4]

Resolved in 28dee5e

[konradoboza]

Paweł remark seems valid.

[ciastektk]

Shouldn't this be done as a part of resolving strategy that will be easily extended?

[barw4]

is there really a point in creating a dedicated strategy if we handle just one resolver for now? We won't probably need another one is a long time - if ever.

[konradoboza]

switch statement doesn't look good. An alternative could be a map but whitelisting isn't nice either maintenance-wise. @Steveb-p what did you have in mind in regards to shape of resolver determination based on query parameter?

[Steveb-p]

tagged_locator would be my choice for resolution, with current non-admin service being tagged.

EDIT:
Index the locator using keys:

            $converters: !tagged_locator
                tag: 'ibexa.<tag>'
                index_by: type

And mark services accordingly:

        tags:
            - { name: 'ibexa.<tag>', type: 'non-admin' }

For non-existent types, throw an exception. You can use the ServiceLocator type (which is injected when tagged_locator is used) to give user the info what types are available (through a dedicated method to acquire locator keys).

[barw4]

please see 480f1d1

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud