v8: Моему гению 1С муза подсказала правильную систему правил для прав доступа #258108

В общем я долго думал, как должен быть организован регистр правил для контроля прав доступа, а сегодня меня осенило - он должен быть организован так же, как правила сортировки почты Outlook или mail.ru, то бишь идет набор некоторых правил, они последовательно применяются и выдается результат. Вкратце о тем - дело в том, что для одной ситуации может быть несколько вариантов правил, например если мы перепроводим приходную накладную, то подходят несколько правил и нужно расставить им приоритеты: "Админ может перепроводить любую приходную накладную" Можно было бы конечно идти путем максимального описания шаблона совпадения, но по-моему, если правила отсортированы по приоритету - то это более наглядный и удобный способ, да и правила получаются более компакными. Регистр правил представляет собой таблицу с полями (к примеру): Пользователь - какого пользователя касается. Роль - какой роли касается (или категории пользователя) - роль или группа ролей Объект - какого объекта метаданных касается (например - *, Справочники, Документы, Справочник.Номенклатура) ГруппаОбъектов - чтобы объединить несколько видов метаданных в одну логическую группу (на уровне программы) и задавать правило для нескольких видов, а не для одного вида. Подразделение - какого подразделения касается правило. Склад - какого склада касается правило. Товар - товар или группа товаров, которого касается правило. ГруппаДоступа - группа доступов, чтобы не назначать каждый доступ отдельно. Текущая Неделя Экземпляр - конкретный объект, которого касается правило. Контрагент - контрагент или группа контрагентов. Возможны поля для оперирования со временем документа: ДнейНазад - какое количество дней назад от текущей даты. Вчера - 1 день, 0 - не указано (обычно для даты документа). ДнейВперед - какое количество дней вперед от текущей даты. Завтра - 1 день, 0 - не указано (обычно для даты документа). По аналогии с ДнейНазад, ДнейВперед, можно использовать поля - СекундНазад, СекундВперед. Сегодня - если дата сегодняшняя (обычно для даты документа). Возможны указания интервалов времени действия правил: ВремяОт - время дня, от которого действует правило ВремяДо - время дня, от которого действует правило ДатаС - дата, с которой действует правило (для временных прав доступа) ДатаПо - дата, по которую действует правило (для временных прав доступа) Возможны поля для проверки авторства объектов: Автор - булево, истина, если автором объекта, к которому осуществляется доступ является текущий пользователь. КонтрагентПользователя - если данный контрагент обслуживается текущим пользователем. СотрудникПользователя - если сотрудник соответствует пользователю. Обязательные поля это: Доступ - вид доступа. Право - булево поле, определяет, разрешить или запретить доступ. Продолжить - продолжить выполнение других правил после применения текущего. Действует - действует ли правило (для временного отключения правил). Комментарий - комментарий. В начале предполагается что право есть. Из регистра правил выбираются подходящие контексту правила до тех пор, пока в текущем правиле "Продолжить" - истина. При выборе каждого правила значение права доступа назначается из поля Право правила. Права доступа можно загнать в регистр сведений ПравилаДоступа, в нем так же должен быть ресурс "Порядок", чтобы можно было отсортировать правила по порядку. В измерениях регистра лучше не использовать списки, т.к. тогда нельзя обрабатывать правила с помощью запроса. Например могут быть такие правила (отсортированные по приоритету): Действует = ложь Комментарий = я включаю это правило только если мне нужно произвести в базе массированные изменения Объект = РегистрСведений.ПравилаПравДоступа Комментарий = кто может назначать права доступа Объект = РегистрСведений.ПравилаПравДоступа Комментарий = кто может назначать права доступа Объект = РегистрСведений.ПравилаПравДоступа Комментарий = кто может назначать права доступа Роль = Старший пользователь ГруппаОбъектов = Документы учета товаров Право = ложь Комментарий = старший пользователь не может работать по акцизному складу Роль = Старший пользователь ГруппаОбъектов = Документы учета товаров Право = истина Комментарий = старший пользователь может перепроводить документы задним числом до 7 дней назад Роль = Пользователь ГруппаОбъектов = Документы учета товаров Доступ = Перепроведение Право = ложь Комментарий = пользователь не может перепроводить документы Пользователь = Директор Вася Право = ложь Экземпляр = Уставной капитал фирмы Комментарий = директор попросил уберечь его от пагубного желания править уставной капитал Пользователь = Директор Вася ГруппаОбъектов = Документы учета товаров Право = истина Комментарий = Главбух может смотреть зарплату сотрудников Отчет = Зарплата СотрудникПользователя=ложь Комментарий = сотрудник может смотреть зарплату только по себе. Доступ = * Право = ложь Комментарий = все, что не разрешено, запрещено. Вот теперь вы вкурили, какими должны быть нормальные права доступа и понимаете, что галочные права доступа 1С безнадежно отдыхают. Вкратце напоминаю - весь контроль нужно вынести в модули, сделать только две роли - админ и пользователь. На все объекты давать полные права (все равно ничего не получится сделать из того, что запрещено в модуле). Ну и при открытии формы можно проверять, может ли юзверь редактировать объект, если нет - сразу делать ее недоступной. Также на полную катушку нужно использовать привилегированные модули для реализации логики, в которой не нужно контролировать права доступа. Такие вот дела.

