На данный момент вложения чатов сохраняются в базу данных.

Метод SaveFileFromStream класса OmnichannelProviders.AttachmentsDownloader использует стандартный метод entity.SetStreamValue("Data", ms).

Метод SaveFile класса Terrasoft.Configuration.Omnichannel.Messaging.OmnichannelOutcomeMessagingService использует стандартный метод entity.SetStreamValue("Data", attachment.Content).



При этом с недавнего времени появились абстрактные интефейсы для работы с файлами в системе (Terrasoft.File).

https:/academy.terrasoft.ua/docs/developer/back_end_razrabotka/api_dlya_raboty_s_fajlami/obzor



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



Идея:

Доработать матоды OmnichannelProviders.AttachmentsDownloader.SaveFileFromStream и Terrasoft.Configuration.Omnichannel.Messaging.OmnichannelOutcomeMessagingService.SaveFile, чтобы они работали через интерфейсы Terrasoft.File.

1 комментарий

Владислав, добрый день, благодарю за вашу идею по развитию системы. Ваше пожелание было передано ответственной команде.

Показать все комментарии

Каким образом, и возможно ли опубликовать событие и подписываться на него в пределах одной схемы ?
Возможно это можно сделать в модуле-зависимости ?

Нравится

5 комментариев

Какая цель использовать sandbox в рамках одной схемы? Это нельзя, и в этом нет смысла. Используйте колбеки.

Ну юзкейс у такого положения вещей есть:
Уже "притчей во-языцах" становится извечная проблема открытия карточек в Combined и Separated режимах, и добавлением какого либо функционала в верхнее горизонтальное меню.
Приходится описывать свою бизнес-логику как для секции так и для карточки, причем логика в сути идентичная, кроме способа получения данных самой карточки (для секции это отдельные трудности, так как прямого доступа к модели карточки не имеется, разве что через "GridData"), так же секцию выделяет то что там необходимо реагировать на отдельные события инициализации карточки.
Вообщем все это порождает офигенный оверхед по коду.
Решение было найдено через Миксин-модуль и события.
Таким образом специально сконфигурированный миксин можно подключать и к карточке и к схеме - логика описана в едином месте, в едином виде, в сути все происходит в карточке, а секция просто соответствующим образом реагирует и подписывается на ряд событий.
Так вот сейчас приходится разделять Миксин-модуль | Модуль экспортирующий публикации | Модуль экспортирующий подписки.
Ну и проскочила мысль, что сами messages можно в рамках одной схемы объявить (одного миксина) а уже подписываться/публиковать по ситуации в схемах куда миксин подключен.

"Севостьянов Илья Сергеевич" написал:Вообщем все это порождает офигенный оверхед по коду.

Именно поэтому мы используем прямой переход из секции в карточку (банально window.open) по клику на запись в реестре. Ибо дублировать логику/пилить кучу сообщений из секции в карточку тупо не хватает терпения. Ууууух. Руку бы пожал тому человеку, который додумался до combined-режима))

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

Проблему понял, но все же в одной схеме нельзя и подписыватся и публиковать, так что либо как сделали вы, либо миксин один на всех, а вот объявлять сообщение непосредственно в карточке\секции.

Показать все комментарии