11.08.2004, 13:09 | #1 |
Участник
|
Ограничение доступа по записям
Необходимо ограничить доступ пользователей к записям, специального модуля для этого нет, как можно решить проблему?
|
|
11.08.2004, 13:18 | #2 |
Участник
|
Какая версия? В 3.0 это стандартная функциональность.
|
|
11.08.2004, 13:37 | #3 |
Участник
|
3.0: Администрирование - Настройки - Контроль доступа - Доступ на уровне записей.
шаг 1 - для каких юзеров в какой компании ограничиваем доступ к какой таблице шаг 2 - задаем критерии доступа для нужного набора полей этой таблицы Обратите внимание, что не для всех таблиц это можно сделать. Если у вас программистами добавлены свои таблицы, их также можно без труда внести в этот список, чтобы настроить для ни разграничение прав. |
|
11.08.2004, 13:41 | #4 |
Участник
|
Но учтите еще один тонкий момент.
Доступ закрывается ПОЛНОСТЬЮ. То есть пользователи не только не будут видеть эти конкретные записи, но и данные этих записей не будут попадать ни вкакие отчеты (даже если отчеты что-то суммируют и не показывают деталей в разрезе тех критериев, доступ к которым вы закрыли). Поэтому сначала подумайте, что и кому закрывать, и кто будет получать отчеты с полной информацией.. а то может оказаться, что такого человека вообще не будет... а потом будете долго искать куда же это все делось... |
|
11.08.2004, 13:46 | #5 |
Участник
|
Версия 3.0, но лицензии на модульRLS нет, поэтому нет соответствующей ссылки в меню
|
|
11.08.2004, 14:20 | #6 |
Moderator
|
Ну тогда остается два пути
1) Покупать лицензию на RLS 2) Реализовывать доступ на уровне записей своими силами. Возможно, но трудоемко и криво. Лучше купите |
|
11.08.2004, 14:32 | #7 |
Administrator
|
Если ограничивать надо данные небольшого количества таблиц, можно попробовать модифицировать формы, которые эти данные отображают (ну, и отчеты, конечно). RLS примерно на этом же уровне и работает.
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
11.08.2004, 14:50 | #8 |
Участник
|
Думаю, что придется все-таки своими силами реализовать
Можно узнать с чего лучше всего начать? |
|
11.08.2004, 15:03 | #9 |
Moderator
|
Цитата:
Можно узнать с чего лучше всего начать?
А если интересует общий ответ - то решается наложением range на датасоурсы форм и отчетов, всех интересующих форм и отчетов. Не стоит забывать про возможность перехода к основной таблице |
|
11.08.2004, 15:22 | #10 |
Administrator
|
Для начала можете сюда посмотреть: http://www.axforum.info/forums/showt...=&threadid=184
Правда то, что там написано, только поможет Вам выявить направление поиска решения.
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
11.08.2004, 21:57 | #11 |
Модератор
|
Обратите внимание: RLS -это именно контроль по доступу для чтения, но не для записи. Т.е. Если если список выбора видит только склад 1 и склад 2, то можно руками внести склад 3. информация запишется, а человек столкнется с проблемой "потеряной " записи, т.к. склад 3 ему не виден... С другой стороны, у человека, который видит только склад 3, откуда-то ни возьмись появляется новая запись... Альтернативы особо нет. Только если действительно написать самому, перекрыть lookup и блокировать ввод собственных значений. Было успешно внедрено в модуле "Производство". Пока нареканий не было...
Вот кстати ссылочка: http://www.axforum.info/forums/showt...ified+validate - может, поможет... С Уважением, Георгий. |
|
12.08.2004, 10:21 | #12 |
Administrator
|
Хотелось бы заметить, что если Вы будете разрабатывать все сами, вам все равно придется перекрывать метод lookup(). Мне кажется, задача усложнится не сильно, если вместе с lookup() вы будете перекрывать еще и modified().
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
12.08.2004, 10:27 | #13 |
Модератор
|
....еще init для первичной выборки, что бы выбрать тоьлко те значения, которые разрешены данному пользователи. И еще можно valadateWrite, что бы все-таки не записали, что не надо
С Уважением, Георгий |
|
12.08.2004, 10:31 | #14 |
Administrator
|
Да, вместо modified, наверное, все-таки лучше перекрыть validateField. А init зачем? Если для фильтрации первоначального списка (не lookup), тогда понятно (я уже об этом писал). Или я что-то не понимаю?
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
12.08.2004, 11:03 | #15 |
Moderator
|
Еще, если у Вас Oracle - попробуйте посмотреть про Fine Grained Access Control. Этот механизм решает аналогичную задачу, но вот каким способом, я к сожалению не знаю - надо будет почитать. Поэтому не уверен, что это подойдет для Аксапты. Если кто-то знает - рад буду услышать.
Кроме того, в Yukon (MS SQL Server 2005) обещают поддержку RLS. К сожалению, эта возможность пока не документирована. Известно только, что предикаты безопастности (RULES) будут создаваться как отдельные сущности, которые можно будет назначать пользователям и группам. |
|
12.08.2004, 11:15 | #16 |
Модератор
|
Нет, Максим, все правильно - для посторения первичного списка... Возможно, придется еще перекрыть ExecuteQuery, а не то с помощью фильтров можно получить все, что угодно...
Но, в принципе, это больше им (рабочим) выгодно, чем нам. Легче видеть 2 склада, чем 40, да и заносить данные на другую смену - им же хуже С Уважением, Георгий |
|
12.08.2004, 11:28 | #17 |
Administrator
|
Ну, executeQuery перекрывать совсем не обязательно. Достаточно поставить RangeStatus для фильтра Hidden или Locked.
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
12.08.2004, 12:00 | #18 |
Модератор
|
Да, согласен... Но уж больно жесткое решение - пусть уж фильтруют... Ну, если, допустим, только 1 склад нужен, а доспуп - к 5 ти.
С Уважением, Георгий. |
|