Завершение настройки карточки

Теперь перейдём на вкладку “Карточки” и закончим разработку типа карточки AbDocument.

Дополнительные контролы

Добавим контрол с заголовком “Partner” типа Ссылка для ссылки на контрагента из стандартного справочника контрагентов. Связываем его с полем карточки AbDocuments.Partner, указываем Алиас представления: Partners, Алиас параметра: Name (т.е. стандартное представление со списком контрагентов). Остальные свойства будут иметь значения по умолчанию.

И добавим строковый контрол Subject типа Строка для ввода темы документа. Связываем его с колонкой AbDocuments: Subject. В этот контрол может быть введён большой объём текста (тип колонки String(Max), т.е. может быть больше 4000 символов), поэтому он должен растягиваться на ширину всех колонок (флаг Растянуть по ширине). Также укажем минимальное и максимальное количество строк: Минимум строк: 3 и Максимум строк: 6.

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

Валидаторы для обязательных полей

Валидатор определяет, что конкретное поле карточки является обязательным (или подходит под другое условие, определяемое типом валидатора, например, числовое поле является положительным). Преимущество задания ограничений через валидаторы в том, что все контролы, связанные с этим полем через свойство Card fields, будут оповещать пользователя о необходимости заполнения этого поля. Кроме того, даже при отсутствии таких контролов проверка условий по полям с валидаторами всё равно будет выполняться при сохранении карточки. Таким образом, значение поля может вычисляться в расширениях и отображаться пользователю в другой форме, а проверка при сохранении будет выполняться именно для этого поля.

Создание валидатора выполняется через контекстное меню на узле “Валидаторы”, который вложен в узел с типом карточки.

В этой версии платформы существует три типа валидаторов:

• Непустая секция определяет, что коллекционная или древовидная секция содержит хотя бы одно значение;

• Непустое поле определяет, что выбранное поле (физическая или комплексная колонка) содержит непустое значение;

• Уникальное поле определяет, что выбранное поле (физическая или комплексная колонка) содержит уникальное значение.

Добавим валидатор на поле, раскроем узел “Валидаторы” и выберем добавленный валидатор. Укажем для него колонку AbDocuments.Subject в свойстве Проверяемое поле, т.е. этот валидатор будет проверять, что в теме документа присутствуют отличные от пробелов символы. В свойстве Сообщение об ошибке зададим сообщение, которое увидит пользователь, когда попытается сохранить карточку с незаполненным полем. Если сообщение не задать, то пользователь увидит системное сообщение, которое полезно для отладки, но для рядового пользователя будет непонятным.

Аналогично добавим валидаторы на поля Number и Type, т.е. номер и тип документа являются обязательными для заполнения. Поле Partner с контрагентом может быть не заполнено, т.к., например, для внутренних документов не указывается контрагент.

Если мы сейчас откроем окно предпросмотра, то увидим, что рядом с заголовками полей, с которыми связаны валидаторы, отображается звёздочка. Она индицирует для пользователя тот факт, что поле нельзя оставлять пустым.

Создание экземпляра карточки

Теперь, наконец, настройка типа карточки завершена, и в системе есть всё необходимое, чтобы создать экземпляр карточки.

Откроем правую боковую панель в TessaClient, выберем плитку “Создать карточку”. Как видим, у администратора есть множество карточек для создания.

Если посмотреть на содержимое плитки “Создать карточку” для пользователя, не являющегося администратором, то ему будут доступны только те карточки, которые он должен создавать в соответствии с правами доступа, а это наша карточка “Document”, а также, возможно, другие типы карточек.

Нажав на плитку “Document”, карточка создаётся. При этом она создана только в памяти клиентского приложения, т.е. в БД нет записей, соответствующих карточке. Внешний вид карточки похож на тот, что мы видели в окне предпросмотра в редакторе типов карточек.

Если карточку сразу же сохранить (плитка “Сохранить новую” на левой боковой панели или [Ctrl]+[S]), то пользователю будет показано окно с ошибкой, где перечисляются сообщения всех сработавших валидаторов (текст сообщений задавался в свойстве валидатора Error message).

Закрыв окно, пользователь увидит карточку, в которой незаполненные поля были подсвечены красным. Так валидаторы “сообщили” контролам, что поля не заполнены, и те показали рамки, которые исчезают после заполнения.

Заполним поля и сохраним карточку.

Заголовок вкладки с карточкой изменился с “Новая карточка” на “Карточка”, что показывает, что карточка сохранена. При сохранении карточка записывает свои данные в БД, а затем загружается из БД. При этом в БД была создана строка (запрос INSERT) в таблице Instances (системная таблица, описывающая системные свойства карточки), а также добавлена строка в строковую секцию AbDocuments. Т.к. это единственная секция карточки, то других строк добавлено не было, но сложные карточки могут содержать десятки строковых и коллекционных секций. При последующих сохранениях карточки изменённые строки будут обновляться запросами UPDATE.

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

