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