В общем я долго думал, как должен быть организован регистр правил для контроля прав доступа, а сегодня меня осенило - он должен быть организован так же, как правила сортировки почты Outlook или mail.ru, то бишь идет набор некоторых правил, они последовательно применяются и выдается результат. Вкратце о тем - дело в том, что для одной ситуации может быть несколько вариантов правил, например если мы перепроводим приходную накладную, то подходят несколько правил и нужно расставить им приоритеты: "Админ может перепроводить любую приходную накладную" Можно было бы конечно идти путем максимального описания шаблона совпадения, но по-моему, если правила отсортированы по приоритету - то это более наглядный и удобный способ, да и правила получаются более компакными. Регистр правил представляет собой таблицу с полями (к примеру): Пользователь - какого пользователя касается. Роль - какой роли касается (или категории пользователя) - роль или группа ролей Объект - какого объекта метаданных касается (например - *, Справочники, Документы, Справочник.Номенклатура) ГруппаОбъектов - чтобы объединить несколько видов метаданных в одну логическую группу (на уровне программы) и задавать правило для нескольких видов, а не для одного вида. Подразделение - какого подразделения касается правило. Склад - какого склада касается правило. Товар - товар или группа товаров, которого касается правило. ГруппаДоступа - группа доступов, чтобы не назначать каждый доступ отдельно. Текущая Неделя Экземпляр - конкретный объект, которого касается правило. Контрагент - контрагент или группа контрагентов. Возможны поля для оперирования со временем документа: ДнейНазад - какое количество дней назад от текущей даты. Вчера - 1 день, 0 - не указано (обычно для даты документа). ДнейВперед - какое количество дней вперед от текущей даты. Завтра - 1 день, 0 - не указано (обычно для даты документа). По аналогии с ДнейНазад, ДнейВперед, можно использовать поля - СекундНазад, СекундВперед. Сегодня - если дата сегодняшняя (обычно для даты документа). Возможны указания интервалов времени действия правил: ВремяОт - время дня, от которого действует правило ВремяДо - время дня, от которого действует правило ДатаС - дата, с которой действует правило (для временных прав доступа) ДатаПо - дата, по которую действует правило (для временных прав доступа) Возможны поля для проверки авторства объектов: Автор - булево, истина, если автором объекта, к которому осуществляется доступ является текущий пользователь. КонтрагентПользователя - если данный контрагент обслуживается текущим пользователем. СотрудникПользователя - если сотрудник соответствует пользователю. Обязательные поля это: Доступ - вид доступа. Право - булево поле, определяет, разрешить или запретить доступ. Продолжить - продолжить выполнение других правил после применения текущего. Действует - действует ли правило (для временного отключения правил). Комментарий - комментарий. В начале предполагается что право есть. Из регистра правил выбираются подходящие контексту правила до тех пор, пока в текущем правиле "Продолжить" - истина. При выборе каждого правила значение права доступа назначается из поля Право правила. Права доступа можно загнать в регистр сведений ПравилаДоступа, в нем так же должен быть ресурс "Порядок", чтобы можно было отсортировать правила по порядку. В измерениях регистра лучше не использовать списки, т.к. тогда нельзя обрабатывать правила с помощью запроса. Например могут быть такие правила (отсортированные по приоритету): Действует = ложь Комментарий = я включаю это правило только если мне нужно произвести в базе массированные изменения Объект = РегистрСведений.ПравилаПравДоступа Комментарий = кто может назначать права доступа Объект = РегистрСведений.ПравилаПравДоступа Комментарий = кто может назначать права доступа Объект = РегистрСведений.ПравилаПравДоступа Комментарий = кто может назначать права доступа Роль = Старший пользователь ГруппаОбъектов = Документы учета товаров Право = ложь Комментарий = старший пользователь не может работать по акцизному складу Роль = Старший пользователь ГруппаОбъектов = Документы учета товаров Право = истина Комментарий = старший пользователь может перепроводить документы задним числом до 7 дней назад Роль = Пользователь ГруппаОбъектов = Документы учета товаров Доступ = Перепроведение Право = ложь Комментарий = пользователь не может перепроводить документы Пользователь = Директор Вася Право = ложь Экземпляр = Уставной капитал фирмы Комментарий = директор попросил уберечь его от пагубного желания править уставной капитал Пользователь = Директор Вася ГруппаОбъектов = Документы учета товаров Право = истина Комментарий = Главбух может смотреть зарплату сотрудников Отчет = Зарплата СотрудникПользователя=ложь Комментарий = сотрудник может смотреть зарплату только по себе. Доступ = * Право = ложь Комментарий = все, что не разрешено, запрещено. Вот теперь вы вкурили, какими должны быть нормальные права доступа и понимаете, что галочные права доступа 1С безнадежно отдыхают. Вкратце напоминаю - весь контроль нужно вынести в модули, сделать только две роли - админ и пользователь. На все объекты давать полные права (все равно ничего не получится сделать из того, что запрещено в модуле). Ну и при открытии формы можно проверять, может ли юзверь редактировать объект, если нет - сразу делать ее недоступной. Также на полную катушку нужно использовать привилегированные модули для реализации логики, в которой не нужно контролировать права доступа. Такие вот дела.

