| Регистрация Правила Главная форума Поиск |
| 0
- 18.01.2012 - 10:42
|
Как в 1С:УНФ 1.3 сделать разграничение прав доступа пользователей к функциональным возможностям конфигурации? Посмотрев на штатные роли не понял, например, как конкретному пользователю дать доступ только к разделу “Запасы и склад”? Получается - свои Роли надо добавлять? На ИТС по УТ11 есть специальные раздел “Ввод информации о пользователях”, там ещё справочник “Профиля групп пользователей”, есть встроенный профиль “Менеджер по продажам”. А в УНФ недоделали это что ли ещё? Так как?     | | |
| 1
- 18.01.2012 - 13:00
| (1) Кроме ролей в 1.3 нет ничего. Смотри сам, если типовых ролей не достаточно делай свои. Развитие системы ограничений обещано в 1.4. | | |
| 2
- 18.01.2012 - 13:46
| Управление НЕБОЛЬШОЙ Фирмой - что ты хочешь от системы? 10-15 пользователей и так договоряться, что кому делать. А бюджет ввода серьезных ограничений слишком велик, чтобы это окупилось на небольший фирме. | | |
| 3
- 18.01.2012 - 17:31
| (2-Reaper) Спасибо. Вот ещё тут нашел: http://forum.infostart.ru/forum28/topic36546/ 3-Lexusss>10-15 пользователей и так договоряться, что кому делать. Договориться то они договорятся, только как объяснить хозяину, что кладовщик может всё?))). >А бюджет ввода серьезных ограничений слишком велик Можно предположить, что раз сама 1с за два года не сделала типовые роли, соответствующие типовому набору должностей (“Менеджер по продажам” и т.п.), то задача нетривиальная. (в 1.4 обещают - уже хорошо) И всё таки, интересна оценка затрат на разработку таких ролей для 1.3? Или лучше 1.4 подождать? | | |
| 4
- 23.01.2012 - 14:21
| http://v8.1c.ru/small.biz/online/~lib_win.htm Восхищаюсь в очередной раз! Ну написали бы просто - "недоделали". Нет же: "Разделение прав доступа для пользователей не используется, т. к. в небольшой организации необходимо обеспечить взаимозаменяемость пользователей."(с) | | |
| 5
- 23.01.2012 - 14:56
|
(4) Предполагается использование настраиваемых RLS или нет? База файловая или клиент-сервер? Количество пользователей? Предполагаемое количество классов ролей пользователей? (в терминологии подсистемы ролей в БСП - это группы доступа) Количество используемых объектов конфигурации? Наличии двойного подчинения сотрудников? Уровень жесткости ограничений: 1. Все должно быть отключено, кроме прямо необходимого по ДИ 2. Пользователю должны быть доступны те объекты, которые прямо необходимы для работы, плюс связанные с эти функции. 3. Достаточно закрыть ряд критических уязвимых мест: ТМЦ, банк, касса. От этого может плясать ценник. | | |
| 6
- 23.01.2012 - 15:20
| 2(6) на 90% переписывал РЛС на УТ10. Проектирование - 2 дня (когда наконоец посетила умная мысль, как все организовать). Создание новых ролей, написание под них шаблонов, создание необходимых метаданных (справочники, регистры сведений с описанием прав доступа) - 3 дня. Все заработало. Допиливание - постепенно в течении нескольких лет (оптимизации, более понятные формы, новые свистелки и т.д.). В итоге, доступ к тому-же справочнику Контрагетов может звучать примерно так: "менеджеру Иванову можно видеть (отчеты и документы) всех контрагентов где он менеджер, плюс всех покупателей из группы доступа Покупатели отечественные из списка регионов, плюс контрагентов из группы справочника "Транспортные компании" этих регионов, плюс компании холдинга как покупатели. Создавать и проводить документы на контрагентов, где он в списке менеджеров плюс транспортные компании. Изменять карточки контрагентов где он основной менеджер (помечен жирниньким)". И создание такого конкретного правила расстановкой галочек занимает минут пять (при наличии минимального опыта). | | |
| 7
- 23.01.2012 - 15:24
| P.S. Уровень доступа по классификации Lexusss'а - "Все должно быть отключено, кроме прямо необходимого по ДИ" (там у меня всякие ограничения по складам, типам цен, типам продукции и т.д. плюс кладовщики не видят, например, закупочных цен и сумм в документах поступления - но это не связано с РЛС) | | |
| 8
- 23.01.2012 - 15:38
|
(Lexusss,7-bma1) Благодарю за содержательные советы! Ещё вот интересно - если кто реально настраивал доступ в УТ11 - как оно? | | |
| 9
- 23.01.2012 - 15:39
|
(7,8) Опять же, оценить могу не в том случае, если ты опишешь свои достижения по гибкости конструктора, а по тем показателям, что я привел. Настройка прав 1000 пользователей при 40 ролях даже без RLS - это намного более трудоемко, нежели настройка прав 10 пользователей с самыми крутыми алгоритмами вроде описанного тобой. У нас проект ограничения прав шел шатко-валко порядка полугода. | | |
| 10
- 23.01.2012 - 15:43
|
(9) Нормальненькая такая подсистемка из БСП. Весьма юзабельно. Большие проекты не смотрел за неимением оных. Соответственно, и замечаний о ее производительности нет. Эту же часть БСП в Документообороте весьма успешно пользуем на сотнях пользователей. Вполне управляемо. Но вот производительность шаблонов хромает, переписывали немало с целью увеличения производительности. Некоторые конструкции оптимизатор MSSQL вообще извращает в хлам, приходилось изголятся в тестах запросов. | | |
| 11
- 23.01.2012 - 15:55
| 2(10) Ролей (базовых и вспомогательных) - две дюжины. Пользователей около 70 (текущее состояние). Объектов конфигурации с ограничениями прав - сейчас чуть выше сотни (справочники, документы, регистры) - как оставшиеся от типовой, так и самописные. | | |
| 12
- 23.01.2012 - 16:02
| Цитата:
| | |
| 13
- 23.01.2012 - 16:31
|
(12) Матрица доступов получает размерность 24 роли * 100 объектов * 3 типа доступа (чтение, добавление, изменение) * 5 различных РЛС (примерно) = более 36000 ячеек. Надо не забывать, что на документы есть еще проведение оперативное и не оперативное. Два дня на проектирование - это 960 минут. То есть при проектировании ты обрабатывал 37 ячеек в минуту!!! Обалденная производительность труда. Я расчитываю трудозатраты скорее исходя из минуты на одну ячейку. Опять же, при практическом внедрении по варианту (1), количество ролей увеличивается раз в 5 над изначально проектируемым. 3 дня на реализацию - это опять же, видимо, только сам механизм прав без автоматизации их распределения и согласования. По поводу "несколько лет" - вот в это верится. (13) Оптимизация RLS - это искусство. Замеры производительности, ловля глюков платформы, анализ километровых планов выполнения запросов, реструктуризация хранения данных, разбор всего того же под файловой базой - это уже не работа... | | |
| 14
- 23.01.2012 - 16:46
| 2(14) У меня разделение по ролям привязано к функционалу а не к ДИ. Т.е. охватывает только часть объектов (на остальное запрет). Т.е. роли "Оприходование товаров", "Авансовые отчеты", "Оформление заказов" и т.п. описывают доступ к каким-то основным объектам и связанным с ними объектам (при оформлении заказа, например нужен доступ к определенным складам и взаиморасчетам контрагентов). И пользователи имеют по три-четыре роли. Т.о. количетсво ячеек резко падает (в роли Заказы поставщикам не нужны доступы к счетам покупателей и наоборот). Во вторых, за счет промежуточного регистра с назначением доступов, 90% доступов по объектам описываются тремя-четырьмя шаблонами. Остальные от них отличаются совсем мало (какими-нибудь деталями). И вначале пользователей было около дюжины всего. Потом их число выросло - вот и начались работы по оптимизации. | | |
| 15
- 23.01.2012 - 16:52
| P.S. в начале существования системы разделителей было всего пять: Пользователь/Группа пользователей, Организация, Контрагент, Склад/Группа складов, ТипЦен. Теперь добавилось еще несколько (тип номенклатуры, физ.лицо/группа физ.лиц и т.п.) Но на сложность системы это практически не повлияло. | | |
| 16
- 23.01.2012 - 16:59
|
(15) Вот мы и подошли к описанию двухдневной работы - 12 пользователей. Вот в это верю легко. В этом случае вместо полномасштабной матрицы доступов пишется просто список доступов каждого из сотрудников. Полагаю, что существующие 24 роли вырисовались при количестве пользователей порядка 30-50. При этом проектировщик уже понимал и держал в голове ту матрицу, которую я описал: матрицу ячеек типа булево. Матрица назначения прав пользователям в твоем случае имеет размерность всего лишь 70 пользователей * 24 роли = 1680 ячеек. Дополнительно, в зависимости от реализации, возможна нагрузка в виде RLS. Про техническую реализацию в виде промежуточного регистра доступов можешь не рассказывать - я в этом не спец. Да и эта самая реализация весьма сильно варьирует при масштабировании решения от 10 пользователей до 70, а затем от 70 человек до 1000. Твоя структура, кажущаяся тебе идеально, с вероятностью 96.37% не устроит конфигурацию с 1000 человек в онлайне. И про файловые базы не следует забывать. Там решение должно быть совершенно иным. | | |
| 17
- 23.01.2012 - 18:07
| 2(17) Разумеется, пилилось под конкретную задачу. Без учета универсальности. Но роли с самого начала строились от функциональных задач, а не от обязанностей конкретных МарьИванн. И потом новые роли появлялись уже как разделение одной старой на две-три новых. Разумеется, для написания матрицы надо было хорошо знать, какие объекты с какими связаны и как. Но, повторю, основная работа пришлась на ту одну рабочую неделю. Все остальное - дошлифовки между делом. | | |
| 18
- 24.01.2012 - 13:35
|
Вот ещё вопрос к гуру ограничения прав): Можно как то увязать Роли для описания ограничений доступа (в понимаемом выше смысле) и Роли для маршрутизации в бизнес-процессах? Или это совершенно не связанные сущности? | | |
| 19
- 24.01.2012 - 13:40
| (19) Они в принципе не связаны. Роль ограничений "менеджер по продажам" никак не связана с ролью "право согласования отгрузок" ибо ею может быть наделен как менеджер по продажам, так и руководитель отдела продаж. | | |
| 20
- 24.01.2012 - 13:41
| Это не связанные сущности. Увязать искусственно можно, только зачем... | |
Интернет-форум Краснодарского края и Краснодара |
