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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.01.2012, 15:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,644 / 848 (80) +++++++
Регистрация: 28.10.2006
axforum blogs: Разбираемся с лентой (Ribbon)
Источник: http://axforum.info/forums/blog.php?b=310
==============

На просторах Инета достаточно много описаний, как вставить кастомную кнопку на ленту. Вот, например, несколько ссылок:
http://gtcrm.wordpress.com/2011/01/1...-in-crm-2011-3
http://blog.tallan.com/2011/06/24/mi...rom-the-ribbon
http://dynamicscrm2011.wordpress.com...-customization

Ниже речь пойдет о расширенном функционале, позволяющем не только вставить кнопку (или любой другой разрешенный элемент) на ленту, но и «оживить» ее: определив дополнительные правила, когда эта кнопка видна, когда скрыта или когда запрещено нажатие. Детальное описание поведения ленты можно подчерпнуть из библиотеки MSDN, зайдя в раздел Ribbon XML Refference. Описание ниже – для ленивых :)

Итак, предположим, что определение кастомной кнопки либо другого какого интерфейсного элемента на ленте уже задано в файле customizations.xml.
Все наши правки файла customizations.xml будут затрагивать раздел — корневой узел для всех кастомных элементов. Он содержит 5 вложенных разделов:
  • Содержит коллекцию действий, которые добавляют, изменяют или удаляют элементы на ленте
  • Содержит коллекцию шаблонов размещения элементов на ленте
  • Содержит коллекцию команд и объявлений правил поведения элементов на ленте
  • Содержит коллекцию определений правил поведения элементов на ленте
  • Содержит коллекцию локализованных названий элементов ленты
Понятно, что коллекция представляет собой набор элементов с такими же именами, что и имя коллекции, но без окончания ‘s’. Т.е. коллекция имеет набор элементов , а коллекция — набор элементов и т.д. Чтобы различать элементы в коллекции, необходимо задать уникальный идентификатор для каждого элемента. Делается это для всех коллекций одинаково:
X++:

Стоит также прислушаться к рекомендациям Microsoft об именовании идентификаторов. Соглашение об именовании MSDN требует использовать следующее правило:

X++:
[solution identifier].[entity].[ribbon].[function].[element name]
Получится что-то вроде этого:

X++:

Общее правило редактирования описания ленты в файле customizations.xml звучит следующим образом: опиши ВСЕ необходимые правила в разделе , затем в разделе укажи, КАКИЕ ПРАВИЛА ДЛЯ КАКИХ ЭЛЕМЕНТОВ ленты должны применяться. Чтобы правило в привязать к команде в , используется уникальный идентификатор правила.

Таким образом, для каждого элемента на ленте мы можем задать несколько правил видимости / доступности и несколько действий (actions). А чтобы различать эти плавила и действия –используются уникальные идентификаторы (не путать с идентификаторами самих элементов на ленте!).

Что нам нужно для элементов на ленте?
  1. Чтобы они были видимыми или скрытыми в зависимости от нашей логики.
  2. Чтобы они были видимыми, но либо доступными, либо запрещенными для использования в зависимости, опять же, от нашего желания.
  3. Чтобы они (при взаимодействии с ними) запускали на выполнение некий пользовательский код.
За каждое из трех желаний отвечает свой собственный раздел в и в :
  • Определяет доступность элементов для взаимодействия
  • Определяет видимость элементов
  • Определяет запускаемые сценарии, команды Outlook или открываемые url
Для каждого элемента коллекции нам нужно будет написать такой код:

X++:

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

Группы правил и

Синтаксис описания групп правил идентичен:

X++:
… …

X++:
… …
Полный список правил приведен ниже.

Правило / Раздел
CrmClientTypeRule + +
CrmOfflineAccessStateRule + +
CrmOutlookClientTypeRule + +
CrmOutlookClientVersionRule – +
CustomRule + –
EntityPrivilegeRule – +
EntityPropertyRule – +
EntityRule + +
FormEntityContextRule – +
FormStateRule + +
MiscellaneousPrivilegeRule – +
OrganizationSettingRule – +
OrRule + +
OutlookItemTrackingRule + –
OutlookRenderTypeRule – +
OutlookVersionRule + +
PageRule + +
RecordPrivilegeRule + –
ReferencingAttributeRequiredRule – +
RelationshipTypeRule – +
SelectionCountRule + –
SkuRule + +
ValueRule + +

