Решили внедрить документооборот, под эту лавочку есть идея попробовать перенести почту то-же в 1С. На данный момент почта самописанная на яве с набором дополнительных полей (кто смотрел, кто взял на исполнение, утвержденный ответ и т.п.), "сервер" агрегирует письма с поп3 ящиков, разбирает на заголовки-тела-вложения и раздает пользователям в зависимости от прав, попутно складируя тексты в бд а вложения на диск в папки по датам и уидам сообщения.
ИБ строится с нуля, на 1С давно посматриваю с интересом но никогда не щупал
В базу 1С удалось закинуть всю инфу через одату - при получении письма ява шлет пост запрос на расшаренную вэб-публикацию одаты и все вполне работает - элемент справочника (сообщения) создается, позволяет задать свой уид (реф_кей) и закинуть все реквизиты, но появилась пара вопросов:
1) одата упорно игнорирует тэг CDATA т.е. если тело письма пришло в html (а таких понятно большинство) то спрятать квадратные скобки не достаточно - приходится тело упаковывать в base64. Впринципе работает но не оптимально по производительности - нема какой замены cdat'е у 1Сной реализации хмл?
Если нема, то можно как-то переопределить обработчик входящей одаты, чтоб автоматически раскодировать base64 при получении? Смысл простой - если храним тело сообщения в base64 то теряем возможность поиска по реквизиту либо строим грабли с поиском по запакованной в base64 строке (кодировка всегда ютф-8 так что прокатит), а если раскодировать при открытии то надо добавлять лишний реквизит (например булево "раскодировано" - при передаче по одате булево устанавливаем, при первом открытии раскодируем строку и скидываем булево) что некомильфо. Событие "при создании" тоже не очень т.к. письмо может и пользователь создавать а не по одате получать т.е. строка закодирована только если прилетела извне (кстати, а "при создании" будет вообще срабатывать при создании элемента через одату или вэб-службы?)

2) Можно как-то работать с пользователями ИБ? Сейчас тупо создаю справочник "Пользователи" и заполняю там повторно реквизиты, создаю реквизит "логин" и коррелирую с реальным пользователем через ТекущийПользователь() соотв. - если пользователю в конфигураторе сменят логин то взаимосвязь слетит.
Может можно как-то накидать реквизитов ИБшному объекту "Пользователь" и работать с их списком?

3) Продолжение вопроса 2 - можно разделять доступ на уровне платформы к разным элементам одного и того-же справочника?
Т.е. есть справочник "Сообщения" в котором лежат все письма, сейчас у элемента есть реквизит "Ящик", который является ссылкой на Элемент справочника Ящики, у которого, в свою очередь, есть массив ссылок на пользователей "ПравоПросмотра". Т.е. список доступных писем формируется по наличию пользователя в списке доступа ящика-владельца письма. А нельзя ли программно задавать право просмотра элемента конкретному пользователю ИБ или конкретной РОЛИ ИБ? Получится заметно аккуратнее

Заранее спасибо за ответы!

п.с. бонусный вопрос - я правильно понимаю что в динамическом списке передаются только выбранные в форме списка реквизиты т.е. если в дин списке элементов "Сообщение" выбраны, например, только два строковых поля "От" и "Тема" то передаются только они, а остальные реквизиты лежат себе спокойно на сервере и ждут своего часа когда их явно запросят в обход списка?

https://its.1c.ru/db/v836doc#bookmark:dev:TI000001358

1) С odata не работал, но судя по описанию ты можешь повесить пользовательский обработчик бизнес событий на создание письма и там разибрать свой base64, не снимаю конфу с поддержки.
2) У ИБшного пользователя есть индентификатор.
3) В ДО есть РЛС, на базе Рабочих групп, там поковыряйся, закроет все твои потребности

4) В конфигураторе у элементов формы есть флаг "Использовать всегда" если он взведён то данные всегда будут возвращяться.

(1) Ага, спасибо, в самом конце создание собственного hs в целом подходит но влечет много велосипедов, а нельзя все-же переопределить обработчик штатной одаты чтоб была возможность вызвать супер-метод (переопределяемый) и после его работы подменить только один реквизит?

(2)
1) Просто письмо может быть создано как внешним действием через одату (и тогда тело в base64) а может быть создано пользователем непосредственно в форме 1С (и тогда тело сразу в обычной строке) а т.к. у base64 нет заголовка то определить что же в теле можно только создавая доп реквизит.
2) А, пойду почитаю - чегот сразу не нашел
3) О! спасибо! рлс вроде то что надо
4) Мне-б наоборот быть уверенным что дин список с заголовками сообщений не потащит себе тела сообщений - в яве это разрулено просто - тела и заголовки внутри сервера хранятся в одном классе но при отправке наружу дробятся на два разных класса - соотв. есть уверенность что запросы заголовков не тянут тяжеловесные тела. Судя по описанию динамических списков, они, вроде как, позволяют не дробить классы вручную а сами генерят себе класс исходя из набора колонок - просто хочется быть уверенным ))