IBX-7717: UDW location endpoint additional permission info

[tischsoic]

🎫 Issue	IBX-7717

Related PRs:

• https://github.com/ibexa/content-tree/pull/71
• https://github.com/ibexa/tree-builder/pull/140
• IBX-7717: Introduced strict getters for LookupLimitationResult and VersionInfo Value Object core#349

Description:

Frontend note: there's backported loader mixin from 4.6, used in TB to show loader when request is loading.

Example

Request:
path: api/ibexa/v2/location/tree/{locationId}/extended-info

const request = new Request(path, {
        method: 'GET',
        mode: 'same-origin',
        credentials: 'same-origin',
        headers: {
            Accept: 'application/vnd.ibexa.api.ContentTreeExtendedNodeInfo+json',
            'X-Siteaccess': siteaccess,
            'X-CSRF-Token': token,
        },
    });

JSON Response:

{
    "ContentTreeNodeExtendedInfo": {
        "_media-type": "application\/vnd.ibexa.api.ContentTreeNodeExtendedInfo+json",
        "permissions": [
            {
                "_name": "create",
                "hasAccess": true,
                "restrictedContentTypeIdsList": {
                    "restrictedContentTypeIds": [
                        "1",
                        "16"
                    ]
                },
                "restrictedLanguageCodesList": {
                    "restrictedLanguageCodes": [
                        "eng-GB",
                        "eng-US"
                    ]
                }
            },
            {
                "_name": "edit",
                "hasAccess": true,
                "restrictedLanguageCodesList": {
                    "restrictedLanguageCodes": [
                        "eng-GB"
                    ]
                }
            },
            {
                "_name": "delete",
                "hasAccess": false
            },
            {
                "_name": "hide",
                "hasAccess": false
            }
        ]
    }
}

XML Response:

<?xml version="1.0" encoding="UTF-8"?>
<ContentTreeNodeExtendedInfo media-type="application/vnd.ibexa.api.ContentTreeNodeExtendedInfo+xml">
    <function name="create">
        <hasAccess>true</hasAccess>
        <restrictedContentTypeIdsList>
            <value>1</value>
            <value>16</value>
        </restrictedContentTypeIdsList>
        <restrictedLanguageCodesList>
            <value>eng-GB</value>
            <value>eng-US</value>
        </restrictedLanguageCodesList>
    </function>
    <function name="edit">
        <hasAccess>true</hasAccess>
        <restrictedLanguageCodesList>
            <value>eng-GB</value>
        </restrictedLanguageCodesList>
    </function>
    <function name="delete">
        <hasAccess>false</hasAccess>
    </function>
    <function name="hide">
        <hasAccess>false</hasAccess>
    </function>
</ContentTreeNodeExtendedInfo>

Documentation:

This is an internal endpoint, no doc required.

Checklist:

• Provided PR description.
• Tested the solution manually.
• Provided automated test coverage.
• Checked that target branch is set correctly (master for features, the oldest supported for bugs).
• Asked for a review (ping @ibexa/engineering).

[alongosz]

1. final & internal
2. Naming: ATM the name suggests we're dealing with a value. How about LoadExtendedNodeInfoStructParser (see the next comment for reasons behind "Struct").

[tischsoic]

1. 👍
2. There is already Ibexa\AdminUi\REST\Input\Parser\ContentTree\LoadSubtreeRequest and I decided to follow with this convention.

[konradoboza]

Point 1 is still not resolved. REST parsers are final across the entire system which is also the case for most of the classes in general.

[alongosz]

What is the reason for changing existing contract parameter name?

[tischsoic]

Because it didn't match the parameter name from one of the interface's implementations and it did not make much sense to me. As you can see in the original PR, both names did not match each other back then:

• interface: https://github.com/ezsystems/ezplatform-admin-ui/pull/1273/files#diff-14fc449f7ecdcea5e8c83c4f5be3656dfceee1ed2df4eb40cea59c2e9ae36d16R37
• implementation: https://github.com/ezsystems/ezplatform-admin-ui/pull/1273/files#diff-c3310f3f33562f15c00a3cfdee25ffbd7f0e88db43c1dea1fe87001dd0ecb785R211

It was also later set to parentLocation in 4.6 here: https://github.com/ibexa/admin-ui/pull/872/files#diff-d1039d1a73d7e40070b874e926dbb079bee41c510c4b14ef555ba1d8f7a66f20R32

But I think this should have been called location as done in the initial method implementation: https://github.com/ezsystems/ezplatform-admin-ui/pull/1273/files#diff-c3310f3f33562f15c00a3cfdee25ffbd7f0e88db43c1dea1fe87001dd0ecb785R211.

[alongosz]

Please be aware that if someone used named parameters, it would be a BC break. However AFAIK we haven't specified our position on BC for that, so for now I'll accept 👍

[tischsoic]

I know, I think last time we tentatively agreed that we are not going to have BC on parameters naming.

[konradoboza]

Point 1 is still not resolved. REST parsers are final across the entire system which is also the case for most of the classes in general.

[tomaszszopinski]

QA approved on IbexaDXP 4.5 commerce.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[tischsoic]

Merged up:

• 4.6: 0cd1d38
• main: 10281de