AXForum  
Вернуться   AXForum > Microsoft Dynamics CRM > Dynamics CRM: Прочие вопросы
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.06.2008, 17:01   #1  
Артем Enot Грунин is offline
Артем Enot Грунин
Moderator
Аватар для Артем Enot Грунин
MCBMSS
Злыдни
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,912 / 623 (28) +++++++
Регистрация: 16.08.2007
Адрес: Пермь!
Записей в блоге: 151
Особенности выделения прав ответственному за Организацию
Доброго времени суток, коллеги. Давеча столкнулся с одной неожиданной особенностью системы безопасности CRM (3.0 / 4.0). Оказывается, пользователь ответственный за организацию имеет полный доступ ко всем связанным с ней объектам, даже если они принадлежат пользователям юнитов, про данные которых ему знать не положено.
Поясню: пусть есть 2 юнита, по одному пользователю в каждом. Пусть пользователи обладают одной и той же наследуемой ролью, которая позволяет им видеть и привязывать записи ко всем организациям (ситуация по умолчанию!), а редактировать только те где он ответственный. Так вот оказывается, что если пользователь 1 создаст организацию, а пользователь 2 контакт к ней, то пользователь 1 сможет работать с контактом как с собственным. Например, удалить у контакта "родительского клиента", вследствие чего лишиться возможности его изменять.
Вопрос: это какая-то специальная настройка, которую я прохлопал, опция ролей безопасности, которую я не заметил, или опять ситуация из серии "что курили..."?

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

MS Certified Dirty Magic Professional

Последний раз редактировалось Артем Enot Грунин; 10.06.2008 в 17:03.
Старый 11.06.2008, 06:24   #2  
ShurikEv is offline
ShurikEv
CRM
 
213 / 28 (1) +++
Регистрация: 25.04.2006
Адрес: г. Новосибирск
Почти тоже самое заметил с Организацией/Контактами и их действиями.
Есть контакт, в отношении которого заведено несколько действий. Даю другому пользователю права на чтение контакта, но тогда он тут же получает права на изменение всех действия, хотя я думал, что тоже будет только на чтение.
Может быть так задумано, но...
Система 3.0
__________________
MS CRM 3.0/4.0
Sharepoint 2003, MOSS 2007/2010
Старый 11.06.2008, 10:20   #3  
Артем Enot Грунин is offline
Артем Enot Грунин
Moderator
Аватар для Артем Enot Грунин
MCBMSS
Злыдни
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,912 / 623 (28) +++++++
Регистрация: 16.08.2007
Адрес: Пермь!
Записей в блоге: 151
Выходит все-таки курили... И что, выходит права на запись-родитель делегируются на все дочерние?
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия.

MS Certified Dirty Magic Professional
Старый 11.06.2008, 11:20   #4  
ShurikEv is offline
ShurikEv
CRM
 
213 / 28 (1) +++
Регистрация: 25.04.2006
Адрес: г. Новосибирск
Ерунда какая-то... Может АндрейС что ответит?
__________________
MS CRM 3.0/4.0
Sharepoint 2003, MOSS 2007/2010
Старый 11.06.2008, 12:36   #5  
Сабитов Андрей is offline
Сабитов Андрей
MCTS
Аватар для Сабитов Андрей
MCBMSS
Лучший по профессии 2009
 
851 / 122 (6) +++++
Регистрация: 07.09.2006
Адрес: СПб
Щас кинем клич to AndreyS
За это сообщение автора поблагодарили: Артем Enot Грунин (1).
Старый 11.06.2008, 14:51   #6  
AndreyS is offline
AndreyS
Moderator
Сотрудники Microsoft Dynamics
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
283 / 61 (3) ++++
Регистрация: 18.05.2006
Клич дошел Я просмотрел ситуацию - очекнь похоже, что в данном случае происходит наследование прав (read/write/append). Запросил коллег из поддержки на предмет того, что это - баг или фича Получу ответ - напишу.
Как я попробовал это решить:
Зашел в свойства контакта и нашел связь "account_contacts". Изменил type of behavior на configurable cascading и изменил где только возможно на Cascade None. Опубликовал изменения и проверил. Контакт остался недоступным для редактирования.
За это сообщение автора поблагодарили: Сабитов Андрей (1), Артем Enot Грунин (2).
Старый 11.06.2008, 15:10   #7  
Артем Enot Грунин is offline
Артем Enot Грунин
Moderator
Аватар для Артем Enot Грунин
MCBMSS
Злыдни
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,912 / 623 (28) +++++++
Регистрация: 16.08.2007
Адрес: Пермь!
Записей в блоге: 151
Не подумал об этой настройке. По умолчанию организация - родитель контактов, а данный тип поведения провоцирует каскадирование всех операций. Похоже это фитча, а не баг. AndreyS, спасибо.
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия.

