IBX-8426: Fixed duplicate relations

[reithor]

🎫 Issue	IBX-8426

Description:

PR adds a "permission switch" to internalLoadRelations().

maintainer update: changed to use sudo as all of them are needed for the update process, see review notes.

Background:
When a user changes Content with related Content without having read permission to the related Content, existing relations are duplicated in ezcontentobject_link table.

https://github.com/ibexa/core/blob/4.6/src/lib/Repository/ContentService.php#L1432

$this->relationProcessor->processFieldRelations(
          $inputRelations,
          $spiContent->versionInfo->contentInfo->id,
          $spiContent->versionInfo->versionNo,
          $contentType,
          $existingRelations
      );

• processFieldRelations() adds all relations from $inputRelations that do not alreaday exist in $existingRelations.
• $existingRelations are load from internalLoadRelations() - skipping non-readable Content

 protected function internalLoadRelations(APIVersionInfo $versionInfo): array
 {
        ..
        /** @var $relations \Ibexa\Contracts\Core\Repository\Values\Content\Relation[] */
        $relations = [];
        foreach ($spiRelations as $spiRelation) {
            $destinationContentInfo = $this->internalLoadContentInfoById($spiRelation->destinationContentId);
            if (!$this->permissionResolver->canUser('content', 'read', $destinationContentInfo)) {
                continue;
            }
         }
        ..
}

[reithor]

@alongosz
I found 2 related issues:

1. APP_ENV=prod:
   Message for non-accessible relations when editing the Content Object is:
   The content item or its location is hidden. It will no longer be publicly available.
   should be
   You don't have permissions to view this Content item (contentID: ..).

2. APP_ENV=dev:
   RuntimeError is thrown when editing the Content

Twig\Error\RuntimeError:
Impossible to access an attribute ("mainLocationId") on a null variable.

  at vendor/ibexa/admin-ui/src/bundle/Resources/views/themes/admin/ui/field_type/edit/relation_base.html.twig:105

[alongosz]

I'm missing here integration test coverage (not a unit one) reproducing the use case from the JIRA ticket on API.

That would help me determining if the fix is done in a proper way and will make it future-proof when other changes gets applied.

[reithor]

I'm missing here integration test coverage (not a unit one) reproducing the use case from the JIRA ticket on API.

thanks @alongosz - will try to get this done - and ping you when I have questions.

[reithor]

I'm missing here integration test coverage

@alongosz : integration test has been added

[alongosz]

Thanks for the test case, after debugging it I see what's the root cause here. Seems we either:

• have a missing feature when loading a $content item by internalLoadContentById - RelationList field should never load on API level an item which user has no permissions to access - might be difficult to implement on the relevant layer level though,
• are updating relations based on too heavy objects - this can negatively impact performance - if we don't touch relation field in an update, it should not be updated at all

both of these things however are too complex to mitigate them via this issue. I have another suggestion as a quick fix for our faulty architecture.

// Side note: please rebase, there are some PHPStan issues that were solved on 4.6 yesterday.

[alongosz]

Review note: it's done like that because there are some architecture issues that are not easy to fix, see #390 (review)

[sonarcloud]

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 SonarCloud