Интересная штука этот ваш говнокод.

Одни говорят, типа, говнокодить можно, если «бизнес просит». Другие говорят, что плохой код писать нельзя, а можно только меньше фич делать. И вроде бы оба правы и спорить бесполезно как с первыми, так и со вторыми. К тому же само понятие «говнокод» слишком субъективно и нужно сначала абзаца три спорить о термине. И мы даже уже спорили об этом и критериев понапридумали даже.

Есть один принцип, по которому можно на всех законных основаниях написать то, что разработчики после вас назовут «техническим долгом» и даже пофиксят. Идея в том, что ни один говнокод в мире не должен нарушать абстракцию, в рамках которого написан этот говнокод. Пока ваш код остаётся в рамках того модуля, в котором определен, говнокодьте себе на здоровье.

Всё. Их много. Они бесполезные, добавлять новые роли муторно, из-за их шаблонов и регистров - жуткие тормоза появляются...
Короче, это пример того, когда сделали типо универсально, но мега тормознуто, и по факту - нифига не универсально.

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

Ты про новую систему RLS, где права в модуле менеджера пишутся на встроенном языке?

Нет. Я про технологию расширений. Чтобы из режима предприятия создавать роли, проверять группы ролей, и т.д.
И сохранять версии изменений, например.

Т.е. Чтобы писать можно было более точечные проверки в рлс. Например, без регистра сведений. Или типо того

Что значит более точечные без регистра сведений? Ты свою механику RLS придумал?

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

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

> из-за их шаблонов и регистров - жуткие тормоза появляются
> но мега тормознуто
> мега глючно
Что тут имеется в виду?

> то что есть сейчас в типовых - это точно не гибко
> по факту - нифига не универсально
Что текущая модель не позволяет сделать?

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

При наличии инструмента для пользователя, вообще всё равно что там внутри и как устроено. Лишь бы работало как нужно.

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

что то  я еще раз прочитал, и не понял - "как это?" :)

Вот опять ты путаешь техническую реализацию с интерфейсом настройки

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

В бокументации к БСП подробно написано, как.

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

Если у тебя есть интерфейс для установки прав на какой-то объект, то какая тебе и остальным разница, что внутри ты должен будешь создать 2 роли?

В том что при любом малейшем изменении правил игры - у тебя будет 100 ролей на чтение одного справочника, и каждый о своими особенностями. Или одна роль, но абсолютно не читабельная, или бывают задачи где в принципе не получится сделать одной ролью, ну или надо будет создавать 100 профилей

Вот этого я совсем не понял. У тебя в любом случае будет максимум 2 роли на каждый элемент. Откуда 100 ролей на чтение 1 справочника?

Почему? Я разве не могу сделать две роли на чтение одного справочника с разными правилами?

в 1С то права действуют по странному принципу ИЛИ

Ты конечно можешь сделать всё, но зачем 2 роли на чтение делать?