Форум на Kuban.ru (http://forums.kuban.ru/)
-   Территория 1С (http://forums.kuban.ru/f1040/)
-   -   ограничить доступ менеджерам (http://forums.kuban.ru/f1040/ogranichit-_dostup_menedzheram-3085844.html)

Oksanakm 20.09.2012 15:40

ограничить доступ менеджерам
 
Ут 10.3 доработанная под предприятие. Нужно сделать так, чтобы менеджеры видели только своих контрагентов - то есть тех, у кого этот пользователь есть в таблице менеджерыпокупателя. А вот то разделение по группам пользователей не достаточно, потому что фирм много менеджеров много и контрагентов много, один контрагент может быть у нескольких менеджеров из разных фирм(или я чего-то недопоняла). Ограничение доступа надо делать на уровне ролей. Роль пользователь нужна, без неё в базу не зайти, а в ней уже открыт доступ по группам... то есть роль пользователь надо уже исправлять или добавлять новую роль. Если я сделал роль как пользователь, но ограничила доступ к тем конрагентам у которых этого менеджера нет. но при добавление роли менеджер по прадажам, так как все функции и возможности менеджера по продажам ему нужны. докменты стали ограничиваться по группам пользователей. И Менеджер стал видеть документы не своих конрагентов пусть они у него как объект не найден отражаются, но нам это не надо, это даже хуже, смущает их это: объект не найден. получается что надо править ещё роль менеджер по продажам что очень не хочется делать. Либо создавать роль похожую на менеджер по продажам с нужными ограничениями по документам и во всех местах в конигурации добавлять где о менеджере о продашах говрится ещё и о новой роли как_менеджерПоПродажам.
Либо может сделать в группы пользователей ещё один вид объектов доступа по менеджерам, но тогда придется опять же все роли дорабатывать - или это мне не поможет? что же делать? у вас были такие проблемы как вы их решаете?? чтобы вы мне посоветовали?

roma n 20.09.2012 15:43

чё пил(а)?
ЗЫ количество групп пользователей = количесто менеджеров

Oksanakm 20.09.2012 15:44

1-roma n >думала.. не подходит, потому что если добавляется контрагент, то его обязательно забудут туда добавить.. место связи это таблица менеджеры контрагентов

Oksanakm 20.09.2012 15:47

1-roma n >так и думала что всякие такие шутки понапишутся.. удивляет объем наверно, текта много, ну а что делать вот такой объемный вопрос был бы он не столько объёмный наверно бы смогла распутаться.

roma n 20.09.2012 15:50

2-Oksanakm > и чё? Пару раз по рукам стукнут забывшему - памяти прибавится.
ЗЫ задачу контроля обязательного указания группы для вновь вводимого контрагента решить элементарно. Ради сабжа ломать систему ролей (собственно, предназначенную для решения озвученной задачи) - удовольствие крайне сомнительное.

Lexusss 20.09.2012 15:51

[quote=Oksanakm;26922842]что же делать?[/quote]
Переделывать типовые RLS
[quote=Oksanakm;26922842]у вас были такие проблемы[/quote]
Да
[quote=Oksanakm;26922842]как вы их решаете?[/quote]
Переделкой типовых RLS.
[quote=Oksanakm;26922842]чтобы вы мне посоветовали? [/quote]
Оставить справочник контрагентов открытым всем на просмотр. Ограничить доступность контактной информации, событий, заказов (и пачки документов обвеса), реализаций; регистров продаж, себестоимости, заказов.
Сделать новые/переделать существующие роли (в зависимости от потребности в обновлениях) под новую логику RLS. Переделывать придется во всех ролях, которые дают доступ к документам и справочникам, которые Вы ограничиваете.

Reaper 20.09.2012 15:51

Советую ознакомиться с документацией...

Oksanakm 20.09.2012 15:52

1-roma n >и групп доступа к контрагентом столько сколько контрагентов?

Oksanakm 20.09.2012 15:53

6-Reaper >я ознакомилась.. я что-то недопоняла?

Oksanakm 20.09.2012 15:55

5-Lexusss >просмотр оставлять тоже нельзя... большую секретность хотят, но поняла, что посоветовали. Спасибо.

Oksanakm 20.09.2012 15:59

4-roma n >ну оставлю себе как вариант, пожалуй. можно попробовать программно как-то это обрабатывать при добавлении менеджера у контрагента.

Oksanakm 20.09.2012 15:59

4-roma n >спасибо за идею

roma n 20.09.2012 16:00

3-Oksanakm > [em]удивляет объем наверно [/em]
Не-а. Удивляет диспропорция между количеством слов и полезной информации...
7-Oksanakm > Нет.
Группа доступа "контрагенты Петрова". Разрешенные объекты доступа -Контрагент1, Контрагент2.
Состав группы - пользователь Петров.
====
5-Lexusss > Если я правильно понял задачу такого пилотажа в сабже не требуется. Если неправильно понял,- да перепахивание логики ограничений для всех используемых ролей

Reaper 20.09.2012 16:03

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

Oksanakm 20.09.2012 16:15

13-Reaper >12-roma n > пока остановлюсь на этом..Спасибо..

Lexusss 20.09.2012 16:18

(12,13) Таблица менеджерЫпокупателя. Для 10 менеджеров количество групп доступа получится 10! = 3 628 800. Для 20 менеджеров справочник получит вообще невообразимые 20! = 2,5 миллиона триллионов записей.
Чудесное решение!

Reaper 20.09.2012 16:20

(15) Чтобы получить такое количество нужно заиметь 2.5 миллиона триллионов контрагентов с [b]разными[/b] настройками доступа. Никто из нас не предлагает составлять все комбинации менеджеров, зачем за идиотов то нас считать?

Lexusss 20.09.2012 16:24

(16) Окей. 20 тысяч контрагентов в справочнике выползет в 20 тысяч групп доступа. Классная производительность получится?

Lexusss 20.09.2012 16:25

(17) Мы в свое время бешаное количество времени убили, пытаясь понять, почему оптимизатор MS SQL странным образом строит план выполнения в RLS. Пока не впихнули словечко РАЗЛИЧНЫЕ в один вложенный подзапрос, чтобы обмануть оптимизатор.
При этом групп доступа было поменьше, чем 20 тыр.

Oksanakm 20.09.2012 16:30

да многовато получится.

Oksanakm 20.09.2012 16:32

не подходит, все таки с ролями придется разбираться.

Oksanakm 20.09.2012 16:35

16-Reaper >не считаю я тут никого идиотами.., зачем бы я стала сюда спрашивать. всем понятно, что это я туплю.

Lexusss 20.09.2012 16:52

(21) Reaper это так со мной общается. :) Потому как я именно так и считаю :)
Чтобы успокоить наш спор - сколько у вас контрагентов и разных вариантов сочетания менеджеров? Можно попробовать прикинуть даже запрос для такого подсчета

Oksanakm 20.09.2012 17:04

22-Lexusss >подумаю как сделать такой запрос. Но скажу несколько тысяч контрагентов и десятка два менеджеров.

Reaper 20.09.2012 17:19

Да там вряд ли больше 50 вариантов. Но дело даже не в этом, а в том, что для постановки эксперемента с типовой системой прав нужно часа 2-3. А по уму ограничения делать она неделю будет. И где логика? Хотя да, оклад... портит людей, портит!

roma n 20.09.2012 17:24

23-Oksanakm > O_o там даже думать не нужно :)
17-Lexusss > я УТ/УПП на ограничение доступа к контрагентам не смотрел... Как же я ошибался :) RLS основанное на Справочник.Контрагенты.Реквизит.ГруппаДоступаКонтрагента никакой гибкости настроек не даст. Если структурировать справочник под предлагаемое ограничение доступа не получится - требующееся количество групп доступа зашкалит за пределы разумного. Пилить логику RLS.

