Кастомизация
05
Окт
17

Управление уровнем доступа к полям

Одной из наиболее запрашиваемых (как грят: самому сталкиваться не приходилось) возможностей CRM является управление уровнем доступа к полям (атрибутам). В стандартном функционал MS CRM 4.0 такой возможности нет. Но видимо это настолько важная тема, что MS выпустила специальный документ по этому поводу, где рассказывается, как такой функционал можно реализовать поддерживаемым способом с помощью дополнительных компонентов: Field-level Security in Microsoft Dynamics CRM: Options and Constraints.

Посему рассмотрим работу плагина XRM Field-Level Security Plugin который и реализует эту самую возможность в MS CRM.

Возможности плагина:

  • Все будут иметь полный доступ в CRM по умолчанию, пока Вы не определите атрибуты к которым необходимо ограничить доступ;
  • Правами доступа настраиваются на уровне ролей;
  • Предоставляются три вида прав доступа:
    • Нет доступа;
    • Только для чтения;
    • Чтение и создание.

Установка:

  • Скачайте и распакуйте архив XRM Field-Level Security Plugin (Вам понадобится либо 32-, либо 64-битная версия);
  • Зарегистрируйте PSXrmDevLib.dll в GAC’е. Для этого:
    • Скачайте и установите оснастку Microsoft .NET Framework 2.0 Configuration Tool (если она еще у Вас не установлена);
    • Откройте Microsoft .NET Framework 2.0 Configuration Tool: перейдите Start – Control Panel – Administrative Tools – Microsoft .NET Framework 2.0 Configuration;
    • Далее щелкните правой кнопкой мыши по Assembly Cache, выберите Add… и укажите сборку PSXrmDevLib.dll (32- или 64-битную).



  • Импортируйте psx_accessrights.xml в CRM — откройте объект в разделе настроек — выставьте для него отображение в каком-либо разделе (например Настройка) — опубликуйте его;


  • Запустите Plug-in Registration Tool и зарегистрируйте в нем сборку PSXrmPlugins.AccessRights.dll. Для нее следующие шаги с такими параметрами:
    • Два шага для Execute Message:
      • Message: Execute;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Pre Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.
        и
      • Message: Execute;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Post Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.
    • Один шаг для Create Message:
      • Message: Create;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Pre Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.
    • Один шаг для Update Message:
      • Message: Update;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Pre Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.
    • Два шага для Retrieve Message:
      • Message: Retrieve;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Pre Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.
        и
      • Message: Retrieve;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Post Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.
    • Два шага для Retrieve Multiple Message:
      • Message: RetrieveMultiple;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Pre Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.
        и
      • Message: RetrieveMultiple;
      • Primary Entity: none;
      • Eventing Pipeline Stage of Execution: Post Stage;
      • Execution Mode: Synchronous;
      • Step Deployment: Server и Offline;
      • Triggering Pipeline: Parent Pipeline.


  • Выдайте парава на Создание и Чтение объекта psx_accessrights для всех ролей, которые имеют доступ к объекту для которого будут настраиваться уровень доступа полей;
  • Осталось настройить парава доступа для полей:
    • Перйдите к объекту Access Rights и создайте новую запись этого объекта;
    • Задайте для нее такие параметры:
      • Роль;
      • Уровень доступа;
      • Объект, в котором необходио ограничить доступ к полям;
      • Само поле, для которого редактируется уровень доступа.


  • Тестируем: создайте запись объекта, для которого настроили доступ (под админом) и заполните поле, к которому ограничили доступ. Далее зайдите в CRM под учеткой для которой настроили уровень доступа (т.е. у которой есть роль, определнная в записи psx_accessrights) ну и откройте карточку созданную под админом. Поле, на которое наложен запрет, будет пустым!



З.Ы. Сорсы сможете найти внутри архива 🙂

