собственно я и раньше поднимал эту проблему http://catalog.mista.ru/public/87912/

сейчас занимаюсь внедрением тяжелой конфы (1с:УправлениеХолдингом) и опять те-же грабли, собственно пока основная претензия, то, что расчет например организаций к которым нужно давать доступ ведется непосредственно в Рельсе а не при записи набора прав, пример:

есть дерево организаций (там в одном дереве ЦФО и организации) и пользователь получает права и через реквизит к головному узлу и ко всем его подчиненным, что происходит при каждом запросе...

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

Ну или есть моменты когда нужно давать доступ на запись по совокупности, например доступ в документ если разрешены и ЦФО и проект, а если что-то одно - то только на чтение...

Допиливать типовые права БСП - это реально непосильно в плане поддержки, по этому и дилема

1. Пытаться поломать бизнес хотелки и юзать только типовые
2. Писать рядом свою подсистему

Написать заявление об уходе в дворники.

(1) почему? в чем проблема?

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

(3)
Лучше пять дней потерять - потом за пять минут долететь(С)Крылья.Ноги.Хвосты.

Я всегда считал и до сих пор придерживаюсь.
Лучше все нахрен сломать и сделать свое чем под типовые подстраиваться...
Особенно учитывая какие грибы они едяи при написании кода%:-))

Если в типовых нет, то свои

(3) а зачем для этого БСП пилить ?

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

(2) В тебе. Вопросы по УХа = идти в дворники. Согласен с ПиНом, что не взяли, знаний пипец.

(7) да, но эти самые значения не все лежат в регистре...

по поводу "причесали" - согласен, стало лучше, но опять же
1. есть моменты которых банально нет (например с рельсой к проектам)
2. даже на хорошем железе дерево 200 организаций с типовой рельсой открывается 5 секунд.... а ведь 200 - это мало учитывая, что в дереве должна быть смесь юр лиц и отделов/цфо, планируется структура до 500 единиц.... я понимаю, что любая рельса с деревом в динамическом списке не дружит, но не до такой-же степени....

(8) то есть любой программист/не дворник знает все ответы на любые вопросы по УХа ???

странное у тебя представления и по программистам и по УХе и по дворникам :)

или конкретно мои вопросы тупые? в чем же дело?

(9) недавно прикручивал рлс к проектам в ерп, нечего там пилить.

(11) новую роль делал ?

(12) Да, ессно , тупо передрал все со складов по-моему,
поставил шаблон и добавил в определяемые типы.

(12) Новый вид доступа не сложно сделать и легко поддерживается

+(14) более того, как это сделать подробно написано в документации

(10) Да. Либо идет в дворники, если не знает

(16) я тебя огорчу, даже разработчики УХ не знают все ответы :)

(17) Пфф, не к тому обращаешься. Митрохин например знает. Только деревня кому ынужна

Дима, добро пожаловать в наш мир типовых! С почином тебя! Про твою задачу, рлс, не могу ничего сказать. Но кажется, что эта задача не стоит таких вот потугов.

Зато могу немножко рассказать, как сейчас обстоят дела такими вещами как различные проверки, расчеты и т.д. Разрабы типовых БП, УТ, ERP, KA пошли по такому пути - есть некие универсальные функции, в них теперь передается МВТ и какой-то набор параметров. На выходе из этих функций-процедур будет запрос на МВТ которого должна быть ВТ с какими-то данными. Это так должно быть в идеале. И когда все работает, ты не думаешь как-оно там. Мир начинается рушатся, когда на МВТ внезапно твоя нужная ВТ либо пустая, либо ее вообще нет. И вот ты пошел внутрь всего этого механизма. Первое что бросается в глаза, это имена ВТ и параметров. Они всегда преобразовываются к уникальным, путем конкатенации с уникальным идентификатором. Далее, чтоб сам механизм понял, какие ВТ как называются в последующих запросах, в параметры исходной функции передается структура параметры, в ключ кладется имяВТ, в значение - как оно на самом деле называется. Дальше определяются, есть ли отборы, нужно ли их ставить, использовать секцию разрешенные и т.д., и по ходу пьесы через конкатенацию строк формируется текст запроса. Если вдруг так оказывается, что там где-то есть джойн, то опять же допиливается секция индексирования по полям склейки. И вот, когда запрос полностью сформируется, ты вылетаешь куда-то в середину (уровень вложенности может быть и 20 и 30), и там так тоненько Запрос.Выполнить();. После этого у тебя может появиться одна ВТ, а может и больше. Но суть в другом: это какие-то промежуточные ВТ, они на финальном этапе уничтожаться. У тебя пока что есть параметры, в которых лежат соответствия имен ВТ и их реальных имен, и МВТ на котором есть некоторые ВТ. Дальше это все передается в следующую процедуру-функцию, там идет формирование следующих ВТ и текста запроса...Ну вообщем-то я думаю ты понял. К выходу самой первой процедуры этот круг Сансары может повториться 50 раз. При этом, естественно все эти 50 Запрос.Выполнить(); будут предыдущие тексты запросов изничтожать. В предпоследнем запросе, как правило ненужные ВТ уничтожаются все сразу. И вот на выходе к тебе придет ВТ или несколько, к которой ты уже сам должен написать ну какой-то там запрос. И вот вопрос к тебе как к специалисту, а как это все отладить? Даже не так - как вообще собрать итоговый текст запроса? Сколько на это нужно времени?