Lexusss 20.09.2012 17:24

(24) Не надо по уму. Перепил в умелых руках займет от силы полдня. Проблема, конечно, останется в стародавнем баге с изменением контрагентов, при котором изменивший пользователь лишается на него прав. Но это не столь критично.

Reaper 20.09.2012 17:44

[quote=Lexusss;26924577]умелых[/quote]
Вот-вот.

VZ 20.09.2012 17:50

Роль все едино добавлять нужно. Связка контрагент-менеджер - тоже. Кондово-сермяжный способ (справочник, регистр - главное, легкая структура) - не? Для управления - обормотка. Даже внешняя. История нафиг. Удаляется вся музЫка двумя кликами, без потерь данных...

bma1 20.09.2012 18:48

[quote=VZ;26924915]Роль все едино добавлять нужно. [/quote]
И удалять доступы к контрагентам/документам в существующих.

DeiMos 20.09.2012 19:59

задачу контроля обязательного указания группы для вновь вводимого контрагента решить элементарно.

Чучундер 20.09.2012 20:02

нельзя сешивать перивчную информацию (список контрагентов, товаров) со вторичной инфой (контрагенами списокм контрагентов для пользователей).

Чучундер 20.09.2012 20:03

ну о определиться - является ли "хотелка" фильтров контрагентов по менеджерам всего лишь хотелкой или ожним из основных функциональных необходимостей учета.
.
у 1Ски пока все в типовых смешано в кучу...

qweqwe123123 20.09.2012 22:28

ааа... потуплю на перефирии.
1) контрагенты как делятся между менеджерами - от балды, или же есть система какая-то из нескольких правил, признаки (свойства) контрагентов?
2) а 7шный чисто подход для торговли не катит? може таки создавать при входе список контрагентов конкретного менеджера, который использовать как "отбор" и обновлять по мере добавления контрагентов?

VZ 20.09.2012 22:45

Поди есть же регистр для произвольных реквизитов контрагента? Ну, типа контактный телефон, мыло, чО-нить подобное? Ну, значит, можно запсочить и "ответственного". При входе этого ответственного для него организовать виртуальную таблицу подопечных контрагентов. Вот и фильтр будет... Не?

EarlyBird 20.09.2012 23:51

оксанка! я тя люблю!
@)->----

Чучундер 21.09.2012 00:02

(34) что сразу приводит к необходимости разделять произвольные реквизиты на чисто информационные - позырить глазами, и селективные - используемые для чего-то.. вот что делать если при входе в баз у у контрагентов как класс отсутсвует произвольный реквизит "ответсвенный"...?

Reaper 21.09.2012 00:35

(35) Не подскользнись токмо...

Oksanakm 21.09.2012 07:57

33-Зелёный тролль >1)от балды делятся..
2) и все таки придется править роли... а так я и из контрагента возьму ограничения(где в таблице менеджерыконтрагента есть этот пользователь - или это медленно будет работать??). я уже это сделала в новой роли, как пользователь, только ограничения по справочникам поменяла..ну и для прав как у менеджера я сделаю тоже.. но как-то хотелось бы поменьше нового.. вдруг потом где-то чего-то вылезет..

Oksanakm 21.09.2012 08:00

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


Текущее время: 20:17. Часовой пояс GMT +3.