i-neti: Фреймворк Extensible Data Security (XDS) в Dynamics 365 Finance for Operations

[trud]

Добавлять поля в заказ и накладывать фильтры/строить индексы по этим полям. Собственно как работает поле компания

[fed]

Цитата:

Сообщение от trud

Добавлять поля в заказ и накладывать фильтры/строить индексы по этим полям. Собственно как работает поле компания

Ну дык те же самые фильтры удобнее добавлять с помощью XDS. Вообще этот механизм ни плох и ни хорош сам по себе. Он просто принудительно добавляет условие в запросы по некоторым таблицам. Если условие безумное, индексов нету или сами структуры данных безумны (как в случае новой ГК), то фильтры будут тормозить не зависимо от того, приделаны они с помощью XDS или в ручную, с помощью ковыряния в исходном коде формы.

[skuull]

Цитата:

Сообщение от trud

Добавлять поля в заказ и накладывать фильтры/строить индексы по этим полям. Собственно как работает поле компания

Так конкретный же кейс, фильтр по фин аналитике на строке заказа, какие фильтры и индексы будем добалять? Причем ребята с ролью "А" не видят подразделение "Б", а роль "Б" не видит "А" и не тоько на одной конкретной форме заказа, а вообще нигде, включая отчеты.

[trud]

Цитата:

Сообщение от Ivanhoe

А все кто против - реальные кейсы можете описать, когда начали использовать и отказались? Или теоретики?

Ну я встречал только негативные последствия(хотя тут наверное ошибка выжившего, когда все хорошо мне об этом не расскзаывали), кейсы - это фильтр на приджойненную таблицу

Цитата:

Сообщение от skuull

Так конкретный же кейс, фильтр по фин аналитике на строке заказа, какие фильтры и индексы будем добалять? Причем ребята с ролью "А" не видят подразделение "Б", а роль "Б" не видит "А" и не тоько на одной конкретной форме заказа, а вообще нигде, включая отчеты.

Как раз один из негативных случаев. Решать подобные вещи очень сложно - т.е. в итоге клиент перетасовал роли и подразделения таким образом чтобы можно было фильтровать по полю из шапки заказа(первоначально была строка), ну и добавили поле в шапку. Хотя в первый год все работало замечательно
А старый Record level security остался в D365?

[fed]

Цитата:

Сообщение от trud

Как раз один из негативных случаев. Решать подобные вещи очень сложно - т.е. в итоге клиент перетасовал роли и подразделения таким образом чтобы можно было фильтровать по полю из шапки заказа(первоначально была строка), ну и добавили поле в шапку. Хотя в первый год все работало замечательно
А старый Record level security остался в D365?

В такой ситуации, я бы аналитики продублировал в скрытые поля в таблице заказов или их строк, построил бы по ним индексы, обновлял бы их в update() или insert() на основании значений аналитик, ну и добавил бы эти поля в XDS.
P.S. Старого RLS не было уже в DAX2012 по моему. В целом - мне его нисколько не жалко. XDS в DAX2012 иногда подлгюкивал на моей памяти, но он все равно был намного более стабильным и работоспособным чем RLS.

[trud]

Цитата:

Сообщение от fed

В такой ситуации, я бы аналитики продублировал в скрытые поля в таблице заказов или их строк, построил бы по ним индексы, обновлял бы их в update() или insert() на основании значений аналитик, ну и добавил бы эти поля в XDS

Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было

[fed]

Цитата:

Сообщение от trud

Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было

Ну при таком раскладе, надо было бы заводить отдельную таблицу с со списком имеющихся подразделений по заказу и при любом обновлении строки заказа, эту табличку обновлять. Ну а потом где-то в XDS прописывать exists join между заказом и этой таблицей. (Хотя честно говоря, я уже не помню как это делать. Я этим XDS пользовался всего пару раз и году в 2014-2015).

[trud]

Цитата:

Сообщение от fed

Ну при таком раскладе, надо было бы заводить отдельную таблицу с со списком имеющихся подразделений по заказу и при любом обновлении строки заказа, эту табличку обновлять. Ну а потом где-то в XDS прописывать exists join между заказом и этой таблицей.

Так я о том и говорю, что exists join где условие накладывается на привязанную таблицу - это по сути полный скан таблицы заказов при открытии формы(т.е. ты находишь сначала по индексу записи в фильтрующей таблице, потом ищешь все заказы которые под это попадают(так так на формах обычно сортировка по коду заказа), сортируешь их, и выводишь первые 10. Это отлично работает на малых объемах, но начиная с сотни тысяч уже тормозит и никакими индексами это не победить

[skuull]

Цитата:

Сообщение от trud

Ну я встречал только негативные последствия(хотя тут наверное ошибка выжившего, когда все хорошо мне об этом не расскзаывали), кейсы - это фильтр на приджойненную таблицу


Как раз один из негативных случаев. Решать подобные вещи очень сложно - т.е. в итоге клиент перетасовал роли и подразделения таким образом чтобы можно было фильтровать по полю из шапки заказа(первоначально была строка), ну и добавили поле в шапку. Хотя в первый год все работало замечательно
А старый Record level security остался в D365?

А кто говорит что легко? XDS самый простой вариант, с токи зрения реализации даже в 2012, а с екстеншенами в 365 цены ему нет. Как уже говорили выше, тормозит будет все с разной степенью тормознутости и к сожалению клиента не всегда удаётся переубедить.

RLS был в 2012, просто был не рекомендуемый . В 365 вроде прибили.