Да, это к теме

тупиковый путь

гыгыгы, не рассказывай, в конце концов везде, где юзверей >50 приходят к такой схеме. Не все конечно сразу невинность теряют, но очень быстро права перекочевывают в модули из галочек.

В чем не откажешь Гению1С так в креативности, даже если предлагаемые им решения носят дискуссионный хараХтер...

спасибо

знаешь для меня есть только один критерий взлетело/ не взлетело, еще не одно творение Гения не взлетело ... так что ... фуфло все это.

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

У меня это взлетело еще на 77.

Ну и что?

просто сейчас я работаю не в той области, чтобы внедрять права доступа. А если тебя интересуют мои внедрения, то вон ТормозИТ развил тему вмешательства в работу форм и парсинга кода, мне это не надо, у меня не типовая.

а то что в данном случае тупо наехал

пробывал я эту идею не прошлой недели  ... трудозатраты не уменьшаются... при обновлении... а гемора гораздо больше.

а может это не глюки а твои, Иван, кривые руки (С) Письмо Директору

лично у меня сейчас права доступа назначаются приказами, проходя утверждение и согласование у начальника. ДОКУМЕНТОМ!

То бишь программно, вы - любители галочек, о таком можете только мечтать.

Ладно, шучу, приказом юзверю уставляется только набор ролей... ;-) но все равно программно и по бизнес-процессу.

может быть ... хотя скорее твои... и че? ложил я вообще на все эти галочки...

Что значит взлетело? Может не самый удачный пример, но та жа теория чисел веками была так для красоты без какого-либо практического выхода и что с ней сделал Райвест, Шамир и Эйдельман, применив полученные теоррезультаты для криптосистем с открытым ключом...

вот именно теория... обоснованная, доказанная, проработанная ... а не те отбросы сознания что нам выдаёт Гений_1С, которые даже не было подвергнуты хоть какому то анализу.

грю тебе, Терв, на 77 так оно и было - все права были записаны в макет, который загружался в ТЗ, а уже по ней разруливались права. В 80 это еще прозрачнее, здесь есть Регистры сведений.

чем галки лучше регистра правил, ну ка?

Готов к обсуждению, если конечно оно тебе интересно.

покажи ему!

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

А не проще ли наследовать права?

скорость где? при записи? я тебя умоляю! к тому же такие регистры можно оптимизировать в таблицу значений и обновлять только при перевходе или раз в 10 минут или еще как... Единственное место, где имеет смысл использовать RLS - это RLS на чтение. Все остальное бред. К тому же в большой системе, где пользователей и ролей много на первое место выступают уже не скорость (а экономим на спичках, господа), а прозрачность прав и оперативность их изменения. не надо из пушек по воробьям.

Про RLS - согласен - рулит только на чтение. Насчет скорости - если при каждом чихе будет читаться этот регистр, могут полезть блокировки. Так что идея кэширования прав в ТЗ - верная, думаю.

