25.05.2009, 16:40 | #1 |
Участник
|
Частичный доступ к данным
Добрый день!
Вопрос следующий. Необходимо реализовать возможность просмотра менеджарами только своих бизнес-партнеров. Но при этом необходимо, чтобы менеджеры видели частичную информацию (название и ответственный) всех бизнес-партнеров. Можно конечно скриптом на onload делать (в зависимости от того свой это бизнес-партнер или чужой ) видимыми или невидимыми нужные поля. Но при этом загрузка формы происходит гораздо дольше и первые пару секунд все-таки видно все поля, до того как они исчезнут . Я пыталась решить проблему созданием дочернего объекта (который содержит поля название и ответственный) и БП создавала такие объекты и настраивала синхронное изменение данных в его полях с бизнес-партнерами. Бизнес-партнеры для просмотра ролями настраивала только уровень пользователя (только своих), а новый объект был всем доступен для просмотра. Может есть более оптимальный вариант решения? |
|
25.05.2009, 17:09 | #2 |
Чайный пьяница
|
Цитата:
Сообщение от Elka
Добрый день!
Вопрос следующий. Необходимо реализовать возможность просмотра менеджарами только своих бизнес-партнеров. Но при этом необходимо, чтобы менеджеры видели частичную информацию (название и ответственный) всех бизнес-партнеров. Можно конечно скриптом на onload делать (в зависимости от того свой это бизнес-партнер или чужой ) видимыми или невидимыми нужные поля. Но при этом загрузка формы происходит гораздо дольше и первые пару секунд все-таки видно все поля, до того как они исчезнут . Я пыталась решить проблему созданием дочернего объекта (который содержит поля название и ответственный) и БП создавала такие объекты и настраивала синхронное изменение данных в его полях с бизнес-партнерами. Бизнес-партнеры для просмотра ролями настраивала только уровень пользователя (только своих), а новый объект был всем доступен для просмотра. Может есть более оптимальный вариант решения? Как такой функционал реализуется - пишутся плагины на Execute и Retrieve, которые перехватывают данные возвращаемые на клиент и меняют их (в вашем случае очищают поля). Пример реализации - у меня правда была немного другая задача - вот.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
|
За это сообщение автора поблагодарили: Elka (1). |
25.05.2009, 17:13 | #3 |
Участник
|
Прикольно.. Спасибо!!!
|
|
25.05.2009, 18:00 | #4 |
Moderator
|
Согласен с коллегой: плагины на Execute и Retrieve - самое элегантное решение, но будьте внимательны: У пользователей которые будут получать купированные записи не должно быть прав на их сохранение, иначе они могут похерить все что от них скрыли. Иными словами дайте всем прова на простмотр и скрывайте поля от тех у кого право только на чтение (без записи).
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия. MS Certified Dirty Magic Professional |
|
|
За это сообщение автора поблагодарили: Elka (1). |
25.05.2009, 18:05 | #5 |
Участник
|
Цитата:
Сообщение от Артем Enot Грунин
Согласен с коллегой: плагины на Execute и Retrieve - самое элегантное решение, но будьте внимательны: У пользователей которые будут получать купированные записи не должно быть прав на их сохранение, иначе они могут похерить все что от них скрыли. Иными словами дайте всем прова на простмотр и скрывайте поля от тех у кого право только на чтение (без записи).
|
|
27.05.2009, 14:51 | #6 |
Участник
|
Цитата:
Сообщение от Артем Enot Грунин
Согласен с коллегой: плагины на Execute и Retrieve - самое элегантное решение, но будьте внимательны: У пользователей которые будут получать купированные записи не должно быть прав на их сохранение, иначе они могут похерить все что от них скрыли. Иными словами дайте всем прова на простмотр и скрывайте поля от тех у кого право только на чтение (без записи).
|
|
27.05.2009, 15:02 | #7 |
Moderator
|
Вы не поняли. Ваш плагин должен зафиксировать, что запрос данных некоторой организации выполняется от имени человека не имеющего прав на изменение данной конкретной организации. Это можно проверить программно. Если права допускают изменение, то и прятать ничего не надо. В упрощенной схеме, по крайней мере.
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия. MS Certified Dirty Magic Professional |
|
27.05.2009, 15:03 | #8 |
Чайный пьяница
|
Написать Pre-Update Plugin, который будет проверять возможность поменять (в соответствии с ролями) те или иные поля и в случае запрета - просто удалть эти поля из сущности. Т.о. получится, то что Вам надо. Но это опять таки надо проектировать и писать... В коробке нет.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
27.05.2009, 15:16 | #9 |
Участник
|
Кажется общую идею поняла.. Спасибо..
|
|
|
Похожие темы | ||||
Тема | Ответов | |||
Доступ к SQL | 30 | |||
Безопастность. Как ограничить доступ к закладке | 10 | |||
Доступ через Outlook из другой сети | 6 | |||
Доступ к полям сущностей | 2 | |||
Общий доступ на записи | 2 |
|