| 0
- 05.04.2017 - 12:10
|
Есть УТ 10.3 Почти типовая. Еще есть директор, не доверяющий небольшому коллективу, есть небольшой коллектив с похожим отношением к директору. Директор хочет все от всех спрятать, чтобы никто ничего не видел, но побольше продавал и побольше приносил денег. Известная и не новая ситуация. Короче надо настроить "новые" права "старым" пользователям. Примерные функции понятны, но нюансы как всегда в тумане. Все надо урезать, оставить минимум, но чтобы все работало. Типичные роли "Директор", "Бухгалтер", точнее "Бухгалтер-Кассир", "Снабжение", "Сбыт", "Склад", "Механик". Кроме того, надо чтобы при отсутствии кого-то, его права можно было легко делегировать другому. У меня вопрос. Стоит ли при таких нечетких требованиях завязываться на встроенной системе ролей УТ 10.3, которая потребует заходить в конфигуратор, что то там менять, выгонять, сохранять. Или поступить по другому, дать на уровне конфигуратора максимум прав и сделать нахлобучку в режиме предприятия, которую придется время от время дорабатывать, что то будет универсально. Тем более при его требованиях обойтись одним штатным функционалом все равно не получится. Аналогичную штуку делал в 7.7, там успешно работает. Но не хотелось бы в УТ 10.3 и велосипед изобретать     | | |
| 1
- 05.04.2017 - 12:52
|
Сделай директору отчет "Кто чем занимался в конфе". С возможностью открыть объекты. Пусть развлекается. Делегировать права. Обормотка "Добавить юзеру роль/и" + регламентная операция "Удалить юзеру роль/и". Эта задаче суть размножение коллекции ролей. Переход на УТ11 позволит все это убрать в Расширения, не трогая саму конфигурацию. | | |
| 2
- 05.04.2017 - 13:14
| ненадо на | | |
| 3
- 05.04.2017 - 13:15
| не надо на УТ 11 ) | | |
| 4
- 05.04.2017 - 13:31
|
3-USSR > Надо, надо. https://wonderland.v8.1c.ru/blog/sis...aimodeystviya/ | | |
| 5
- 05.04.2017 - 13:44
| он там итак за всеми следит, и видеонаблюдение и датчики у водителей и многое другое )) | | |
| 6
- 05.04.2017 - 22:27
| 2(0) Делал подобное как раз на УТ10. Нафиг выкинул типовые права с типовым RLS. Сделал все через таблицы доступа и правила настроек этих таблиц. Возился долго, но теперь все настраивается по принципу: есть группа пользователей с настроенной ролью. Включаю туда человека - у него появляются нужные права, исключаю - права сразу исчезают. Причем настройка этих прав для каждой группы достаточно проста - через наборы правил - эти правила заполняют таблицы доступа, и RLS обращается уже к этим простым таблицам (они все построены по принципу: Пользователь, Объект доступа, Уровень доступа), не строя сложных запросов по правилам (как в типовой). | | |
| 7
- 06.04.2017 - 08:53
| Цитата:
| | |
| 8
- 06.04.2017 - 10:11
|
2(7) Объект базы данных. С вариантом, где роль настраивается через таблицы, и объект - это объект конфигурации я тоже экспериментировал, и пришел к выводу, что лучше иметь жесткие роли. Очень много взаимосвязей между объектами конфигурации, которые на лету и не стоит пытаться настраивать и подстраивать. Лучше их продумывать и реализовать в виде ролей заранее. Косяков будет гораздо меньше. | | |
| 9
- 06.04.2017 - 10:25
|
Ненамного стало яснее ) я не очень понял, что значит право доступа на объект базы данных, которое хранится в таблице доступа. Или таблица доступа генерируется динамически при обращении к объекту базы данных ? Что значит жесткие роли? Они раз и навсегда ? а что настраивается в режиме предприятия ? Какие сущности ? Я посмотрел типовую, там ограничения по организациям и по контрагентам, остальное надо писать и причем все довольно громоздко. | | |
| 10
- 06.04.2017 - 10:45
|
2(9) Типовая это геморрой на глазу. С настройкой ролей через таблицу схема примерно такая (упрощаю для краткости): есть всего одна роль - с самыми полными правами. есть таблица, где каждому пользователю, в зависимости от включенности его в ту или иную группу, прописан уровень доступа к каждому объекту (точнее к ключевым - документам, основным справочникам и т.п.). А все ограничения привязываются к событиям: При открытии, При записи и т.п. В запросах в отчетах так же проверяешь доступность типов данных при формировании (блок проверки в принципе не большой, и вставляется во все запросы без особых сложностей). Написать такое в принципе не слишком сложно, но администрировать - совсем не удобно... Жесткие роли, это роли, которые прописаны в конфигураторе. Их удобно делать не по должностям (как в старой УТ10.3), и не по объектам (как в новой УТ10.3 и УТ11), а по процессам. Например роль "Процесс приемки товаров" или "Процесс оприходования наличных" и т.п. И каждой группе пользователей присваиваешь нужный набор ролей. Когда включаешь пользователя в новую группу, происходит анализ всех групп, куда он входит, и в настройках пользователя автоматом ставятся доступные ему роли - как в типовой). То же самое при исключении кого-то из группы. | | |
| 11
- 06.04.2017 - 12:28
| Цитата:
| | |
| 12
- 06.04.2017 - 12:51
|
Мне кажется, вы говорите о разных вещах. Вообще-то Объект базы данных - это конкретный элемент справочника, либо конкретный документ (с конкретным номером и датой). | | |
| 13
- 06.04.2017 - 12:51
|
2(11) Таблица из Двух измерений и одного реквизита числового. Пользователь: Иванов И.И. Объект: "Документ.ЗаказПокупателя" УровеньДоступа: 5 5 уровень - читать, добавлять, изменять, проводить оперативно, отменять проведениею Для реквизита объекта (условный пример): Пользователь: Иванов И.И. Объект: "Документ.ЗаказПокупателя.Организация" УровеньДоступа: 1 Уровень 1 - только видит, изменение недоступно. | | |
| 14
- 06.04.2017 - 12:56
| Цитата:
| | |
| 15
- 06.04.2017 - 13:12
| Цитата:
Ты не сможешь указать ограничения на конкретный документ. Например: документы филиала1 не должны быть видны пользователям филиала2. Задача Настройка RLS в ограничение доступа на уровне записей. В данном случае я бы отключил бы RLS напрочь. p.s. что бы не использовать подписки - можно подправить одну процедуру - проверка даты в документах. | | |
| 16
- 06.04.2017 - 14:04
|
2(15) Это разные задачи. Я уже говорил, что возился с обеими. С ограничением по допуску на уровне записей как раз очень хорошо решается через промежуточную таблицу. Структура абсолютно такая же. Например: доступ к документу Реализация организован проверкой трех реквизитов: Организация, Контрагент, Склад. В РЛС есть простенький запрос на ограничение по трем таблицам (отбор по пользователю, объекту, уровню доступа не ниже 2). Таблицы выглядят так: Пользователь: Иванов И.И. Объект: Склад Хабаровск УровеньДоступа: 2 Пользователь: Иванов И.И. Объект: Хаврюшин А.И. ИП УровеньДоступа: 3 Уровень 2 тут "чтение и использование в отчетах, использование в документах". уровень 3 - "чтение и использование в отчетах, использование в документах, изменения в карточке объекта" и т.д. | | |
| 17
- 06.04.2017 - 14:50
|
(12)Я именно так и понимаю Но в целом пока что не понял, как у человека все сделано. Но по такому краткому описанию вряд ли и можно что-то понять. Я всегда полагал, что ограничения накладывают на объект МЕТАДАННЫХ, а при проверка конкретного объекта базы данных именно и смотрят ограничения в метаданных, исходя из вида этого объекта | | |
| 18
- 06.04.2017 - 14:56
|
(17)чушь я сморозил, при проверке на уровне записей конечно в ограничениях должны участвовать объекты базы данных. Мы просто все про свое сейчас говорим. Надо разделить задача на доступ к видам метаданных и к объектам БД | |
Интернет-форум Краснодарского края и Краснодара |