Не все идею Г1С бредовые... в предложенной концепции есть что-то прикольное... Хоть и не сам придумл, но интересно интерпретировал имеющиеся наработки... сыро, конечно... надо курить и думать...

"Вкратце напоминаю - весь контроль нужно вынести в модули, сделать только две роли - админ и пользователь." "но для больших предприятий порочность галочек уже давно доказана и выливается в тучу часов простоя когда у юзверей нет прав и в тучу часов исправления ошибок, когда есть лишние права." да, повышенная "гениальность" до добра не доводит "на 77 так оно и было" ну ну, тупо переносить с 7-ки на 8-ку много ума не надо "Чего стоит только тот факт, что новая роль в 1С всегда создается со всеми установленными галочками, бред Нуралиева!" "На все объекты давать полные права" верх гениальности - сначала засрать, потом выдать за свое "чем галки лучше регистра правил, ну ка?" в ролях, кроме галок, есть еще и запросы, баран правда, о чем я? гению не ведомо слово "запрос" "Вот теперь вы вкурили, какими должны быть нормальные права доступа и понимаете, что галочные права доступа 1С безнадежно отдыхают." более дебильного вывода трудно представить ...

"можно оптимизировать в таблицу значений" ну ну, это же код на уровне клиента - тормоза обеспечены + права никогда не должны проверяться на уровне клиента - это азы безопасности роли же (с запросами) выполняются на уровне sql сервера - максимально возможная безопасность и производительность!

Может тебе жениться пора?

У меня такое впечатление, что мозг Гения1С находится в состоянии перманентого мозгового штурма... :) Для нетиповой конфигурации имхо идея хорошая... Но за реализацию я бы не взялся...

Все давно придумано: в правилах почты, файерволов, доступа к файловым системах ext и NTFS ...

+ АД еще осталось заново изобрести в этой ветке.

>Чего стоит только тот факт, что новая роль в 1С всегда создается со всеми >установленными галочками, бред Нуралиева! Создали новую роль без галочек. Начнутся вопли "Аааааа!!!! 1С не работает!!!!!" Ну и ругань в адрес 1С. А создали роль со всеми галочками - все работает. :)

вообще права надо сделать проще :) в каждой таблице завести поле строка в которой 0000011100000  определенный символ означает возможность чтения (записи) и т д права на добавление и т д определеются скриптом... будет легко определять какой док доступен, а какой нет

Для каждого поля или группы полей

Все таки у вас кривые руки товарищ александр прощайте обновления - обоснуйте? Я делаю роль лклАдмин и лклПользователь, а типовые роли не трогаю и не назначаю их... Признаете кривость своих рук? = ну ну, тупо переносить с 7-ки на 8-ку много ума не надо Шедефр софистики. = верх гениальности - сначала засрать, потом выдать за свое не вкурил ты, кури сосредоточеннее. = правда, о чем я? гению не ведомо слово "запрос товарищ, а вы что хотите юзверю дать консоль запросов, а нафига? а уж если даете ему отчеты, рулите в отчетах. Или в КЗ почитайте мою статью, как делать конроль текстов запросов. Мдя, упали вы в моих глазах ниже плинтуса. Кичливый, самоуверенный, не в силах вкурить ничего нового, кроме привычного Беломора.

про назначение нескольких ролей не читал? лучше не навредить, чем дать юзверю возможность залезть куда не надо.

Эрвин, в 77 не было программной модификации конфы и в 80 не будет. 1с пишется для тупых 1снеков.

проверка прав не выполняется на уровне SQL сервера

При обращении к базе если на объект наложена роль то к запросу добавляется еще кусок который выполняет ограничение роли. Например, при открытии справочника контрагентов срабатывает условие отбора контрагентов: Поля по которым не накладвается условие: Запрос SQL:

еще раз для военных - РЛС имеет смысл только на чтение, остальное - от лукавого и вылезет боком.

Ужоснах... Я сделал RLS на запись... Что же делать? :-[ ]

когда кол-во юзверей в твоей базе перейдет за 50, ты перепишешь РЛС на модули. ;-) Если конечно не мазахист.

Юзверей около 60. Полет нормальный.

значитцо мазахист

или боссы у вас не очень требовательные. Не хочу устраивать голосований, но из опыта моего и моих коллег РЛС на запись - это маразм.