Комментарии (17)
  • DD 05.10.2010

    Полезно!

  • Konstantyn 05.10.2010

    Вопрос. А можно ли как то с момощью данного плагина ограничить доступ на пиклисты? Например: чтобы под одной ролью виделись одны значения пиклиста, а под другой — другие? Или это нужно решать каким-то другим способом?

  • slivka_83 05.10.2010

    Нет, этот плагин не предназначен дляэтого. Я бы реализовал это с помщью скрипта: на онлоаде запрашивал роль текущего юзвера и в зависимости от нее удалял не нужные значения из пиклиста (только вот что делать, если в пиклисте выбрано значение, которое нужно удалить…).

  • Igor 05.10.2010

    Может доступ нужно выдать всем ролям на чтение и запись psx_accessrights, независимо от настраиваемого объекта?

  • slivka_83 05.10.2010

    Точно уже не помню 🙂 это служебный оъект и никакой смысловой нагрузки не несет. Можете выдать всем ролям, но уберите его из сайтмапа и снимите галку «доступен для расширенного поиска» — думаю проблем возникнуть не должно 🙂

  • briscard 05.10.2010

    Установил сабж. Начал проверять и обнаружил, что у всех пользователей (попробовал у двоих), кроме админа CRM перестал вообще открываться. Пишет: «Запрошенный доступ к реестру запрещен».

    кто-нибудь знает: в чем может быть дело?

  • slivka_83 05.10.2010

    Попробуйте зарегить шаги плагина на Админа CRM.

  • briscard 05.10.2010

    спасибо за желание помочь!
    если речь идет о Plug-in Registration Tool (как описано выше), то все шаги зарегистрировал при установке. На админа или не на админа — понять не могу: там нет поля «на кого» (не видел по крайней мере). Или это где-то в другом месте надо зарегистрировать еще? Чего-то я не понимаю 🙁

  • briscard 05.10.2010

    ага, кажется нашел где я облажался. сейчас проверю и отпишусь. может кому пригодится

  • Igor 05.10.2010

    Вот как раз и требуется дать права всем пользователям на чтение и запись psx_accessrights

  • briscard 05.10.2010

    это был мой прокол — не дал пользователям права. только когда дал на «чтение» и «запись» все равно ничего не изменилось, а изменилоось — когда дал права на «создание» и «чтение»: как на картинке сверху (а не как написано)

  • slivka_83 05.10.2010

    Спасибо 🙂 поправил 🙂

  • briscard 05.10.2010

    Плагин работает, но как оказалось, не так как нам нужно.

    Моя задача: сотрудники подразделения А не должны видеть контактную информацию клиентов подразделения Б. При этом остальные поля клиентов подразделения Б им должны быть доступны. При помощи данного плагина я закрыл доступ сотрудникам подразделения А к контактам клиентов Б, но получается, что теперь сотрудники А не могут и у своих клиентов видеть контактную информацию. То есть плагин закрывает доступ к данному полю напрочь, в том числе и доступ сотрудников подразделения А к контактной информации собственных клиентов.

    Может кто-нибудь подсказать: что делать?
    Спасибо!

  • slivka_83 05.10.2010

    > При помощи данного плагина я закрыл доступ сотрудникам подразделения А к контактам клиентов Б, но получается, что теперь сотрудники А не могут и у своих клиентов видеть контактную информацию.

    Противориечивое утверждение 🙂 Это раз 🙂
    Во-вторых плагин закрывает доступ не для подразделений а для Ролей 🙂 соответственно если сотрудникам обоих подразделений назначена одна и та же роль, то управляться доступ для них бедут одинаково 🙂 Вообщем «разнесите» этих сотрудников по разным ролям 🙂

  • briscard 05.10.2010

    Что касается подразделений и ролей, то, конечно, я назначил соотрудникам разных подразделений разные роли и таким именно образом ограничивал доступ 🙂
    А вот в чем противоречивость — не понимаю? Задача стояла так: сотрудник из подразделения «А» должен видеть все поля карточки потенциального клиента (объект интересы) принадлежащего подразделению Б, за исключением некоторых, например — за исключением поля «Служебный телефон». При этом все поля своих потенциальных клиентов ему должны быть доступны каак для записи так и для чтения.
    На данный момент я вижу два способа решения:
    1. создать для каждого подразделения разные атрибуты «служебный телефон» и др. и при помощи сабжа ограничить доступ к этом полям «несвоих» сотрудников. Это вариант явно кривой и некрасивый (в форме и в представлении будут избыточные для каждого поля), но работать, полагаю будет
    2. Создать три объекта типа «Потенциальный клиент»: для подразделения А, для подразделения Б и общий. В общем объекте будут через воркфлоу создаваться записи только открытых для всех полей, а частные объекты (А и Б) будут доступны только с рамках своих подразделений (это можно организовать через роли) Это — более красивое с точки зрения сотрудников решение, но более затратное и менее предсказуемое ( в смысле больше вероятность моей ошибки и ее оследствий).
    Есть какие-то другие решения?

  • briscard 05.10.2010

    я понял в чем Вы увидели противоречивость: я употребил слово «контакты», имея в виду не объект «контакты», а поля с контактной информацией в ообъекте «Интересы». Закрыть доступ к объекту «контакты» несвоего подразделения, конечно, можно стандартным функционалом, но мне как раз нужно скрыть информацию отдельных полей из объекта «интересы» и из объекта «бизнес-партнеры». Зачем это нужно не спрашивайте: просто таков приказ директора 🙂

  • slivka_83 05.10.2010

    > Есть какие-то другие решения?
    Ну можно нарисовать плагин или JavaScript, которы будет скрывать поля в зависимости от того, к какому подразделению принадлежит пользователь.

*

code