В очереди за идиотизмом

Текущая версия системы, как мы знаем, не блещет своими средствами командной работы. Если на чистоту, то средства равно два: передача доступа и списки ожидания. Первый позволяет каким-либо образом обойти драконовскю систему безопасности, хотя и неудобен. Второй представляет собой средство чуть более похожее на механизм командной работы, но имеет значительно больше ограничений: например, в список можно поместить объекты далеко не всех типов. Вот вам интересный факт: в SDK есть перечисление OwnershipTypes, которое включает, такие пункты как: BusinessOwned (Not supported), BusinessParented (Not supported), None, OrgOwned, TeamOwned (Not supported), UserOwned. Судя по всему, запрещенные типы владения будут разрешены в пятой версии системы. Сейчас же приходится довольствоваться ограниченным функционалом списков.

Итак, как это работает? Администратор регистрирует в системе новый Список ожидания - объект типа Queue. Беда в том, что область видимости этого объекта может быть только Global: или вы видите все списки, либо ничего. Гораздо хуже тот факт, что строки этого списка (Queue Item) так же являются "объектами организации". Иными словами чтобы дать пользователю возможность видеть элементы одного из списков вы вынуждены дать ему возможность видеть все элементы всех списков.

Следующий момент. За назначение списку (помещение в список) ответственно отдельное событие "Route", а не "Assign" как в случае с назначением пользователю. При этом список не может быть "ответственным" за помещаемые в него записи. При назначении объекта списку, исходный владелец объекта не меняется, однако в списке создается лишь некий ярлык - QueueItem, по которому можно найти исходный объект.

Список ожидания может быть связан с некоторым адресом электронной почты. Классические примеры - публичные почтовые адреса организации вида: sales@orgname.org или support@orgname.org, почту в которых предполагается обрабатывать сообща. В отличие от объектов Подразделение, Место или Оборудование, электронная почта Списков ожидания несет в себе функционал: она может отслеживаться Роутером по тому же принципу что и почта пользователей системы. Здесь же может крыться и некоторая хитрость: при отслеживании почты, роутер сопоставляет только ту почту, которая отправлена на адрес пользователя или очереди. Иными словами, наличие письма в ящике еще не гарантия того, что письмо будет отслежено Роутером. В том случае, если письмо придет на адрес списка рассылки Exchange (sales@orgname.org), пользователь (user@orgname.org) получит письмо, но при этом не будет его адресатом, и отслеживание работать не будет! Имейте это в виду, если в вашей организации роль публичного почтового адреса выполняет список рассылки. Для того чтобы отслеживание заработало, вам придется создать для очереди отдельный почтовый ящик, например, sales_queue@orgname.org, но не включать его в список рассылки, а развернуть серверное правило, которое будет пересылать входящую почту списка на этот адрес (желательно использовать Redirect а не Forward!). Если в организации по прежнему используется Exchange 2003, то возможности применить правило к списку у вас не будет. Тем не менее, существует обходной маневр:
1. Включите ящик очереди в список рассылки.
2. Разверните на нем правило которое:
1) Проверяет что письмо пришло на адрес списка
2) Перенаправляет письмо непосредственно на адрес ящика
3) Удаляет исходное письмо. Порно, зато задорно!
3. Если для сбора писем Роутер использует Forward mail box, смело разворачивайте стандартное правило маршрутизации при помощи Rule Deployment Wizard. Первое попадание письма в ящик будет им проигнорировано, а второе отработает как надо. Отслеживание будет работать.

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

В Список можно поместить не все записи, а толь только записи следующих типов:
activity
activitymimeattachment
activityparty
appointment
bulkoperation
calendar
campaignactivity
campaignresponse
email
fax
incident
incidentresolution
letter
opportunityclose
orderclose
phonecall
quoteclose
service
serviceappointment
task
Иными словами только Действия и Обращения.

За каждым пользователем в системе закреплены два особых персональных Списка ожидания: "Назначенные", куда попадают все объекты перечисленных выше типов, если назначить их пользователю, и "Выполняется", куда попадают все элементы списков, которые он принимает из других списков, или просто создает сам. Назначение этих двух списков не совсем понятно. Единственное применение, которое я вижу - при помощи очереди "Назначенные" отслеживать те действия которые пытаются на вас повесить (чтобы не искать их в списке "Мои действия"), и в случае несогласия возвращать их обратно.

Вот теперь, когда мы разобрались с тем как и откуда данные попадают в список, возникает важный момент: как же забрать их оттуда? А вот тут и возникает интересный момент! Для того чтобы выполнить событие "Handle" (назначить себе объект списка, а так же связанный с ним объект) мы должны обладать следующим набором привилегий:
prvAssignActivity
prvDeleteQueueItem
prvReadActivity
prvReadQueueItem
prvWriteQueueItem
QueueItems мы видим, читаем и даже удаляем все что только есть на свете, так как уровень доступа к ним может быть только Global, а вот что насчет, действий, например? А вот тут облом: если Действие принадлежит пользователю, чьи Действия мы назначать себе не можем, то и объект из очереди мы забрать не сможем. Занавес. Единственный выход который я вижу: это попытаться сделать pre plugin к событию Handle в котором выдавать права на запись тому несчастному, который пытается ее себе назначить. К счастью, Microsoft осведомлена об этой проблеме, и Функционал списков подвергнется существенной модернизации в CRM 5.0. Сейчас же придется довольствоваться тем что есть.