Хотя бы потому, что РЛС на запись не обеспечивает всех возможностей контроля, т.е. есть ситуации, где он не работает - хотя бы сравнение прошлого и текущего состояния объекта. То бишь со временем появляется зоопарк методов контроля - от контроля на уровне модуля до РСЛ на запись. И все это нужно документировать, тестировать и сводить в одну систему. Я молчу, что РЛС на запись не выдает диагностики, что можно сделать в модуле. Молодо-зелено, батенька.

"из опыта моего и моих коллег" - как показал опыт МОЙ - можно сей ценный источник информации игнорировать. Ибо опыт у Вас, батенька, уж больно избирательный. Тебе русским по-белому говорят - ВСЕ РАБОТАЕТ. И работает как надо. И не нужны твои извращения. Система контроля прав на проведение документов таки да, не RLS, ибо ее тупо невозможно сделать. Твоя проблема в том, что ты считаешь себя самым умным. А на деле - велосипедостроитель. Спору нет - квадратные колеса - это шедевр дизайна. Но не поедет. З.Ы. Кстати, все в можно сделать гораздо проще и универсальнее.

хахахаха, рассмешил. Ассемблер тоже работает. Речь идет о простоте и надежности СОПРОВОЖДЕНИЯ системы... Мдя, как все запущено, какие понты!

Угу. Насчет простоты - я уже сказал. А насчет понтов - перечитай свои ветки. Там комплексов детских - на небольшую психушку хватит. Ладно, счастливо оставаться.

покеда, двоечник. ;-)

Со словами поаккуратнее, а то ведь и ответить ненароком можно.

дефендер, ты еще не сделал ни одного внятного определения, чем РЛС на запись полезен для твоей базы данных, кроме того, что РАБОТАЕТ. Окей, в 54 считать ИМХО, раз ты такой чуствительный.

как быстро это будет работать на 50 юзверей?

РЛС на запись нужна например чтобы запретить проводить доки

Если уж употребляешь словосочетание "Регистр правил" то было бы неплохо давать ссылку на оригинал, где это давно и успешно работает.

Neco тут подумал для чтения документа (только читается полностью или нет или читается частично)... хотя может быть мой вариант и бред... если надо часто закрывать на чтение ЧАСТЬ документа вообще это надо для скорости вопрос с записью и т д согласен спорен

Честно прочитал три раза. не понял:-)

ты сказал а что нало ставить ограничение не только на чтение всего документа, но и реквизитов.... вот и пытаюсь ответить...

Скорости частичное закрытие реквизитов не прибавит. весь фикус РЛС в том что запрос интегрируется общий запрос на получение или запись данных и значит выполняется эффективнее любых конструкций на клиенте

идея совсем другая... в каждом документе есть дополнительное поле строка в которой хранится последовательность 0 и 1 так вот если там 0 то пользователь не может получить к себе документ если 1 то может тогда в любой запрос будет добавлятся строка типа where substr(g.dostup,номер пользователя, 1)="1" и по ней будет определятся получает пользователь док или нет...

в скоросте как раз выйгрышь (за счет меньшего чтения данных и более простого запроса)

Для каждого пользователя нужно хранить такое поле

поле включает много 0 и 1 для КАЖДОГО пользователя...

Офигенно быстро, все правила хранятся в кеше пользователя в виде ТЗ, контроль в момент модификации данных, по сравнению с самой модификацией данных - копейки.

я думаю термин стал общеупотребительным, потому что я даже не знал, что оригинал - там! ;-) еще раз - в сложной системе появляется сожительство РЛС на модификацию и контроля в модуле - по сути зоопарк из двух методов вместо одного. Отсюда растет бардак. Поэтому имеет смысл отказаться от РЛС на модификацию ради простоты сопровождения. В модуле можно сделать все, в РЛС на модификацию - не все, так зачем изначально распылять силы на два механизма, объединять их вместе, думать об их работе, если можно сразу пойти в правильном пути. И еще раз повторяю - РЛС на модификацию не объясняет юзверю, почему у того нет прав доступа. Пора это уже в КЗ писать. ;-)

неко, издеваешься? какая экономия может быть на единичной операции записи? Ты на спичках тоже экономишь. Ну съэкономишь ты 0.05 секунды на открытии формы, что дальше???

бредовая идея, вернее опять же сильно ограниченная. Читай в разделе = Динамический RLS =

Предлагаю тебе реализовать в любой типовой конфигурации на выбор.

