Неоднократно задавал тут вопрос: возможно ли применить функционал расширенного фильтра к объекту "справочник".
Официальный ответ саппорта - нет не возможно, но пожелание адресовали разработчикам для возможности реализации этого в будущих релизах.
на самом деле мне удалось этого добиться, правда не совсем стандартным способом...
- Создал раздел внутренними механизмами BPM
- Дропнул тейбл раздела в БД
- Создал представление (с inner join из 2 таблиц) с таким же названием в БД из п.2.
- Внес изменения в объект в БПМ - создал columns точь-в-точь как в представлении + установил признак "представление БД" (!)
- Закастомил страницу реестра.
Правда теперь не понимаю может ли эти изменения как-то негативно повлиять на работу приложения в целом?
Нравится
Использовать схемы на основе view вполне допустимо, парой сообщений ниже Алла Савельева как раз предлагает такое для решения вопроса с графиком.
Только обычно создают в обратном порядке: сначала — схему с установленной галкой, потом — view в базе с такими же полями. Таблицы при этом не создаётся.
Обычно в названии объекта для ясности вначале пишут Vw, можете посмотреть такие в стандартной системе.
По поводу негативного влияния, всё зависит от кода view. Если он содержит ошибки или при наложении каких-то фильтров получится очень тяжёлый запрос на выборку, то база может «задуматься».
Зверев Александр,
ключевое слово - расширенный фильтр.
К справочнику его не применить.
Соответственно создал раздел, (руками его создавать - неблагодарное дело). А уже потом ахалай-махалай с Vw...
Случайно обнаружил: подобное действие с разделом привело к ошибке (см. принт-скрин).
УРЛ https://[url_app]/0/ServiceModel/EntityDataService.svc/ для меня крайне важен...
Значит, у нового раздела на основе view получилось совпадающее с существующим значение названия или чего-подобного. В результате при попытке системы построить список объектов, доступных по OData натыкается на пару дублей и не может однозначно выбрать.