Продолжаю переносить почту в 1С, сборкой с поп3, разбором маймов и сохранением на диск заведует внешняя аппликушка, которая в 1С засылает через одату заголовки, тела и ссылки на вложения.
Вопрос в том, как лучше организовать хранение данных в 1С
Вариантов вижу два:
1) По аналогии с тем, как делал во внешней аппликухе - создаю три справочника - Пользователи, ПочтовыеЯщики и Сообщения, в каждом элементе справочника Сообщения есть табличная часть в которой лежат ссылки на элементы справочника ПочтовыеЯщики (т.к. письмо может лежать в нескольких ящиках - например оно падает в ящик "Отдел продаж" но менеджер может расшарить его в ящик "Проектировщики" если клиент например просит подобрать оборудование и после этого выставить счет). У элементов справочника ПочтовыеЯщики есть табличная часть ПравоПросмотра, в которой лежат ссылки на Пользователей, которые имеют право просмотра сообщений в этом ящике.
Концепция отлично работает на яве, где все заголовки сообщений болтаются в оперативной памяти и база данных не дергается при каждом обращении пользователя
В 1С получается что надо сделать два запроса - вначале получить список доступных пользователю ящиков и потом выбрать из сообщений те, у которых в табличной части присутствует любой из них
Бонусом в яве перечисление ящиков для сообщения это банальный массив, а вот в 1С, насколько я понимаю, табличная часть это отдельная таблица субд, которая создается для каждого сообщения (или я не прав?) и соотв. на 10к сообщений = 10к доп таблиц?

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

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

про РС ни слова.

(1) А как сюда РС подпихнуть? Чот не приходит в голову

(0)
>табличная часть это отдельная таблица субд, которая создается для каждого сообщения (или я не прав?) и соотв. на 10к сообщений = 10к доп таблиц
нет. таблица одна.

Не ясно, зачем сущность "Почтовые ящики"

"табличная часть это отдельная таблица субд, которая создается для каждого сообщения (или я не прав?)" // Не прав - физическая таблица для ТЧ справочника (для данных) одна единая

(2)
вместо ТЧ РС с измерениями Пользователи и Сообщения (оба ведущие).
можно рассмотреть вариант вместо ТЧ подчиненный справочник.
ЗЫ
имхо. от ТЧ надо отказаться.

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

Отдельные справочники:
1. справочник пользователей системы
2. учетные записи почты для этих пользователей
3. почтовые сообщения

в почтовых сообщениях табличная часть для получателей, CC и BCC

учетные записи - подчиненный справочник

(8) А может справочник подчиняться нескольким пользователям? т.е. если учетная запись "Офисная почта" доступна сразу всем пользователям, а учетная запись "Отдел продаж" только некоторым то как организовать подчинение?

(9) Два владельца у одного справочника могут быть. Но у одного элемента подчиненного справочника всегда один и только один элемент-владелец

(9) Либо ТЧ у спр. Пользователи, либо через РС с измерениями пользователь,учетнаязапись

(9) а что значит "учетная запись доступна пользователям"?

если речь про список рассылки, то это не учетная запись

(12) Например когда есть ящик office@домен, который доступен всем и ящик sale@домен который доступен не всем
Бонусом вариант когда ящика внешнего нет но есть элемент справочника ПочтовыеЯщики "Инженерный отдел" который доступен, опять-же, некоторым пользователям
Смысл именно в уходе от рассылок и копий, когда каждый пользователь получает свою копию письма и никто кроме него не видит обработали ли это письмо.
Простой пример - в папку sale@ падает запрос на счет, если мы тупо раскидываем копии письма всем подписанным на папку, то каждый манагер в праве думать что на письмо ответил кто-то другой, ровно как и в праве ответить каждый, думая что никто не отвечал на сообщение.
Если же все видят один и тот-же элемент справочника Сообщения то все манагеры могут:
- видить ответил ли кто-то и что именно ответил
- поставить отметку об исполнении чтоб никто не тратил время на ответ
- подоткнуть еще ящиков получателей чтоб подозвать помощь из других отделов - проектантов, инженеров, техсуппорт и т.п., опять-же с дальнейшим доступом ко всем комментариям других пользователей.

(11) Да, кстати, вариант 1) можно немного переработать - не в справочник ПочтовыеЯщики добавлять ТЧ с правами просмотра/редактирования/ответа и т.п., а пользователям добавлять ТЧ с перечислением ящиков, доступных для просмотра и т.п.
Но перебор ящиков с доступными правами при выборке писем происходит только один раз - так что выигрыш не большой но в целом есть, да

Кстати еще вопрос по поводу (15)
Если интегрировать элементы конфигурации в типовую конфу (никогда этого не делал), то что лучше:
- доп справочники, которых нет в типовой конфе (когда ТЧ с правами лежит в справочнике ПочтовыеЯщики, которого нет в типовой) или лучше
- доп поля для справочников типовой (когда ТЧ с правами лежат в справочнике Пользователи, который есть в типовой)
?

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

"уходе от рассылок и копий" - это не делается так.
То, что ты описываешь, - это по сути хелпдеск или что-то похожее. Задача прилетает по почте, пока она не назначена, ее видят все, когда назначена, ее, может, и вяд все, но сделать что-то может только тот, кому назначена.

Это нельзя решить путем раздачи доступов всем в один и тот же ящик.

Для этого надо, чтобы на ящике sale@ сидел робот, создавал отдельный объект "Задача" на основании каждого письма, и складывал эту задачу в какую-то очередь. Объект "задача" уже реализует требуемый воркфлоу (hint - это бизнес процессы). Далее люди уже работают не с почтой, а с задачами в очередях.

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

вообще - это тупо otrs. Из коробки.

(18) Можно и через задачи но грабли остаются теми-же - разделение доступа (не должны менеджеры подписанные на sale@ видеть например задачи прилетевшие в techsupport@) и возможность коллективной работы с одной и той-же задачей (19) У нас сейчас аналог работает, но есть ряд хотелок, которые требуют попробовать реализовать это внутри 1ски

(20) RLS для этого придуман 100500 лет назад

(20) задача и письмо - это две разные сущности. Не смешивай их - козлёночком станешь.

(22) Про задачи кстати интересная идея - пойду покурю мануалы
Я же правильно понимаю что в адресации и исполнителях задач можно указывать группы?