Права в УТ 10.3
 

Есть УТ 10.3 Почти типовая. Еще есть директор, не доверяющий небольшому коллективу, есть небольшой коллектив с похожим отношением к директору. Директор хочет все от всех спрятать, чтобы никто ничего не видел, но побольше продавал и побольше приносил денег. Известная и не новая ситуация. Короче надо настроить "новые" права "старым" пользователям. Примерные функции понятны, но нюансы как всегда в тумане. Все надо урезать, оставить минимум, но чтобы все работало. Типичные роли "Директор", "Бухгалтер", точнее "Бухгалтер-Кассир", "Снабжение", "Сбыт", "Склад", "Механик". Кроме того, надо чтобы при отсутствии кого-то, его права можно было легко делегировать другому.
У меня вопрос. Стоит ли при таких нечетких требованиях завязываться на встроенной системе ролей УТ 10.3, которая потребует заходить в конфигуратор, что то там менять, выгонять, сохранять. Или поступить по другому, дать на уровне конфигуратора максимум прав и сделать нахлобучку в режиме предприятия, которую придется время от время дорабатывать, что то будет универсально. Тем более при его требованиях обойтись одним штатным функционалом все равно не получится. Аналогичную штуку делал в 7.7, там успешно работает. Но не хотелось бы в УТ 10.3 и велосипед изобретать

Сделай директору отчет "Кто чем занимался в конфе". С возможностью открыть объекты. Пусть развлекается.

Делегировать права. Обормотка "Добавить юзеру роль/и" + регламентная операция "Удалить юзеру роль/и".

Эта задаче суть размножение коллекции ролей.

Переход на УТ11 позволит все это убрать в Расширения, не трогая саму конфигурацию.

ненадо на

не надо на УТ 11 )

3-USSR > Надо, надо.
[url]https://wonderland.v8.1c.ru/blog/sistema-vzaimodeystviya/[/url]

он там итак за всеми следит, и видеонаблюдение и датчики у водителей и многое другое ))

2(0) Делал подобное как раз на УТ10. Нафиг выкинул типовые права с типовым RLS. Сделал все через таблицы доступа и правила настроек этих таблиц. Возился долго, но теперь все настраивается по принципу: есть группа пользователей с настроенной ролью. Включаю туда человека - у него появляются нужные права, исключаю - права сразу исчезают. Причем настройка этих прав для каждой группы достаточно проста - через наборы правил - эти правила заполняют таблицы доступа, и RLS обращается уже к этим простым таблицам (они все построены по принципу: Пользователь, Объект доступа, Уровень доступа), не строя сложных запросов по правилам (как в типовой).

[quote=bma1;44029543]они все построены по принципу: Пользователь, Объект доступа, Уровень доступа[/quote]
Объект доступа - Это объект конфигурации или объект базы данных?

2(7) Объект базы данных.
С вариантом, где роль настраивается через таблицы, и объект - это объект конфигурации я тоже экспериментировал, и пришел к выводу, что лучше иметь жесткие роли. Очень много взаимосвязей между объектами конфигурации, которые на лету и не стоит пытаться настраивать и подстраивать. Лучше их продумывать и реализовать в виде ролей заранее. Косяков будет гораздо меньше.

Ненамного стало яснее ) я не очень понял, что значит право доступа на объект базы данных, которое хранится в таблице доступа. Или таблица доступа генерируется динамически при обращении к объекту базы данных ? Что значит жесткие роли? Они раз и навсегда ? а что настраивается в режиме предприятия ? Какие сущности ?
Я посмотрел типовую, там ограничения по организациям и по контрагентам, остальное надо писать и причем все довольно громоздко.