А рлс какие-то, это фигня, Дима.

(13) в каждый документ добавил реквизит проект?

Никаким РЛС не сделать - как например в ДО - когда для каждого документа можно задать свою рабочую группу. (по умолчанию допустим имеет доступ подразделение и проект, нужно добавить некоторых пользоваталей другого подразделения). Но это лепить свой регистр ОбъектыДоступа, очереди пересчета прав и т.д. Или как образец взять ActiveDirectory.
УХ - отличная конфа, выкинули б из нее консолидацию, оставив бюджетирование и некоторые другие фишки, и продавали б как альтернативу КА тем кому не нужно производство...

(20) ээ, зачем ?

(22) в 11 -- прикрутил проекты к erp и rls

(23) читаем вдумчиво , рлс к справочнику проектов в конфигурации erp , а не городил сквозной учет по проектам
Конечная задача была другая, со своим набором документов.

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

Да и вообще типовых я не боюсь, главное, что бы их никто не допиливал кривыми руками... Вот сейчас у меня типовых 35 баз: БП 2 и 3, ЗУП 2.5 и 4, сельхоз рарусовская 3.... и вообще нет проблем, по тому как типовой подходит... Так, что я никогда от типовых и не уходил...

(25) >>cогласен что она замороченная, но она вообще-то понятная и довольно простая в понимании.

В конце моего опуса, я задал вопрос: "как вообще собрать итоговый текст запроса? Сколько на это нужно времени? " Ты пробовал сам собирать такой запрос? Ты наверное, не понял. То что описал ты - это стандартная схема старая, когда запрос собирается в одну простынь. Да это долго, но на выходе ты его можешь лицезреть целиком. Я же описываю современный подход, когда никакой единой простыни нет в природе. Чтобы его (запрос) физически собрать в один текст, может уйти рабочий день, если ты только этим и будешь заниматься. Это без учета установки всех параметров. Потому что, что тебе даст текст без параметров? Ничего. А параметры можно посмотреть только в отладчике. Таким образом, единственным способом, является сбор такого пакетника по каждому пакету, с проверкой каждого параметра на значение из конфигуратора, с обязательной проверкой количества временных таблиц на каждом этапе, т.к. ты можешь запросто и вместо захода в процедуру, просто ее пройти, а там может еще в пяток ВТ уже понасоздавалось. Если ты за один проход не соберешь весь текст, то следующий запуск, как ты понял, будет уже с другими именами и параметрами, они же каждый раз новые. И исходя из этого, я не понял твоего коммента про "она вообще-то понятная и довольно простая в понимании". Такая схема, она не только не понятна и ни фига не простая в понимании, ее физически как есть, отладить итсовской консолью нельзя, т.к. нужно имена вт и параметров привести к меньшей длине. Ну при условии, что ты полностью прошел квест по сбору самого текста запроса. И вот ты пишешь "Я последнюю самописку делал примерно с таким-же подходом" - если это так, то мне не понятно, зачем? Вот реально зачем в самописной конфе, или даже в своем алгоритме, делать такое? Это бессмысленно Дима, и я объясню почему. В типовых это сделано сейчас из-за того, что сами такие алгоритмы - универсальны по отношению к ТИПОВЫМ, т.е. алгоритм - един для основного косяка типовых конфигураций. И вполне обыденно сейчас, когда ты собираешь текст запроса, прошел 19 функций вниз, а там в процедуре один коммент:

//в этой конфигурации ничего не делаем.

Либо идет проверка какого-то свойства, которое где-то в другой конфе заполняется. И если свойства нет, или же оно не заполнено, то ВОЗВРАТ.

Вот зачем так делается. А повторять это в своей конфе, если ты ее и сам поддерживаешь - это маразм в степени маразм.

И еще интересно вот что. Собирая пакетники, которые состоят из 50 и выше запросов, уже просто так взять и понять, что делает каждый запрос - нельзя. Конечно, есть запросы понятные, но есть - совершенно невозможно понять, почему так. Т.е. там заложены некие алгоритмы, объяснению которых найти в самих запросах - нельзя. Иногда, они описываются в комментариях к коду, который эти запросы формирует. Т.е. приходится, на всяких случай, еще и комментарии тоже забирать, т.к. фиг его знает - понятно там в итоговом тексте, зачем нужна ВТКоэффициентыВыплаты и Запрос пакета 51.

Ну кароч, Дима. Кажется твой тезис про простоту и понимание - не о том :) Или же ты достиг Дзен.