Тоже проперлись от ass search in qv?)

да ну я уже давно на этом)

Дело в том, что можно предлагать различные варианты отборов, при которых варианты QlikView и Qlik Sense будут давать различный уровень эффективности.
Т.к. в вашем примере, если мне нужно выбрать всех Actor, соответствующих Директору = Adrian, то очевидно, что мне может быть удобнее выполнить предложенный вариант поиска.
А что, если меня интересует лишь часть Actor-ов, у которых Директором является Adrian? Очевидно, что мы сначала найдем/выберем нужного директора, а затем, увидев ассоциативно связанных с ним Actor, выберем требуемых их них

ну это просто разные сценарии, безусловно

Вот я про то же.

и хорошо, когда есть возможность использовать любой метод для разных целей.
Первый сейчас, sense просто не даёт сделать так же просто, как и view

А хочется, чтобы такая возможность была)
И всего лишь)

Но что-то как-то странно все же, все.

Зачем убирать сейлз
поинт?)

Нынче другие сейлз понты - графички от артифишел интеллект

ай агрии

Если есть возможность выбора - безусловно хорошо. Но выбор сразу всех значений сопоставленных с найденным - это лишь один вариант из возможных. И если для всех остальных вариантов всё равно приходится работать с индивидуальными листбоксами, то вопрос - зачем ради одного варианта усложнять объект. Я не защищаю свою точку зрения, я лишь просто задаю вопрос о целесообразности поддерживать код ради единственного сценария?

я не представитель кликтек, чтобы знать насколько целесообразно или нет :)
Я могу рассуждать лишь как пользователь.
И для меня это не очевидно.
Зачем казалось бы столь важные вещи отодвигать в сторону.

но все остальные варианты по-сути это последовательное натыкивание фильтров.
То есть ровно тоже самое, что и в других продуктах)
Кажется, что искать значения одного поля, непосредственно в нем, на основе значений других полей - это очень круто

реализовали же поиск по формулам  - работает и радует всех :)

Всё течет и меняется ))
Возможность выбора в конкретном поле и любые ассоциативные манипуляции  с отборами - способ работающий в 100% случаев.
Вариант обсуждающийся нами в QlikView - это лишь один частный случай, достигаемый только при условии, что на экране есть листбокс (а его ещё должен кто-то нарисовать и съесть тем самым место на листе., А что делать, если нужное поле не выведено в виде листбокса на лист? А что, если такой поиск хочется делать по всей модели? Все поля в виде листбоксов на лист вываливать?
Вариант же предложенный в Qlik Sense позволяет и поля не рисовать и делать отборы любой гибкости и видеть все взаимосвязи. И при этом не гонять

все данные на сторону пользователя просто для тупого отображения листбоксов

нет :)
Давать профессиональную лицензию - пусть сами вываливают что хотят :))

но это уже всё следствия.
Например, иметь такую возможность поиска в тех же "выборках", было бы тоже удобно

в общем, печально просто что с view не перетянули все хорошие функции, которые уже ни раз обсуждались)
Понятно, что всё можно сделать так или иначе, но когда это можно сделать проще - всегда радостно)