Для предоставления доступов в 1с используется механизм ролей. Минус его — в сложности администрирования.
Есть два подхода работы с ролями:
1. Создаем роль под должность/функционал и указываем там права на все необходимые документы, справочники и т.п.
Минус данного подхода в том, что если требуется изменения какого нибудь права на один объект из данного функционала, то придется обновлять конфигурацию. Это долго. Порой только на следующий день, а права нужны вот прямо сейчас.
2. Создаем на каждый документ/справочник по несколько ролей типа: ЗаказСоздание, ЗаказПроведение, ЗаказПометкаУдаления, ЗаказЗапись и т.п.
Когда в базе сотни документов список будет просто огромный и администратору нужно много времени на настройку прав.
Предлагаемая подсистема позволяет менять права в реальном времени, без обновлений и перезапуска 1с. При этом интерфейс прост и не требует много времени на изменение прав. Подсистема подходит как для обычных, так и для управляемых форм.
Для использования подсистемы должна быть одна роль для всех пользователей, которая разрешает все (кроме непосредственного удаления). Подсистема ставит запреты и не может дать разрешение если этого разрешения нет в роли.
По умолчанию, если права не назначены, для всех стоит запрет на все. Это поведение можно изменить в коде.
Документ установки прав на "пустого" пользователя применяет эти права всем пользователям по умолчанию.
Права назначаются с определенной даты, следовательно можно сделать так, что например три дня у пользователя будет право, а потом заберется.
Право определяется на основании "логического максимального" на текущий момент. Например на должность стоит запрет на создание заказа, а на пользователя разрешение. В итоге будет разрешение.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Я так понимаю у всех админские права, которые режутся этим документом?
Затем кодом в каждом объекте проверяются права, что плохо скажется на производительности.
(1) Да, режутся в подписках.
В нашем случае вообще ни как не сказывается на производительности (УПП размером 800 Гб, >300 пользователей, правда сервера мощные и база на ssd дисках).
Но и в общем не должно сказываться, в общем времени открытия/записи/проведения документов очень маленький процент на выполнение данного кода.
А через Расширения можно до окончания рабочего дня добавить права пользователю,
а на следующий день их отключить т.к. необходимая Роль создана?
(3)
По сути, вы уходите от Ролей и переходите на индивидуальные права для пользователей.
А профилем нельзя решить? Перезайдет в 1С и все.
Кстати, если подсистема делалась только для того, что допилили новый док, а права не настроили.
То для этих целей создают вторую роль администратора, у которого забирают все права и ставят галку для новых объектов.
Тогда нужным пользователям эта роль назначается до момента настройки ролей. Потом эту роль просто также обнуляют и дело в шляпе. Так намного эффективнее!
(4) Можно. Но нужно много ролей и их сложно администрировать.
Например одному пользователю можно проводить РТУ, другому нельзя, третьему нельзя их создавать но можно смотреть, четвертому можно отменять проведен.
Нужно 4 роли. Таких документов например 100. Получаем 400 ролей. Далее месяцами создаем 150 профилей в каждый подбирая из списка по 400 ролей.
Мы пробывали так, у админов глаза на лоб лезли от необходимости постоянно копаться в списке из 400 строчек.
(6) Не для этого. У нас есть общая роль, которая у всех и там автоматически встают права на новые объекты.
Используем похожий механизм: механизм «Администрирование прав объектов» в типовой конфигурации 1С:Университет (не могу точно сказать, является ли это механизмом БСП или разработчики сами его придумали). Там у них одна роль Пользователь, которой разрешено почти всё (но ниже, чем полные права). Создавать, а потом переделывать при каждом обновлении свои роли оказалось неудобно. Механизм «Администрирование прав объектов» также позволяет перенастраивать доступ «на лету» (можно сразу на группу пользователей).
Извращение, конечно, еще то, но конкретно в данной конфигурации оказалось удобно 🙂
Пример настройки прав:
мы когда-то экспериментировали: пробовали программно создавать роли на чтение и запись каждого объекта. И потом обработкой раздавать пользователям. Дело было в УПП
Кончилось тем, что УПП запуститься не смогла — платформа падала
Игорь, а есть инструкция, как объединять со своей конфигурацией?
при изменении существующей роли в конфигурации можно обновляться динамически.
представленные механизмы и скрины это технологии прав эдак до 2015.
современные методы ограничения прав вполне логичны и не глаза на лоб лучше выкатывать,
а грамотно работать с профилями.
сейчас не вижу причин навешивать на типовые профили и группы доступа своего троянского коня.
не удивлюсь, если если из этого коня полезут бокопоры.
(12) По моему, Вы совершенно не разобрались в сути вопроса и в причинах для чего это было сделано.
Пример — у вас есть документ, на который надо одному пользователю дать доступ только для просмотра, другому для создания только новых документов, но не без права изменения записанных, третьему право редактирования, но без права создания новых документов. четвертому — полный доступ, а пятому полный доступ до пятницы. При этом в типовой есть только роли «только чтение» и «полный доступ» на этот документ, которые, при этом еще предоставляют такой же доступ еще на пару видов документов из этой же подсистемы.
И вот давайте, теперь, расскажите, как Вы будете «грамотно» настраивать доступ на этот один только документ с помощью профилей не создавая 4-5 новых ролей?
(11) Для разных конфигураций свои особенности.
В обмен через сравнение объединение переносим все объекты (кроме справочников).
Для роли «все права» ставим разрешение на все объекты конфигурации и добавляем эту роль всем пользователям.
Находим процедуру, которая вызывается из всех форм и вставляем в нее вызов процедуры из подсистемы прав. Для УТ 11.4 можно например в УправлениеСвойствамиКлиент:
Если в конфигурации нет профилей или они используются по другому, то внести изменения ИТК_ДоступКОбъектамСервер.СтруктураДоступа. (например просто удалить часть кода где используется профиль пользователя )
(14) Насчет динамического обновления только в экстренных случаях я не согласен — может 5-10 лет назад оно и было «демоническим», а сейчас его опасаться выглядит как-то параноидально. Проблема с кешами надумана или еще актуальна в УПП и прочих ИБ родом из нулевых.
По остальным аргументам, если вам проще работать со своей надстройкой над РЛС, то кто ж вам запретит — работайте. Я считаю, что проще полагаться на типовой и ваять свои профиля.
Юзеров около 300 и полный комплект ИБ линейки 1С. По правам мало когда бывают затыки, больше времени уходит на разгребание багов после очередного обновления ИБ, но так как вы еще на УПП, то вам вряд ли будет понятен этот абзац.
а как рубится доступ к данным через запросы? если ранее у пользователя не было прав на таблицу остатков товара, то и отчет выдавался пустой. Или например как в скд, нет прав на просмотр таблицы, часть данных в отчет не выводится. Т.е. запрос режется платформой на основе ролей. А тут получается будет доступ на все?
А к регистрам доступ тоже будет контролироваться? Данные получаемые отчетами как-то ограничивать можно?
(14) выстрадано
(16)Динамическое обновление было и есть демоническое — никогда не знаешь что у тебя потеряется
К примеру после трех динамических обновлений потерялись доработки формы — последовательность колонок на форме откатилась на несколько обновлений назад. И тут уже ничего не сделаешь — на сервере лежит именно такая конфигурация, а доработки формы потеряны. Самое страшное в этом всем — что понять что у тебя что то потерялось сразу не всегда возможно. Может и у вас что то потеряно но вы пока об этом не знаете ? )
Какое-то непонятное, половинчатое решение. Позволяет ограничить только запись.
А построение управляемого интерфейса? Видимость команд? Просмотр справочников, документов, данные в отчетах?
(21) Нормальное решение в духе 1С. Суперкостыль. С недокументированными супернедостатками, как и полагается. ;))
(14)Динамическое обновление ролей благославлено самой компанией 1С — они не кешируются! Можно обновлять без опасений!
(16)Проблема ошибок кеша до сих пор актуальна — но решается флагом чистки кеша
(21)Данные получаемые отчетами (при применении RLS) не может ограничить даже сама платформа по ролям в ряде случаев (я про бух регистры говорю).
А вообще мне интересно, как автор ограничил просмотр в формах даже без отчетов?
(22)У 1С вообще с настройкой прав доступа всё очень печально на уровне платформы — один сплошной недостаток — и ничего не поделаешь — поэтому компаниям параноикам остаётся только накручивать много много подобных мегакостылей — в попытке закрыть все лазейки и запрещая использование всего, где этот костыль ещё не накручен (например касабеьно отчётов — использовать только свои доработанные отчеты, корректно проверяющие выводимые данные на разрешённый доступ уже во «время вывода» результата, а сами данные собирать и обрабатывать в привилегированном режиме приходится). А для большинство руководителей уже махнуло рукой на гибкое ограничение на просмотр информации (да и вообще на гибкую настройку прав доступа) — тут важнее чтобы лишнего в базе не изменили, а не то, чтобы не увидели!
Но всё-равно вот так вот индивидуально права очень геморрно расставлять. Но это уже другой вопрос.
(26) я вообще не понимаю, как народ в общем случае решает проблему с РЛС — оно ж тормозить начинает пипец как…
10 лет на проектах что-то выдумываю для клиентов в плане прав. каждому индивидуально — универсально для всех пока никто ничего не придумал. типовой механизм профилей — слабая попытка решить вопрос. лучший способ — в контексте требований клиента реализовывать дополнительную функциональность. как с обувью — каждому свой башмак.
(27) никак. а точнее уточняешь задачу до деталей и реализовываешь свой механизм. А ты как хотел?
(17) (18) (25) Данная подсистема служит для ограничения только по документам и справочникам.
Разграничение по разрезам данных настроено через RLS. Т.е. пользователи видят только документы, относящиеся к их подразделению например.
Отчеты в основном используются внешние, а на внешние отчеты и обработки тоже настроено RLS. Таким образом пользователи могут запустить только доступные им отчеты.
Вариативные права, например право проведения документа до 11 часов должно быть только у начальника планово-экономического отдела и фин директора, а у остальных после 11, реализованы через систему «дополнительных прав» (УПП 1.3, УТ 10.3).
(21) Не только запись. Еще просмотр, создание. Т.е. нельзя открыть документ посмотреть, если нет прав. Или можно открыть посмотреть, но новый создать нельзя (форма не откроется и выдаст ошибку).
(27)Если использовать аккуратно и по чуть-чуть — то оно вполне нормально работает. Тут главное параноей не страдать — по ограничению доступа к данным «всех и вся». Стараться делать, только интерактивные ограничения (к справочника и документам), и в, основном, только на изменения, а не на чтение. А если уж приспичит где-то делать ограничения на чтение или на неинтерактивные операции — то вот тут уже нужно костыли изобретать, если участок окажется критическим по производительности.
(31) А как это возможно с помощью подписок? Подписка на создание формы есть только для обработок. Или я чего-то не знаю?!
Впрочем проблему командного интерфейса так все равно не решить.
Круто, НО администрировать такое — надо понимать все взаимосвязи, а это сделать рядовому «Администратору 1С» может быть и не под силу, а так как вариант…
(32) Проблема, как всегда, в том, что мало кто готов сформулировать окончательные требования по ограничениям доступа до разработки схемы БД, а после оно в схему плохо ложится со всеми вытекающими… Но самая задница возникает когда ставится задача ограничить данные отчётов. РЛС на регистры — это ад.
(29) хотелось хоть какого-то универсализма. хотя бы на уровне совместимости РЛС с СКД… но и этого нет, мля. Видел фреймворки, на которых более логично это выглядит. но там других проблем навалом.
(35)Вот поэтому я и сказал — RLS можно применять, но без паранои и в основном только на интерактивный доступ к изменениям (и как разделитель справочников и документов в формах списка)
(37) == платформа принципиально не годится для построения систем массового обслуживания ака личных кабинетов и тп. Справочник БСП «Внешние пользователи» является томлением духа и суетой…
(38)К чему Вы это написали
(39) просто ною. любимая мозоль.
(40)Универсальных систем пока не придумали, да и вряд ли придумают, для людей, вообще когда-либо, не нойте! Работайте с тем, что есть. Развивайте. Предлагайте новое!
Допустим будет два плана счетов, одинаковых с разными правами и общая оборотка будет собираться как сумма этих двух (трех, пяти.. ) бухгалтерских регистров. Про двойную запись забываем как пережиток прошлого. Контроль и так программный. Как то не очень красиво.
Мне нравится такая система настройки прав доступа. Возможно, компоновка интерфейса на основе ролей без чтения объектов это интересно и ее есть куда развивать.
(36)ясно)
(20) Это больше похоже не на динамическое обновление, а на поочередное обновление из разных конфигураторов.
Если на сервере отладка запущена от другой службы и на других портах. то вы можете одновременно запускать 2 конфигуратора в одной базе, если при этом вы обновитесь сначала в первом конфигураторе, а потом во втором, то все изменения из первого конфигуратора перезатрутся.
(12) А точнее из нулевых. Привет Рарусу, во всех их продуктах такая подсистема прав.
Подобные решения уже есть во многих отраслевых конфигурациях. Например в БИТ_финанс есть настройка прав доступа на уровне базы. Часть проблем снимает, но задача разделения прав при чтении данных остается.
(16) оно до сих пор не работает.
буквально через пару минут начинаются глюки.
Платформа 8.3.14, хотя заявлено решение было в 11 или 13-й.
(16) RLS само по себе так тормозит, что очень хочется что-то другое и быстрое.
Мне вот интересно, что за бардак такой, что нельзя стандартизировать роди пользователей?
Насколько это проще, вообще ничего не надо, обратился к отделу качества, написали служебные инструкции, снадартизировали роли
И все!!!
Нужно что- то срочно поправить — есть отдел качества, он поправит за нерадивого сотрудника. Никому никакие права динамически менять не нужно.
(49)Кстати, да. Сколько раз стыкались «у нас всё через одно отверствие, и мы не можем ничего сказать точно, никаких должностных инструкций нет, но нужен четкий учет». Так система вам учет не исправит. Что это за предприятие, на котором постоянно куча пользователей с разными правами, которых нельзя в группы поделить?
В ЕРП сделано через набор ролей. К каждому документу/справочнику/регистру делается отдельно роль на создание/изменение, чтение или что-то уникальное. То, что дописываем, делаем точно так же. И потом изменить права никаких проблем нет. Кстати, в той же ЕРП есть пункты, в которых документ разделяется по пунктам доступа, но это скорее исключение (типа заявок на расход ДС, у которых есть инициатор и есть согласующие).
А если такое постоянно…
(50) Все права один раз прописаны по должностям, никакого бардака нет в этом плане. Изменения прав бывают не часто.
Например есть подразделение, в котором только у бухгалтера есть право проводить ПКО. Бухгалтер уходит в отпуск. Право проведения ПКО на время отпуска бухгалтера дается какому то одному самому ответственному сотруднику. (естественно все права бухгалтера ему дать нельзя).
Подсистема предназначена большей частью для упрощения работы администраторов 1с (наглядность установки прав). Была попытка сделать все через роли (по 5-6 родей на объект), но скорость составления матриц прав по должностям, их контроль и изменение в этом случае упала в разы.
(52)В УПП нельзя давать несколько профилей юзеру?