2(9) Типовая это геморрой на глазу.
С настройкой ролей через таблицу схема примерно такая (упрощаю для краткости): есть всего одна роль - с самыми полными правами. есть таблица, где каждому пользователю, в зависимости от включенности его в ту или иную группу, прописан уровень доступа к каждому объекту (точнее к ключевым - документам, основным справочникам и т.п.). А все ограничения привязываются к событиям: При открытии, При записи и т.п. В запросах в отчетах так же проверяешь доступность типов данных при формировании (блок проверки в принципе не большой, и вставляется во все запросы без особых сложностей).
Написать такое в принципе не слишком сложно, но администрировать - совсем не удобно...
Жесткие роли, это роли, которые прописаны в конфигураторе. Их удобно делать не по должностям (как в старой УТ10.3), и не по объектам (как в новой УТ10.3 и УТ11), а по процессам. Например роль "Процесс приемки товаров" или "Процесс оприходования наличных" и т.п. И каждой группе пользователей присваиваешь нужный набор ролей. Когда включаешь пользователя в новую группу, происходит анализ всех групп, куда он входит, и в настройках пользователя автоматом ставятся доступные ему роли - как в типовой). То же самое при исключении кого-то из группы.

[quote=bma1;44031259]прописан уровень доступа к каждому объекту (точнее к ключевым - документам, основным справочникам и т.п.)[/quote] приведи пример записи в свою таблицу ограничений

Мне кажется, вы говорите о разных вещах.
Вообще-то Объект базы данных - это конкретный элемент справочника, либо конкретный документ (с конкретным номером и датой).

2(11) Таблица из Двух измерений и одного реквизита числового.
Пользователь: Иванов И.И.
Объект: "Документ.ЗаказПокупателя"
УровеньДоступа: 5
5 уровень - читать, добавлять, изменять, проводить оперативно, отменять проведениею

Для реквизита объекта (условный пример):
Пользователь: Иванов И.И.
Объект: "Документ.ЗаказПокупателя.Организация"
УровеньДоступа: 1
Уровень 1 - только видит, изменение недоступно.

[quote=Ирли Бёрд;44032133]Мне кажется, вы говорите о разных вещах.[/quote]
И к тому и к тому можно организовать доступ через таблицы. Доступ к объектам конфигурации - мне не понравилось. Сложность администрирования не компенсируется гибкостью настроек. Доступ к объектам базы данных (для RLS) - мне понравилось, через промежуточные таблицы RLS работает гораздо быстрее, чем в типовой через наборы правил напрямую.

[quote=bma1;44032136]Объект: "Документ.ЗаказПокупателя"[/quote] У тебя ограничения на объекты конфигурации.
Ты не сможешь указать ограничения на конкретный документ. Например: документы филиала1 не должны быть видны пользователям филиала2. Задача Настройка RLS в ограничение доступа на уровне записей. В данном случае я бы отключил бы RLS напрочь.
p.s. что бы не использовать подписки - можно подправить одну процедуру - проверка даты в документах.

2(15) Это разные задачи. Я уже говорил, что возился с обеими. С ограничением по допуску на уровне записей как раз очень хорошо решается через промежуточную таблицу. Структура абсолютно такая же.
Например: доступ к документу Реализация организован проверкой трех реквизитов: Организация, Контрагент, Склад. В РЛС есть простенький запрос на ограничение по трем таблицам (отбор по пользователю, объекту, уровню доступа не ниже 2). Таблицы выглядят так:

Пользователь: Иванов И.И.
Объект: Склад Хабаровск
УровеньДоступа: 2

Пользователь: Иванов И.И.
Объект: Хаврюшин А.И. ИП
УровеньДоступа: 3

Уровень 2 тут "чтение и использование в отчетах, использование в документах". уровень 3 - "чтение и использование в отчетах, использование в документах, изменения в карточке объекта" и т.д.

(12)Я именно так и понимаю
Но в целом пока что не понял, как у человека все сделано. Но по такому краткому описанию вряд ли и можно что-то понять. Я всегда полагал, что ограничения накладывают на объект МЕТАДАННЫХ, а при проверка конкретного объекта базы данных именно и смотрят ограничения в метаданных, исходя из вида этого объекта

(17)чушь я сморозил, при проверке на уровне записей конечно в ограничениях должны участвовать объекты базы данных.
Мы просто все про свое сейчас говорим. Надо разделить задача на доступ к видам метаданных и к объектам БД