Столкнулся с проблемой отправки картинок из 1С (при использовании внешнего HTML редактора)


Проблема заключается в том, что картинка вставленная в тело HTML письма в не зависимоти от расширения отсылается как *.tmp файл. Некоторые почтовые клиенты нормально отрабатывают <IMG src="путь_к_файлу\файл.tmp"> а всеми любимый почтовый клиент, входящий в офисный пакет всеми любимой мелко-мягкой фирмы по умолчанию tmp файлы блокирует.

Решение: Ищем в общем модуле УправлениеЭлектроннойПочтой следующую строку:

Код 1C v 8.х

 ПутьКФайлу = ПолучитьИмяВременногоФайла();   

Заменяем на это:

Код 1C v 8.х

 Если ЗначениеЗаполнено (СтрокаТаблицы.ИмяФайла) тогда

            имяф=СтрокаТаблицы.ИмяФайла;

            массивимяфайла = СтрЗаменить(имяф, ".",Символы.ПС);

            Расширение=СтрПолучитьСтроку(массивимяфайла,СтрЧислоСтрок(массивимяфайла));

            ПутьКФайлу = ПолучитьИмяВременногоФайла(Расширение);

Иначе

            ПутьКФайлу = ПолучитьИмяВременногоФайла();

КонецЕсли;

   

И картинки отсылаются с исходным расширением.

Начиная с платформы 8.0 системы 1С Предприятие, существует возможность ограничивать права доступа пользователей на уровне записей. Для этого используется механизм RLS (Record Level Security). Такая «тонкая» настройка может быть полезна для ограничения доступа по организациям, клиентам, номенклатуре и др.

RLS – это возможность разработчика задать условие на таблицы базы данных для тех или иных пользователей (групп пользователей) и не дать им увидеть лишнего. Условие имеет булевый тип. Если значение условия принимает значение «истина», то доступ предоставляется, в противном случае – запрещается.

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

RLS применяется для следующих видов прав доступа:
* Чтение
* Добавление
* Изменение
* Удаление

Порядок настройки RLS

Рассмотрим простой пример выполнения настройки. Снимки экрана сделаны на версии 1С Предприятие 8.2 (8.2.9.356). Синтаксис шаблонов текстов ограничений описан в документации по 8.2 в книге «Руководство разработчика. Часть 1», поэтому на нем останавливаться не будем.

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

После этого на основании указанных шаблонов задаются ограничения к необходимым объектам. Для редактирования текста условия можно воспользоваться конструктором ограничений доступа к данным.

Для редактирования нескольких ролей удобно управлять через окно «Все роли».

Для копирования условий в другие роли можно использовать окно «Все ограничения доступа». Шаблоны в другие роли могут копироваться только вручную.

Вот и все. Можно проверить результат.

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

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

Следует помнить, что ограничения прав доступа на уровне записей довольно ресурсоемкий механизм и чем более сложные ограничения Вы поставите, тем медленнее программа будет работать, особенно при большой базе данных.
Мелкоступов Александр