Детальное описание того, как и какие правила можно определять, содержится в библиотеке MSDN. Рассмотрим только несколько наиболее привлекательных.

(применимо только в )

Задает вызов функции JavaScript из библиотеки функций. Должны быть обязательно указаны имя функции и имя библиотеки.
CRM самостоятельно производит вызов функции, указанной в , в следующих случаях:
  • при открытии формы;
  • при сохранении формы (без закрытия);
  • при возврате на вкладку, где присутствует кастомный элемент, с другой вкладки формы.
Функция должна возвращать булево значение true (1) или false (0), определяющее состояние элемента: элемент разрешен или запрещен.

Описание правила можно расширить несколькими опциональными полезными вещами.
  1. Атрибутом Default. Задает значение по умолчанию. Если функция FunctionName, указанная в правиле, еще не вызвана, то будет использоваться значение Default: true или false.
  2. Атрибутом InvertResult. Инвертирует значение, возвращаемое функцией FunctionName. Т.е., если FunctionName возвращает true, то элемент на ленте будет запрещен (disable).
Пример:
X++:

Для определения состояния элемента на ленте вызывается функция Gl.Quote.ApprovalCommand из библиотеки Gl_Quote_Library пользовательского JavaScript кода.
Возвращаемое функцией булево значение инвертируется (потому что InvertResult="1").
До момента первого вызова функции или при ошибке вызова функции элемент считается разрешенным (потому что Default="true").
Примечание:
  1. Если по каким-либо причинам CRM не сможет вызвать функцию, указанную в , то для определения состояния кастомного элемента будет использовано значение Default.
  2. CRM производит успешный вызов функции FunctionName даже если сам ресурс Library не прикреплен к форме (что для меня странно). С целью избегания недоразумений рекомендуется все же указывать в свойствах формы библиотеку с кодом функции, которая должна загружаться вместе с формой.
  3. Если элемент невидим, то вызов функции FunctionName не производится.
  4. В функцию FunctionName можно передать параметры, указанные с помощью атрибутов BoolParameter, CrmParameter, DecimalParameter, StringParameter.


Задает состояние элемента в зависимости от состояния формы. Должно быть обязательно указано состояние формы State, при котором элемент на ленте будет разрешен/видим или запрещен/невидим.

Опциональный атрибут Default определяет состояние элемента в случае, когда состояние формы определить не удается (даже не представляю, когда такое может быть).
Опциональный атрибут InvertResult=«1» инвертирует результат применения правила.

Вы можете указать следующие состояния формы, на которые будет реагировать элемент:
  • Create Состояние новой записи до ее первого сохранения
  • Existing Состояние после сохранения записи, когда пользователь может редактировать данные
  • ReadOnly Состояние, когда данные доступны только для чтения
  • Disabled Состояние неактивной формы (записи), когда данные нельзя редактировать
  • BulkEdit Режим группового редактирования записей
Пример:
X++:

Элемент на ленте будет разрешен/видим для всех состояний формы, кроме Create (т.е. после того, как новая запись будет сохранена).



Задает состояние элемента в зависимости от значения поля на форме. Должны быть обязательно указаны имя поля и отслеживаемое значение.

Правило звучит следующим образом: задать состояние элемента, как только в указанном поле будет установлено указанное значение и запись будет сохранена.

Как и прежде, атрибут InvertResult инвертирует действие правила. Это означает, что если мы хотим, чтобы элемент на ленте был разрешен/видим во всех случаях, кроме случая, когда в поле Field присутствует значение Value, то мы должны использовать InvertResult=«true».
Опциональный атрибут Default определяет состояние элемента в том случае, когда значение поля не определено, т.е. отсутствует (null).

Пример:
X++:

Разрешить/показать элемент, когда в наборе параметров PriceCode будет выбрана строка, имеющая значение 2.
Вы можете использовать строковое поле или числовое поле, а не только набор параметров.
Заметьте, что правило сработает не тогда, когда вы введете ключевое значение в отслеживаемое поле (и покинете его), а только после сохранения записи.

(применимо только в )

Задает видимость или невидимость элемента в зависимости от свойств сущности.
В правиле должны быть обязательно указаны:
  • проверяемое свойство сущности PropertyName.
  • какой тип булевого значения PropertyValue должен возвращаться (true или false), если свойство, указанное в PropertyName, имеет место быть.