MS Certified Dirty Magic Professional
За это сообщение автора поблагодарили: Сабитов Андрей (1).
Старый 11.06.2008, 15:38   #8  
Артем Enot Грунин is offline
Артем Enot Грунин
Moderator
Аватар для Артем Enot Грунин
MCBMSS
Злыдни
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,912 / 623 (28) +++++++
Регистрация: 16.08.2007
Адрес: Пермь!
Записей в блоге: 151
А может и баг... Нашел в курсе по настройке системы:
Права и каскадные правила:
При применении каскадных действий у пользователя должны быть права на выполнение этих действий для всех затрагиваемых связанных объектов. Если таких прав нет, изменение выполнено не будет.
Предположим, что у ответственного за организацию имеются права на удаление этой организации. Но если у него нет необходимых прав на удаление всех существующих связанных объектов, он не сможет удалить эту организацию.
Конец цитаты.
Проверял - могу.
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия.

MS Certified Dirty Magic Professional
Старый 19.06.2008, 15:32   #9  
AndreyS is offline
AndreyS
Moderator
Сотрудники Microsoft Dynamics
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
283 / 61 (3) ++++
Регистрация: 18.05.2006
Поддержка говорит, что это из-за "особых" отношений между Account и Contact. Наверное, что-то из концепции Account Manager - "я как AM могу делать со своим клиентом все что угодно" .
Так что, похоже, что это баг в курсах Коллеги перенаправили запрос в соответствующую команду.
Старый 19.06.2008, 17:30   #10  
Артем Enot Грунин is offline
Артем Enot Грунин
Moderator
Аватар для Артем Enot Грунин
MCBMSS
Злыдни
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,912 / 623 (28) +++++++
Регистрация: 16.08.2007
Адрес: Пермь!
Записей в блоге: 151
Позвольте! Это не баг в курсах, а брешь в системе безопасности! Как говорилось в тех же курсах, существует ряд организации, где с клиентом могут работать несколько менеджеров (и ряд моих заказчиков не исключение). При помощи настройки каскадных правил мы можем отнять у "владельца записи" возможность видеть или изменять "чужое", но от возможности удалить мы его оградить не можем. Нехорошо это...

Андрей, еще раз спасибо за беспокойство.
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия.

MS Certified Dirty Magic Professional
Старый 24.06.2008, 10:54   #11  
IgorF is offline
IgorF
Учаснег
Аватар для IgorF
Ex AND Project
Лучший по профессии 2011
Лучший по профессии 2009
 
307 / 37 (2) +++
Регистрация: 23.07.2007
Адрес: Поребрик сити
столкнулись с этой проблемой год назад, видимость Клиента в базе в разрезе всей организации и дочерних. Выход был следующим, назначили все организации Администратору системы, так и работает до сих пор... Правилами можно разрулить автоматическое назначение вновь созданной организации....
Старый 24.10.2008, 13:25   #12  
Артем Enot Грунин is offline
Артем Enot Грунин
Moderator
Аватар для Артем Enot Грунин
MCBMSS
Злыдни
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,912 / 623 (28) +++++++
Регистрация: 16.08.2007
Адрес: Пермь!
Записей в блоге: 151
Итак вторая найденая брешь... На форму интереса, по требованию руководства, был вынесен стандартный атрибут клиент (системая связь с организацией или контактом). У пользователей есть права на создание интересов (на уровне пользователя) и на их назначение (на уровне пользователя). То есть они могут создавать только свои, после чего назначать только свои интересы. Так вот выясняется, что если указать любую Организацию в поле Клиент, то возможно сразу создавать интерес назначенным любому пользователю. Баг, в общем-то безобидный, но крайне интересный. Похоже что многие системные отношения (с перекрестными ссылками) обладают подобным поведением
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия.

MS Certified Dirty Magic Professional
Старый 27.10.2008, 08:13   #13  
Артем Enot Грунин is offline
Артем Enot Грунин
Moderator
Аватар для Артем Enot Грунин
MCBMSS
Злыдни
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,912 / 623 (28) +++++++
Регистрация: 16.08.2007
Адрес: Пермь!
Записей в блоге: 151
Решил не создавать еще одну тему с названием вроде "система безопасности CRM или что курили разработчики", а продолжить эту... Не судите за флуд, просто в очередной раз наболело, да полезно будет многим узнать про "тонкости и колкости" системы безопасности CRM (опробовано на 3.0, но думаю справедливо будет и для 4.0).

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

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

Всем кто не сломал моск, удачи!
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия.

MS Certified Dirty Magic Professional
За это сообщение автора поблагодарили: AlekseyS (1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Грид с фильтром по ответственному. IgorF Dynamics CRM: Разработка 7 28.05.2008 15:15
"У вас нет необходимых прав для применения фильтра к отчету" zhenek Dynamics CRM: Разработка 7 02.04.2008 12:26
Недокументированные особенности MS CRM 3.0 )) Jabberwocky Dynamics CRM: Администрирование 0 05.07.2007 10:53
Проблемы с назначением прав доступа. uaslava Dynamics CRM: Администрирование 0 20.03.2007 16:25
У админа нет прав. Senturion Dynamics CRM: Администрирование 3 15.11.2006 16:19

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 09:23.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.