Статья, в которой описывается применение технологии регистров правил для настройки прав доступа, опубликована аж в 2004 году (там же в библиотеке на ). Все реализовано, проверено и давно используется. Мы для того и опубликовали терминологию регистров правил (детерминант, корень, входной контекст, степени соответствия, приоритеты и пр.), чтобы можно было разговаривать на одном языке. Без ссылки на первоисточник тяжело воспринимать новизну Ваших идей :). Возможно, предложенная в статье методика не устраивает (там на самом деле приведена лишь общая схема), но тогда почему бы не указать, что именно нового предлагается Вами.

три года Фиксин продолжает генерировать идеи быстрее , чем у него появляются дешевые мобильные телефоны? или он отошел от того бизнеса "секс за телефон" и перешел на новый "моск за 1С". Эх давно не заходил сюда, а тут все таже неувядаемая звезда.

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

а что, есть какие-то сложности? Берешь парсер, парсишь модули, или в 8.1. делаешь проще - подписку на события и вуаля... Какие траблы-то? да, так оно и есть! жжу!

(0, 77) Знаешь, если я правильно понял то, что ты хотел сказать, у тебя будут проблемы с мелкософтом, если ты припишешь авторство идеи себе...

почему, объясни. ;-)

Пришла в голову мысль - по моему у меня там так написано. ;-) Это не значит что "я придумал и запатентовал" и вообще, копирайты, особенно софтверные - это зло!

Они за любую идею глотку рвут всем. Это раз. Посмотри настройук правил для ИСА-сервера. Это два:)

Я просто говорю, что если начнешь приписывать авторство идеи... Я сказал то, что сказал, ни словом больше.

ну и что же, дружище? Есть вещи очевидные, которые никто не запатентует, например колесо. Но вот если бы я придумал, как использовать колесо в 1С, я бы мог приписывать себе авторство этой идеи, потому что никому в голову не приходило это юзать раньше. Вот те крест, что я даже не знал, что такая фигня у мелкософт есть, значит это очевидное решение. ;-)

счас нам внедряют новую учетную задачу на 8ке... система прав доступа впечатляет... права доступа 1С вообще не используются рулить ими вообще приятно... сильно не вчитывался в , но примерно так и сделано, только  у нас сделано больше на установку прав доступа к объектам и разруливание схем приходования на склады. но в принципе не сложно прикрутить и дополнительные какие фичи... правда теперь все чаще возникает желание, наряду с рабочим место менеджера, склада итд, иметь рабочее место админа :)

Не читал. Скажите, Актив Дайректри еще не изобрели в этой ветке?

это не актив директори. Актив директори описывает слишком простые права доступа. Сравните "файл можно исполнять" и "можно проводить документы, на три дня отстоящих от текущей даты в прошлое". ;-) Вот именно, ребята смыли в унитаз "галочные права" и правильно поступили. Респект и уважуха!

Ну вот и докажи что все просто, трындеть ты гаразд, а теперь по делу чтонить сотвори.

уже все доказано и в КЗ выложено.

То что валяется в КЗ - это еще не доказательство. Пока нет реализации, чтолибо говорить бессмысленно. Если будет типовая конфигурация с твоими ограничениями прав мы сможем тогда сравнить производительность твоего решения и решения от 1С.

гы, а в то что на марсе нет жизни, ты тоже поверишь, только когда туда слетаешь? или в то что на солнце температура 1 млн градусов. Ты что, видишь какие то проблемы с реализацией и производительностью? Теория для того и дана, чтобы прежде чем что-то реализовывать на практике, сначала проверить теорией. чему тебя в универе учили-то? Элементы реализации есть в конфах, которые я писал, да и любой кодер - многие выносят часть контроля прав доступа в модуль.

гений, хде живешь-то? палатку поставил?

снимаю хату в Реутово за 14300 рублей. Но это оффтоп, больше не спрашевай, не отвечу.

чем мой вариант плох? приметивен... зато скорость чтения потресающая!... есть возможность убрать видимость на определенный документ и т д... можно менять права динамически...

тем что это затычка. т.е. ты не решаешь всех проблем прав доступа, а решаешь только частные случаи. 1с-цы с помощью своих галочек тоже решают частные случаи. В результате получается зоопарк контроля прав доступа - галочные права, РЛС, контроль в модуле, на выходе имеем обширное хозяйство, занимающееся только контролем доступа абсолютно неконтролируемое. ;-)

пля... И почему у музы не получается попасть кирпичом гению по башке? P.S. есть предложение скинуться по 50 рублей музе на курсы в стрелковой школе...

могу осуществить.... , но суслика жалко

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