Правило звучит следующим образом: показать (если правило вернет true) или скрыть (если правило вернет false) элемент на ленте, если сущность обладает указанным свойством.

Необходимо использовать AppliesTo=”PrimaryEntity” для элементов на главной ленте формы сущности и AppliesTo=”SelectedEntity” для элементов на ленте грида; причем будут проверяться свойства не самой сущности, содержащей грид, а свойства выбранных сущностей в гриде.

Соответственно, применение в правиле опционального атрибута EntityName уместно для случая, когда AppliesTo=”SelectedEntity”, и грид может содержать разные типы сущностей (например, разные Activities).
Как и раньше, опциональные атрибуты Default и InvertResult определяют значение по умолчанию и требование инвертирования результата применения правила.

С помощью правила можно контролировать наличие следующих свойств у сущности:
  • DuplicateDetectionEnabled Для сущности разрешен поиск дубликатов
  • GridFiltersEnabled Разрешена фильтрация в гриде
  • HasStateCode Сущность имеет поле statecode
  • IsConnectionsEnabled Для экземпляров сущности разрешено связывание
  • MailMergeEnabled Сущность поддерживает MailMerge (генерацию документов на основе шаблонов)
  • WorksWithQueue Сущность поддерживает работу с очередью (экземпляр сущности можно включать в очередь)
  • HasActivities К сущности могут быть привязаны Действия (т.е. форма сущности имеет вкладки Действия / Закрытые действия или подобные)
  • IsActivity Сущность определена как Действие
  • HasNotes В сущность можно добавлять примечания
  • IsCustomizable Сущность может настраиваться
Заметьте, что здесь речь идет не о конкретном экземпляре сущности (записи), а о свойствах сущности как типе объекта. Т.е. проверка свойства HasNotes вернет true для сущности, в которую можно добавлять примечания, независимо от того, есть ли у конкретной записи в настоящий момент примечания или нет.

Пример:
X++:

Показать элемент на ленте формы, если сущность может быть связана с Действиями (т.е. Действие может ссылаться на сущность в поле В отношении).

(применимо только в )

Задает видимость или невидимость элемента в зависимости от полномочий пользователя по отношению к заданной сущности.

В правиле должны быть обязательно указаны:
  • привилегии уровня записи PrivilegeType (т.е. операции, которые разрешены с записью): Create, Read, Write, Delete, Assign, Share, Append, AppendTo (не расшифровываю — и так понятно).
  • уровень доступа к записи PrivilegeDepth: None (нет), Basic (пользователь), Local (подразделение), Deep (головное и все дочерние подразделения), Global (организация).
Правило звучит следующим образом: показать / скрыть элемент на ленте, если пользователь обладает указанными привилегиями и уровнем доступа.

Как и раньше, Default задает состояние элемента по умолчанию, когда невозможно определить обязательные параметры правила (привилегии и уровень доступа), а InvertValue инвертирует значения указанных параметров (привилегии и уровень доступа наоборот).

Опционально можно указать логическое имя сущности, к которой будет применяться это правило, в атрибуте EntityName.

Также можно указать, к какому типу записей данное правило относится: к главной форме или к записям в гриде. В первом случае используем AppliesTo=«PrimaryEntity», во втором — AppliesTo=«SelectedEntity».

Пример:
X++:

Показать элемент, если пользователь имеет привилегии на уровне подразделения и имеет право редактировать запись.


Источник: http://axforum.info/forums/blog.php?b=310
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Microsoft Dynamics CRM Team Blog: CRM 2011 Chart Enhancements Blog bot Dynamics CRM: Blogs 0 25.01.2012 10:11
DynamicsAxSCM: Visualizing Security in Microsoft Dynamics AX 2012 Blog bot DAX Blogs 0 29.08.2011 13:11
crminthefield: How to Create a Silverlight Web Resource that Interacts with CRM 2011 Forms Blog bot Dynamics CRM: Blogs 0 24.06.2011 04:17
Microsoft Dynamics CRM Team Blog: Welcome to the World of Dialogs - Part 1 Blog bot Dynamics CRM: Blogs 0 02.02.2011 21:11
DynamicsAxSCM: Personalization of Role Centers in Dynamics AX 2009 Blog bot DAX Blogs 0 21.06.2010 16:05

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 22:33.