Особенности выделения прав ответственному за Организацию

[Артем Enot Грунин]

Доброго времени суток, коллеги. Давеча столкнулся с одной неожиданной особенностью системы безопасности CRM (3.0 / 4.0). Оказывается, пользователь ответственный за организацию имеет полный доступ ко всем связанным с ней объектам, даже если они принадлежат пользователям юнитов, про данные которых ему знать не положено.
Поясню: пусть есть 2 юнита, по одному пользователю в каждом. Пусть пользователи обладают одной и той же наследуемой ролью, которая позволяет им видеть и привязывать записи ко всем организациям (ситуация по умолчанию!), а редактировать только те где он ответственный. Так вот оказывается, что если пользователь 1 создаст организацию, а пользователь 2 контакт к ней, то пользователь 1 сможет работать с контактом как с собственным. Например, удалить у контакта "родительского клиента", вследствие чего лишиться возможности его изменять.
Вопрос: это какая-то специальная настройка, которую я прохлопал, опция ролей безопасности, которую я не заметил, или опять ситуация из серии "что курили..."?

Данная особенность проверялась на Контактах и Возможных сделках.
Записей "предоставления доступа" при этом не создается.
Если предоставить доступ самостоятельно, то это ничего не изменит - доступ полный.

[ShurikEv]

Почти тоже самое заметил с Организацией/Контактами и их действиями.
Есть контакт, в отношении которого заведено несколько действий. Даю другому пользователю права на чтение контакта, но тогда он тут же получает права на изменение всех действия, хотя я думал, что тоже будет только на чтение.
Может быть так задумано, но...
Система 3.0

[Артем Enot Грунин]

Выходит все-таки курили... И что, выходит права на запись-родитель делегируются на все дочерние?

[ShurikEv]

Ерунда какая-то... Может АндрейС что ответит?

[Сабитов Андрей]

Щас кинем клич to AndreyS

[AndreyS]

Клич дошел Я просмотрел ситуацию - очекнь похоже, что в данном случае происходит наследование прав (read/write/append). Запросил коллег из поддержки на предмет того, что это - баг или фича Получу ответ - напишу.
Как я попробовал это решить:
Зашел в свойства контакта и нашел связь "account_contacts". Изменил type of behavior на configurable cascading и изменил где только возможно на Cascade None. Опубликовал изменения и проверил. Контакт остался недоступным для редактирования.

[Артем Enot Грунин]

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

[Артем Enot Грунин]

А может и баг... Нашел в курсе по настройке системы:
Права и каскадные правила:
При применении каскадных действий у пользователя должны быть права на выполнение этих действий для всех затрагиваемых связанных объектов. Если таких прав нет, изменение выполнено не будет.
Предположим, что у ответственного за организацию имеются права на удаление этой организации. Но если у него нет необходимых прав на удаление всех существующих связанных объектов, он не сможет удалить эту организацию.
Конец цитаты.
Проверял - могу.

[AndreyS]

Поддержка говорит, что это из-за "особых" отношений между Account и Contact. Наверное, что-то из концепции Account Manager - "я как AM могу делать со своим клиентом все что угодно" .
Так что, похоже, что это баг в курсах Коллеги перенаправили запрос в соответствующую команду.

[Артем Enot Грунин]

Позвольте! Это не баг в курсах, а брешь в системе безопасности! Как говорилось в тех же курсах, существует ряд организации, где с клиентом могут работать несколько менеджеров (и ряд моих заказчиков не исключение). При помощи настройки каскадных правил мы можем отнять у "владельца записи" возможность видеть или изменять "чужое", но от возможности удалить мы его оградить не можем. Нехорошо это...

Андрей, еще раз спасибо за беспокойство.

[IgorF]

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

[Артем Enot Грунин]

Итак вторая найденая брешь... На форму интереса, по требованию руководства, был вынесен стандартный атрибут клиент (системая связь с организацией или контактом). У пользователей есть права на создание интересов (на уровне пользователя) и на их назначение (на уровне пользователя). То есть они могут создавать только свои, после чего назначать только свои интересы. Так вот выясняется, что если указать любую Организацию в поле Клиент, то возможно сразу создавать интерес назначенным любому пользователю. Баг, в общем-то безобидный, но крайне интересный. Похоже что многие системные отношения (с перекрестными ссылками) обладают подобным поведением

[Артем Enot Грунин]

Решил не создавать еще одну тему с названием вроде "система безопасности CRM или что курили разработчики", а продолжить эту... Не судите за флуд, просто в очередной раз наболело, да полезно будет многим узнать про "тонкости и колкости" системы безопасности CRM (опробовано на 3.0, но думаю справедливо будет и для 4.0).

Итак речь в ней в очередной раз об тонкостях виденья и влияния на объекты системы. Рассмотрим типовой пример: в организации есть ряд продающих или просто работающих с заказчиком подразделений. Все они должны хранить историю работы с клиентом, но было бы не предусмотрительно показывать её всем пользователям, ибо информация может быть конфиденциальна. Типовая ситуация - ограничить права на видение действий пределами подразделения. Типовая проблема - как теперь совместно работать? Ибо назначенные пользователям другого подразделения задачи тут же исчезают - перестают быть видимыми? Типовое решение - предоставлять доступ на видение сделки. Так вот этот вопрос я бы и хотел тут обсудить.
И где собственно тонкость? А тонкость в том, что если дать самому себе права на чтение данных возможной сделки, то можно увидеть все связанные с ней действия! Если потом отобрать их, то видимость тех действий, что уже созданы сохранится, а видимость новых будет в соответствии с ролями безопасности.
Что будет если не расшаривать сделку для себя, а только для 2ого менеджера? Он будет видеть все действия, а вы только в соответствии с ролью. Впрочем, если вы будете создавать действия сразу назначенные другим ползователям, то их видимость при этом сохранится.
Почему все это так? Вопрос с одной стороны риторический, с другой могу на него ответить: связь между основным объектом и действиями по умолчанию родительская, а этот тип поведения предусматривает касадное правило "Каскад для всех" на операцию "Общий доступ" (даже, если вы не видите все объекты к которым он применится). Таким образом вы можете использовать этот приём, в тех случаях, когда важно, чтобы создатель был "вторым владельцем".

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

Всем кто не сломал моск, удачи!