Открытие карточки из представления

Закроем карточку и обновим представление “Documents” (плитка “Обновить” на левой боковой панели или [F5]). Представление показывает одну строку с только что созданной карточкой.

Её можно открыть двойным кликом по строке представления.

Обратите внимание, что заголовок вкладки теперь “1”, т.е. значение поля “Number”, хотя мы не писали расширение Digest. Это штатная возможность платформы, когда представление или контрол со ссылкой предоставляют текст с названием карточки.

Название карточки из ссылки

Info

Взглянем ещё раз на #reference, ссылающийся на документ в метаинформации представления AbDocuments.

#reference(ColPrefix: Doc, RefSection: AbDocuments, DisplayValueColumn: DocNumber, IsCard: true, OpenOnDoubleClick: true)

Была открыта карточка именно по этой ссылке #reference, т.к. в ней указаны свойства OpenOnDoubleClick: true и IsCard: true. Идентификатор карточки был получен из колонки-идентификатора DocID, т.к. в свойстве ColPrefix: Doc определяется, что в #reference входят все колонки, алиас которых начинается с Doc, и DocID является первой подходящей колонкой с типом данных uniqueidentifier (Guid в схеме данных).

А заголовок вкладки с карточкой предоставила колонка DisplayValueColumn: DocNumber для строки, по которой дважды кликнули.

История действий

Теперь откроем историю действий с карточкой, выбрав плитку “История действий” в левой боковой панели.

История действий – это и есть логи аудита, которые фиксируют каждое действие с карточкой. Они записываются системой для тех типов карточек, у которых в настройках включен флаг Фиксировать действия. Сейчас для карточки доступно 3 записи (сверху выполненные позже): создание карточки, затем открытие (которое автоматически произошло после сохранения) и потом ещё одно открытие (которое выполнялось из представления по двойному клику).

У карточки имя “< имя неизвестно >“, т.к. для неё не была определена функция Digest в расширениях, и это ещё одна причина её определить. Любую запись в истории можно открыть, и прочитать подробную информацию обо всём, происходящем с карточкой. Запись по созданию карточки выглядит следующим образом:

Здесь для строковой секции AbDocuments записаны значения полей, которые заполнил пользователь.

Структура карточки

Структура карточки показывает в JSON-подобном формате сериализованные данные карточки, которые были отправлены на сервер. Такие данные называются структурой карточки.

По этим данным также видно, какая информация указана в секции AbDocuments. Просмотреть её до того, как карточка будет сохранена, можно, выбрав плитку “Card structure” на левой боковой панели в карточке документа.

Если в поле Partner указать некоторого контрагента “Syntellect” (если его нет, то можно создать карточку контрагента с таким именем), и, не сохраняя карточку, открыть её структуру, то она будет выглядеть следующим образом.

Здесь отображается не полная структура, а та, что будет направлена на сервер при сохранении, она содержит только системные поля и изменённые поля в секциях. В секции AbDocuments ссылочный контрол заполнил два поля: ParnterID с идентификатором контрагента и PartnerName с его именем. В разделе выше, в котором описывалась работа представлений, было рассказано, как поля из представления Partners заполняются в полях карточки.

Info

Отображение колонок представления на поля карточки

1. У полей комплексной колонки Partner “отбрасывается” префикс, т.е. вместо PartnerID получаем суффикс ID, а вместо PartnerName – Name.

2. В представлении Partners выполняется поиск подходящей ссылки #reference, из которой также удаляется префикс, заданный в ColPrefix. Это оставляет те же суффиксы ID и Name.

3. Для колонок с одинаковыми суффиксами переносятся данные, т.е. из ID запроса (“PartnerID”) в ID колонки (тоже “PartnerID”, т.к. префиксы совпали).

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

Удаление карточки и её восстановление

Теперь посмотрим, как происходит удаление карточки. Поскольку в типе карточки был поставлен флаг Удалять в корзину, то карточка удаляется “в корзину”, из которой она может быть восстановлена администратором. Однако, при удалении карточки все строки из её секций фактически удаляются, а в “корзине” размещается сериализованная структура карточки. Поэтому из нашей таблицы AbDocuments (и из одноимённого представления) строка с карточкой будет удалена.

Удалим карточку:

История действий по карточке с отметкой удаления будет доступна не из карточки (которая удалена), а из представления “История действий” в рабочем месте “Администратор”.

Собственно, удалённая карточка есть в представлении “Удаленные карточки”.

Открыв удалённую карточку по двойному клику, можно будет выполнить следующие действия: “Просмотр”, “Восстановить” или окончательно “Удалить” (кнопки на левой боковой панели). Для удалённой карточки используется имя “<имя неизвестно>“, т.к. для неё не определена функция Digest.

Система автоматически удаляет карточки спустя несколько дней после их удаления (по умолчанию через 30 дней), это настраивается в файле Plugins\Tessa\configuration\RemoveDeletedCards.xml, который расположен внутри основной папки сервиса Chronos.