Fix(Core): Take care of item recursivity to load Dropdown values #17086
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the release of version 10.0.15 with the following security fix :
d02c537
A user in a
sub-entity
who views anasset
in theroot entity
(recurisf
) can no longer load dropdowns.When creating the dropdown, the entity_restrict option does not take into account the notion of recursiveness
an empty array is sent
I should see the values visible in the asset entity AND in my current entity (sub-entity)
I think the problem comes from the
Session::getMatchingActiveEntities
function, which filters theactive entities
($_SESSION
) with the desired entity (1 in_array [] => false
) (without taking into account the recusivity of the asset).By adding
entity_sons
option, GLPI also retrieves the asset's sub-entities, which are then filtered to match the current user's active entities (1 in_array [1] => yes
)This PR deserves special attention because of the complexity of the filtering by entity, because I am not aware of the scope of this change and the criticality involved.
in other words, I don't really know what I'm doing.