Relationship Distribution gives inconsistent results when changing the limit parameter

[labo-flg]

Description

On this example dashboard:
https://testing.octi.staging.filigran.io/dashboard/workspaces/dashboards/d4374a78-de09-4a00-a5c3-37b673bcea8b

The 2 widgets are the same (second one duplicated from the first), I only changed the "limit" parameter of the second one (from 10 to 20).

One widget gives 0 results, the other gives 2 results.

This bug will not happen if the user has BYPASS capabilty, so test with a user with only access to knowledge + dashboards.

I also tested with a user with ALL capabilities but not BYPASS, the bug happens. So probably a part of the code excluded when user has BYPASS.

Environment

Testing environment 6.0

See user/role/dashboard with mention "6319"

Screenshots (optional)

[labo-flg]

Results of our initial debug session with @marieflorescontact :

• distributionRelations calls elAggregationRelationsCount which gives the 100 first results of this aggregation
• then convertAggregateDistributions take the N first items (N being the limit variable, so 10 or 20 here)
• then convertAggregateDistributions calls elFindByIds to resolve these N first objects and to return them

Problem: elFindByIds naturally checks the data restriction thanks to buildDataRestrictions. With BYPASS there is no restrictions, but once you have a regular user this will have an impact : in the end only few ids are actually resolved. Upon the 10 first you might have luck and get a few... Greater the value N, bigger the chance. Ultimately we cannot know for sure the results.

Could we include the data restrictions into the aggregation query directly ?
cc @SamuelHassine WDYT ?

[labo-flg]

Update:
elQueryBodyBuilder includes data restrictions, and it's injected in the "query" part of the aggregation query... so it should work properly I guess. But I keep getting objects I am not able to later resolve with elFindByIds.

EDIT: the injection concerns the relationships itself, not the objects from/to this relationship so it's normal.
We cannot inject data restriction filter on these objects on this aggregation over relationship indices.

[labo-flg]

Shall we increase the MAX_AGGREGATION_SIZE to give us more room? I'm unsure of the perf cost here (cc @richard-julien).

[labo-flg]

After some discussions, we agreed on the following solution:

• the relationship distribution shall be the same in both cases, it represents a state of the database and not a state of a subset of the data depending on user's rights. Dashboards are meant to be shared, so they shall not be inconsistent
• the items that are not accessible shall be presented as "restricted"

On the technical side it means changing the API of relationshipDistribution to return not an entity but just enough for the display, an unified API with the id, entity_type and representative.

Frontend side, this will simplify greatly the fragment (no more ... on XXX for every possible entity in the model) and removes the need for using the magic function defaultValue(node)

[labo-flg]

Here is how it looks with #6323