That be actually a very big (breaking) change. Are we sure we'd want to do this and are we clear on all that it means for all the different API calls? I'm not sure I'd want this merged actually and rather close it I would say.

@tsteur what about having an additional option for those filters to filter recursively? could maybe also be exposed as api parameter or something like that?

@sgiehl that could work. Although generally not seeing that feature request very often and then we need to add test cases and support it etc. Generally that would work though 👍

maybe @mattab can say something about the intention of that PR? Not sure what it would be needed for 🤔

The goal of the PR was to be able to filter columns in the output of the Live APIs, where currently showColumns/hideColumns aren't applied, and all data is always returned for all visitors. it was requested a few times over the years to be able to remove/show only some columns in these Live API outputs, as they are wordy/large by default.

If it's easy to do we can introduce one additional general API parameter to enable this behaviour but we would not want this by default.

Another idea: could we otherwise only offer this specific behavior (by default) to Live APIs only? because it's only useful for Live APIs afaik so not really needed to add this feature to our API as a whole maybe...

@mattab @tsteur I've updated the PR. Now there is an additional parameter hideColumnsRecursively, which can be set to 1 to enable the removal of nested columns. For Live API methods that parameter defaults to 1. All others will assume 0.

Note: for showColumns that might not work as expected.

@sgiehl can you add one system test for the Live API?

added a test