Incorrect connection of the parent table with the map and another widget

[ElenaGallo]

Description

As reported in the User Guide here, if the widget has been created on the same dataset (layer) of the Parent Table then two filters will be applied in AND to the widget itself: the spatial filter of the Map widget and the attribute filter defined in the Parent Table.

At this moment this type of connection is not correct. The chart widget is connected to the map but not to the Parent Table.

How to reproduce

• Open this dashnoard
• Write "Florida" to STATE_NAME quick filter

Expected Result

interaction_ok.mp4

Current Result

interaction_no.mp4

• Not browser related

Browser info

(use this site: https://www.whatsmybrowser.org/ for non expert users)

Browser Affected	Version
Internet Explorer
Edge
Chrome
Firefox
Safari

Other useful information

[MV88]

there is problem with the introduction of traces and propagation of dependencies, I've spotted a problem here

in particular the fetch of table deps from a trace

https://github.com/geosolutions-it/MapStore2/blob/master/web/client/selectors/widgets.js#L113

i suppose it is enough to properly fix this selector, but i had no time to check it.
if it this the case it should be a quick fix otherwise it may take some more effort

[tdipisa]

This is a regression imho since it seems affecting also QA. @MV88 @ElenaGallo please confirm.

[MV88]

yeah, it has been introduced with multivariable charts work

[tdipisa]

@MV88

yeah, it has been introduced with multivariable charts work

it is not possible since that work is not present in QA but only in DEV, therefore I think the source of the problem is another. Anyway let's better check what introduce this regression @dsuren1.

[MV88]

ok, anyway there it fails because it does not find the editing layer in the charts, dues to the introduction of traces.

[dsuren1]

Investigation

The regression was introduced in 2021.02.00 by #7376 in buildDependencies function stop from building a correct dependency recursively.

Removing the condition of !ret.mapSync from buildDependencies allows us to propogate the dependency properly and fixes this issue. But it reintroduces the Maximum call stack size exceeded exception, so we need to find a better way to handle both the scenarios

Investigation was made against the current stable 2023.02.xx, same could be applied to DEV as well.

Although as @MV88 higlighted, there is some problem in the selector in DEV availableDependenciesForEditingWidgetSelector with respect to traces, which needs to be checked separately, for any other issues apart from the current one

[tdipisa]

@dsuren1 should we review pts assigned to this issue ?

[dsuren1]

Yes @tdipisa, maybe a point more should help us better identify the cause for intial change and find a common ground to fix both issues without breaking new changes. Furthermore the investigation took some time in tracing and finding the root cause.