\nОбласть применения: управляемое приложение, обычное приложение.
1. В управляемом режиме из-за ряда ограничений тонкого клиента может возникнуть необходимость поддержки запуска толстого клиента (в режиме управляемого приложения). Подробнее см. Функциональность обычного приложения, отсутствующая в управляемом приложении.
\n2. При этом разработка конфигураций, рассчитанных на режим управляемого приложения, как правило, ведется исходя из того, что в клиент-серверной архитектуре код следующих модулей компилируется и выполняется только на сервере
\nВ частности, в указанных модулях может встречаться обращение к общим модулям, доступным только на сервере.
\nОднако в толстом клиенте, в режиме управляемого приложения, клиент-сервер, возможны ситуации, когда указанные модули могут начать компилироваться и выполняться на стороне клиента, в частности:
\nКомпиляция и выполнение таких модулей на клиенте могут приводить к ошибкам. По этой причине режим проверки конфигурации для режима толстый клиент, управляемое приложение, может находить ошибки в указанных модулях.
\nДля того чтобы избежать незапланированной компиляции и исполнения указанных модулей на клиенте, а также чтобы избежать лишних сообщений режима проверки конфигурации, следует:
\n\n\n#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда
…
#Иначе
ВызватьИсключение НСтр(\"ru = 'Недопустимый вызов объекта на клиенте.'\");
#КонецЕсли
\n\n#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда
…
#КонецЕсли
\n\n#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда
…
#КонецЕсли
В последнем случае также будет действовать следующее ограничение: если представление объектов формируется обработчиками событий модуля менеджера ОбработкаПолученияПредставления и ОбработкаПолученияПолейПредставления, то в толстом клиенте, в режиме управляемого приложения, клиент-сервер, представление будет формироваться по умолчанию, без вызова этих обработчиков, и тем самым будет отличаться от остальных режимов работы. (При этом оставшиеся два обработчика модуля менеджера ОбработкаПолученияДанныхВыбора и ОбработкаПолученияФормы вызываются всегда только на сервере, поэтому указанное ограничение на них не распространяется.)
\n| \n Методическая рекомендация (полезный совет) \n3. В тех случаях, когда требуется снять указанное выше ограничение, необходимо дополнительно обеспечить работу на клиенте следующих фрагментов серверного кода: \n
Для этого код перечисленных обработчиков событий следует вынести за инструкции препроцессора, указанные в п.2, а обработчики подписок разместить в клиент-серверных модулях. \nПри необходимости вызова серверных процедур (и функций) из клиентского кода следует размещать вызываемые процедуры в серверных общих модулях с признаком Вызов сервера. При этом нужно убедиться, что в параметры процедур (и в возвращаемые значения функций) не передаются значения мутабельных типов (СправочникОбъект, ДокументОбъект и пр.) \nВажно: не следует для этих целей всем общим модулям с признаком Сервер принудительно устанавливать флажок Вызов сервера. Подробнее см. Ограничение на установку признака «Вызов сервера» у общих модулей. \nНапример, обработчик события ОбработкаПолученияПредставления вызывает общий модуль, который не доступен на клиенте: \nПроцедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка) правильно выполнить переход на сервер (и при этом не передавать на клиент значения мутабельных типов): \nПроцедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка) КонецПроцедуры |
4. Для расстановки фрагментов кода с инструкциями препроцессора можно воспользоваться приложенной обработкой.
", "type": "BUG" }, { "engineId": "acc", "ruleId": "538 : Проверка подсистем объектов_ не имеющих визуального представления", "name": "Объект, не имеющий визуального представления, входит в состав подсистемы, включенной в командный интерфейс (538)", "severity": "INFO", "description": "\nОбласть применения: управляемое приложение, обычное приложение.
Методическая рекомендация (полезный совет)
\n1.1. С помощью подсистем решаются две методические задачи:
\nВ простейшем случае, получившаяся для обоих задач структура подсистем конфигурации может совпадать.
\nНапример, видимые для пользователей разделы командного интерфейса «Закупки», «Продажи» и пр. могут использоваться одновременно и при разработке: для быстрого отбора объектов в окне метаданных Конфигуратора, при переносе объектов в другие конфигурации, для задания ограничений области поиска при глобальном поиске по конфигурации и т.д.
\nУ таких подсистем должен быть установлен флажок Включать в командный интерфейс.
\n1.2. В общем случае, подсистема, логически объединяющая некоторый набор объектов метаданных, может не совпадать с одним разделом командного интерфейса приложения. Для логического объединения набора объектов метаданных по функциональному признаку рекомендуется заводить в конфигурации отдельную иерархию подсистем, не включенных в командный интерфейс. У таких «функциональных» подсистем флажок Включать в командный интерфейс должен быть снят.
\nПримеры:
\n1.3. При этом, общие модули, регламентные задания, константы, подписки на события и прочие объекты, не имеющие визуального представления в командном интерфейсе, рекомендуется включать только в состав «функциональных» подсистем.
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. Общие модули создаются для реализации процедур и функций, объединенных по некоторому признаку. Как правило, в один общий модуль помещаются процедуры и функции одной подсистемы конфигурации (продажи, закупки) или процедуры и функции сходного функционального назначения (работа со строками, общего назначения).
\n1.2. При разработке общих модулей следует выбирать один из четырех контекстов выполнения кода:
\n| \n | Тип общего модуля | \nПример наименования | \nВызов сервера | \nСервер | \nВнешнее соединение | \nКлиент (обычное приложение) | \nКлиент (управляемое приложение) |
| 1. | \nСерверный | \nОбщегоНазначения (или ОбщегоНазначенияСервер) | \n\n
| \n\n + | \n\n + | \n\n + | \n\n
|
| 2. | \nСерверный для вызова с клиента | \nОбщегоНазначенияВызовСервера | \n\n + | \n\n + | \n\n
| \n\n
| \n|
| 3. | \nКлиентский | \nОбщегоНазначенияКлиент (или ОбщегоНазначенияГлобальный) | \n\n
| \n\n
| \n\n
| \n\n + | \n\n + |
| 4. | \nКлиент-серверный | \nОбщегоНазначенияКлиентСервер | \n\n
| \n\n + | \n\n + | \n\n + | \n\n + |
2.1. Серверные общие модули предназначены для размещения серверных процедур и функций, не доступных для использования из клиентского кода. В них реализуется вся внутренняя серверная бизнес-логика приложения.
Для корректной работы конфигурации в режимах внешнего соединения, управляемого и обычного приложений, серверные процедуры и функции следует размещать в общих модулях с признаками:
В таком случае гарантируется возможность вызова серверных процедур и функций с параметрами мутабельных типов (например, СправочникОбъект, ДокументОбъект и т.п.). Как правило, это:
\nСерверные общие модули называются по общим правилам именования объектов метаданных.
Например: РаботаСФайлами, ОбщегоНазначения
В отдельных случаях для предотвращения конфликта имен со свойствами глобального контекста может быть добавлен постфикс \"Сервер\" (англ. \"Server\").
Например: РегламентныеЗаданияСервер, ОбменДаннымиСервер, ScheduledJobsServer.
2.2. Серверные общие модули для вызова с клиента содержат серверные процедуры и функции, доступные для использования из клиентского кода. Они составляют клиентский программный интерфейс сервера приложения.
Такие процедуры и функции размещаются в общих модулях с признаком:
Серверные общие модули для вызова с клиента называются по общим правилам именования объектов метаданных и должны именоваться с постфиксом \"ВызовСервера\" (англ. \"ServerCall\").
Например: РаботаСФайламиВызовСервера, CommonServerCall
Следует иметь в виду, что экспортные процедуры и функции в таких общих модулях не должны содержать параметров мутабельных типов (СправочникОбъект, ДокументОбъект и т.п.), так как их передача из (или в) клиентского кода невозможна.
\n\n\nСм. также: Ограничение на установку признака «Вызов сервера» у общих модулей
2.3. Клиентские общие модули содержат клиентскую бизнес-логику (функциональность, определенную только для клиента) и имеют признаки:
\nИсключение составляют случаи, когда клиентские процедуры и функции должны быть доступны только в режиме управляемого приложения (только в режиме обычного приложения или только в режиме внешнего соединения). В таких случаях, допустима иная комбинация двух этих признаков.
\nКлиентские общие модули именуются с постфиксом \"Клиент\" (англ. \"Client\").
Например: РаботаСФайламиКлиент, ОбщегоНазначенияКлиент, StandardSubsystemsClient
\n\nСм. также: минимизация кода, выполняемого на клиенте
2.4. Для того чтобы избежать дублирования кода, рекомендуется создавать клиент-серверные общие модули с теми процедурами и функциями, содержание которых одинаково на сервере и на клиенте. Такие процедуры и функции размещаются в общих модулях с признаками:
\nОбщие модули этого вида именуются с постфиксом \"КлиентСервер\" (англ. \"ClientServer\").
Например: РаботаСФайламиКлиентСервер, ОбщегоНазначенияКлиентСервер, UsersClientServer
В то же время, как только возникает необходимость ветвить код в клиент-серверных общих модулях на серверный и клиентский, то не следует использовать для этого инструкции препроцессора. Вместо этого, функциональность, различную для клиента и для сервера, рекомендуется реализовывать по общим правилам в модулях соответствующего типа – см. пп. 2.1 и 2.3. Такое явное разделение клиентской и серверной бизнес-логики продиктовано соображениями повышения модульности прикладного решения, упрощения контроля со стороны разработчика над клиент-серверным взаимодействием и снижением риска ошибок из-за принципиальных отличий требований к разработке клиентского и серверного кода (необходимость минимизации кода, выполняемого на клиенте, разной доступностью объектов и типов платформы и др.). При этом нужно иметь в виду неизбежное увеличение числа общих модулей в конфигурации.
\n\n\nПодробнее см.: Использование директив компиляции и инструкций препроцессора
Особым случаем смешанных клиент-серверных модулей являются модули форм и команд, которые специально предназначены для реализации серверной и клиентской бизнес-логики в одном модуле.
\n3.1. Имена общих модулей рекомендуется строить по общим правилам именования объектов метаданных. Название общего модуля должно совпадать с названием подсистемы или отдельного механизма, процедуры и функции которой он реализует. Рекомендуется избегать в названиях общих модулей таких общих слов как \"Процедуры\", \"Функции\", \"Обработчики\", \"Модуль\", \"Функциональность\" и т.п. и применять их только в исключительных случаях, когда они более полно раскрывают назначение модуля.
\nДля того чтобы различать общие модули одной подсистемы, которые созданы для реализации процедур и функций, выполняемых в разных контекстах, рекомендуется задавать им постфиксы, описанные ранее в пп. 2.1-2.4.
\n3.2. Дополнительно к общим модулям могут быть добавлены уточняющие постфиксы.
\n3.2.1. Для глобальных модулей добавляется постфикс \"Глобальный\" (англ. \"Global\"), , в этом случае постфикс \"Клиент\" добавлять не следует.
Например: РаботаСФайламиГлобальный, InfobaseUpdateGlobal
3.2.2. Модули, выполняющиеся в привилегированном режиме, имеющие признак Привилегированный, именуются с постфиксом \"ПолныеПрава\" (англ. \"FullAccess\").
Например: РаботаСФайламиПолныеПрава
3.2.3. Модули, предназначенные для реализации на сервере или на клиенте функций с повторным использованием возвращаемых значений (на время вызова или на время сеанса), именуются с постфиксом \"ПовтИсп\" (англ. \"Cached\") и \"КлиентПовтИсп\" (англ. \"ClientCached\") соответственно.
Например: РаботаСФайламиКлиентПовтИсп, UsersInternalCached
3.2.4. Серверные и клиентские модули библиотечных конфигураций (которые предназначены не для самостоятельного использования, а для разработки других конфигураций) с процедурами и функциями, допускающие изменение своей реализации, именуются с постфиксами \"Переопределяемый\" (англ. \"Overridable\") и \"КлиентПереопределяемый\" (англ. \"ClientOverridable\").
Например: РаботаСФайламиКлиентПереопределяемый, CommonOverridable
\n\nСм. также: Переопределяемые и поставляемые объекты библиотеки
\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. В конструкциях встроенного языка ключевые слова пишутся канонически (как в документации или Синтакс-помощнике).
Правильно:
КонецЕсли
\nНеправильно:
\nконецЕсли, КОНЕЦЕСЛИ, конецесли, Конецесли.
\n2. При следовании друг за другом нескольких операторов присваивания, допускается выравнивать их следующим образом:
\nДиалогВыбора.ПолноеИмяФайла = ИмяФайла;
ДиалогВыбора.Каталог = ИмяПути;
ДиалогВыбора.Заголовок = НСтр(\"ru = 'Выберите файл со списком запросов'\");
ДиалогВыбора.Фильтр = НСтр(\"ru = 'Файлы запросов (*.sel)|*.sel|Все файлы (*.*)|*.*'\");
ДиалогВыбора.Расширение = \"sel\";
При этом не следует выравнивать операторы одинаково по всему модулю - рекомендуется делать выравнивание только для операторов, расположенных рядом.
3. Составные логические выражения в Если…КонецЕсли переносятся согласно правилам переноса выражений.
4. Логические выражения и логические значения (например, результат функции, возвращающей логическое значение, переменные типа Булево и пр.) не следует проверять путем сравнения с литералами Истина и Ложь.
Правильно:
Если ЭтоНовый() Тогда
\nНеправильно:
\nЕсли ЭтоНовый() = Истина Тогда
\n5. В тех случаях, когда требуется сравнивать результаты каких-либо выражений, следует предварительно присваивать результаты этих выражений промежуточным переменным, и сравнивать уже сами эти переменные.
Правильно:
Ответ = Вопрос(НСтр(\"ru = 'Данные еще не записаны. Записать?'\"), РежимДиалогаВопрос.ДаНет,, КодВозвратаДиалога.Да);
Если Ответ = КодВозвратаДиалога.Да Тогда
Записать();
Иначе
Возврат;
КонецЕсли;
Неправильно:
\nЕсли Вопрос(НСтр(\"ru = 'Данные еще не записаны. Записать?'\"), РежимДиалогаВопрос.ДаНет,, КодВозвратаДиалога.Да) = КодВозвратаДиалога.Да Тогда
Записать();
Иначе
Возврат;
КонецЕсли;
6. Необходимо использовать системные наборы значений везде, где возможно их применить, например, вместо Символ(10) следует использовать Символы.ПС.
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. В программном модуле (общие модули, модули объектов, модули менеджеров объектов, модули форм, команд и т.п.) в общем случае могут присутствовать следующие разделы в приведенной ниже последовательности:
\nНекоторые разделы могут присутствовать только в модулях определенного вида. Например, обработчики событий элементов форм могут присутствовать только в модулях форм, а раздел описания переменных и раздел инициализации не могут быть определены в неглобальных общих модулях, модулях менеджеров объектов, наборов записей, значений констант и модуле сеанса.
\nТребование о разделении кода модуля на разделы призвано повысить читаемость кода и упростить внесение изменений в код разными авторами (разработчиками) как при коллективной разработке, так и при доработке прикладных решений на конкретных внедрениях.
\n1.2. Объемные разделы модулей рекомендуется разбивать на подразделы по функциональному признаку.
\n1.3. Разделы и подразделы оформляются в виде областей. При этом имена областей должны удовлетворять требованиям стандарта Правила образования имен переменных
\n1.4. Шаблон (заготовка для копирования) разделов для общих модулей:
\nрусск.
#Область ПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныйПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region Public\n// Enter code here.\n#EndRegion\n\n#Region Internal\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n\n
русск.
#Область ОбновлениеИнформационнойБазы\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region InfobaseUpdate\n// Enter code here.\n#EndRegion\n\n
1.5. Шаблон оформления разделов для модулей объектов, менеджеров, наборов записей, обработок, отчетов и т.п.:
\nрусск.
#Область ПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиСобытий\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныйПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region Public\n// Enter code here.\n#EndRegion\n\n#Region EventHandlers\n// Enter code here.\n#EndRegion\n\n#Region Internal\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n\n
1.6. Шаблон оформления разделов для модулей форм:
\nрусск.
#Область ОбработчикиСобытийФормы\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиСобытийЭлементовШапкиФормы\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиСобытийЭлементовТаблицыФормы<ИмяТаблицыФормы>\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиКомандФормы\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region FormEventHandlers\n// Enter code here.\n#EndRegion\n\n#Region FormHeaderItemsEventHandlers\n// Enter code here.\n#EndRegion\n\n#Region\nFormTableItemsEventHandlers \n// Enter code here.\n#EndRegion\n\n#Region FormCommandsEventHandlers\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n
\n\nСм. также: Правила создания модулей форм
1.7. Шаблон оформления разделов для модулей команд:
\nрусск.
#Область ОбработчикиСобытий\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region EventHandlers\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n\n
1.8. В модуле не должно быть пустых областей.
\n2. Общие требования к разделам программных модулей.
\n2.1. Заголовок модуля представляет собой комментарий в самом начале модуля. В заголовке модуля приводится его краткое описание и условия применения.
Например:
////////////////////////////////////////////////////////////////////////////////\n// Клиентские процедуры и функции общего назначения:\n// - для работы со списками в формах;\n// - для работы с журналом регистрации;\n// - для обработки действий пользователя в процессе редактирования\n// многострочного текста, например комментария в документах;\n// - прочее.\n// \n////////////////////////////////////////////////////////////////////////////////\n\n
Для модулей форм в заголовке рекомендуется размещать описание параметров формы.
\n2.2. Раздел описания переменных. Имена переменных назначаются согласно общим правилам образования имен переменных, а их использование описывается в статье Использование глобальных переменных в программных модулях.
\nВсе переменные модуля должны быть снабжены комментарием, достаточным для понимания их назначения. Комментарий рекомендуется размещать в той же строке, где объявляется переменная.
Пример:
русск.
#Область ОписаниеПеременных\n\nПерем ВалютаУчета;\nПерем АдресПоддержки;\n...\n\n#КонецОбласти\n\n
англ.
#Region Variables\n\nVar PresentationCurrency;\nVar SupportEmail;\n...\n\n#EndRegion\n\n
2.3. Программный интерфейс. Экспортные процедуры и функции, составляющие его программный интерфейс, размещаются сразу же после описания переменных. Такие процедуры и функции предназначены для использования другими объектами конфигурации или другими программами (например, через внешнее соединение), поэтому должны быть расположены в модуле на \"видном месте\".
\n\n\nСм. также: Описание процедур и функций
2.4.1. Обработчики событий формы, команд и элементов формы. Перед служебными процедурами и функциями в модуле формы располагаются обработчики событий формы, а также обработчики событий команд и элементов формы.
\n2.5. Обработчики событий модулей объекта и менеджера объекта размещаются после раздела с программным интерфейсом, но до служебных процедур и функций модуля. \n
| \n Методическая рекомендация (полезный совет) \n2.5.1. Рекомендуется располагать обработчики, придерживаясь порядка их следования в описании встроенного языка. |
2.6. Служебные процедуры и функции модуля, которые не являются обработчиками событий, а составляют внутреннюю реализацию модуля, размещаются в модуле следом за обработчиками событий.
\nВ тех случаях когда общий модуль является частью некоторой функциональной подсистемы, включающей в себя несколько объектов метаданных, в этом разделе также могут быть размещены служебные экспортные процедуры и функции, предназначенные только для вызова из других объектов данной подсистемы.
\nПроцедуры и функции, связанные между собой по характеру или по логике работы рекомендуется располагать вместе. В модулях форм не рекомендуется явно группировать процедуры и функции модуля на серверные, клиентские и функции без контекста, так как такое «технологическое» упорядочивание затрудняет понимание логики модуля, отвлекая внимание разработчика на детали ее реализации.
\n2.7. Раздел инициализации содержит операторы, инициализирующие переменные модуля или объект (форму).
Например:
русск.
#Область Инициализация\n\nАдресПоддержки = \"v8@1c.ru\"; \nВыполнитьИнициализацию();\n...\n\n#КонецОбласти\nангл.
#Region Initialize\n\nSupportEmail = \"v8@1c.ru\";\nCtor();\n...\n\n#EndRegion\n\n
Для оформления разделов кода в виде областей рекомендуется воспользоваться приложенной обработкой.
", "type": "BUG" }, { "engineId": "acc", "ruleId": "239 : Структура стандартных областей", "name": "В модуле должны быть определены стандартные области (239)", "severity": "CRITICAL", "description": "\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. В программном модуле (общие модули, модули объектов, модули менеджеров объектов, модули форм, команд и т.п.) в общем случае могут присутствовать следующие разделы в приведенной ниже последовательности:
\nНекоторые разделы могут присутствовать только в модулях определенного вида. Например, обработчики событий элементов форм могут присутствовать только в модулях форм, а раздел описания переменных и раздел инициализации не могут быть определены в неглобальных общих модулях, модулях менеджеров объектов, наборов записей, значений констант и модуле сеанса.
\nТребование о разделении кода модуля на разделы призвано повысить читаемость кода и упростить внесение изменений в код разными авторами (разработчиками) как при коллективной разработке, так и при доработке прикладных решений на конкретных внедрениях.
\n1.2. Объемные разделы модулей рекомендуется разбивать на подразделы по функциональному признаку.
\n1.3. Разделы и подразделы оформляются в виде областей. При этом имена областей должны удовлетворять требованиям стандарта Правила образования имен переменных
\n1.4. Шаблон (заготовка для копирования) разделов для общих модулей:
\nрусск.
#Область ПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныйПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region Public\n// Enter code here.\n#EndRegion\n\n#Region Internal\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n\n
русск.
#Область ОбновлениеИнформационнойБазы\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region InfobaseUpdate\n// Enter code here.\n#EndRegion\n\n
1.5. Шаблон оформления разделов для модулей объектов, менеджеров, наборов записей, обработок, отчетов и т.п.:
\nрусск.
#Область ПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиСобытий\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныйПрограммныйИнтерфейс\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region Public\n// Enter code here.\n#EndRegion\n\n#Region EventHandlers\n// Enter code here.\n#EndRegion\n\n#Region Internal\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n\n
1.6. Шаблон оформления разделов для модулей форм:
\nрусск.
#Область ОбработчикиСобытийФормы\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиСобытийЭлементовШапкиФормы\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиСобытийЭлементовТаблицыФормы<ИмяТаблицыФормы>\n// Код процедур и функций\n#КонецОбласти\n\n#Область ОбработчикиКомандФормы\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region FormEventHandlers\n// Enter code here.\n#EndRegion\n\n#Region FormHeaderItemsEventHandlers\n// Enter code here.\n#EndRegion\n\n#Region\nFormTableItemsEventHandlers \n// Enter code here.\n#EndRegion\n\n#Region FormCommandsEventHandlers\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n
\n\nСм. также: Правила создания модулей форм
1.7. Шаблон оформления разделов для модулей команд:
\nрусск.
#Область ОбработчикиСобытий\n// Код процедур и функций\n#КонецОбласти\n\n#Область СлужебныеПроцедурыИФункции\n// Код процедур и функций\n#КонецОбласти\n\n
англ.
#Region EventHandlers\n// Enter code here.\n#EndRegion\n\n#Region Private\n// Enter code here.\n#EndRegion\n\n
1.8. В модуле не должно быть пустых областей.
\n2. Общие требования к разделам программных модулей.
\n2.1. Заголовок модуля представляет собой комментарий в самом начале модуля. В заголовке модуля приводится его краткое описание и условия применения.
Например:
////////////////////////////////////////////////////////////////////////////////\n// Клиентские процедуры и функции общего назначения:\n// - для работы со списками в формах;\n// - для работы с журналом регистрации;\n// - для обработки действий пользователя в процессе редактирования\n// многострочного текста, например комментария в документах;\n// - прочее.\n// \n////////////////////////////////////////////////////////////////////////////////\n\n
Для модулей форм в заголовке рекомендуется размещать описание параметров формы.
\n2.2. Раздел описания переменных. Имена переменных назначаются согласно общим правилам образования имен переменных, а их использование описывается в статье Использование глобальных переменных в программных модулях.
\nВсе переменные модуля должны быть снабжены комментарием, достаточным для понимания их назначения. Комментарий рекомендуется размещать в той же строке, где объявляется переменная.
Пример:
русск.
#Область ОписаниеПеременных\n\nПерем ВалютаУчета;\nПерем АдресПоддержки;\n...\n\n#КонецОбласти\n\n
англ.
#Region Variables\n\nVar PresentationCurrency;\nVar SupportEmail;\n...\n\n#EndRegion\n\n
2.3. Программный интерфейс. Экспортные процедуры и функции, составляющие его программный интерфейс, размещаются сразу же после описания переменных. Такие процедуры и функции предназначены для использования другими объектами конфигурации или другими программами (например, через внешнее соединение), поэтому должны быть расположены в модуле на \"видном месте\".
\n\n\nСм. также: Описание процедур и функций
2.4.1. Обработчики событий формы, команд и элементов формы. Перед служебными процедурами и функциями в модуле формы располагаются обработчики событий формы, а также обработчики событий команд и элементов формы.
\n2.5. Обработчики событий модулей объекта и менеджера объекта размещаются после раздела с программным интерфейсом, но до служебных процедур и функций модуля. \n
| \n Методическая рекомендация (полезный совет) \n2.5.1. Рекомендуется располагать обработчики, придерживаясь порядка их следования в описании встроенного языка. |
2.6. Служебные процедуры и функции модуля, которые не являются обработчиками событий, а составляют внутреннюю реализацию модуля, размещаются в модуле следом за обработчиками событий.
\nВ тех случаях когда общий модуль является частью некоторой функциональной подсистемы, включающей в себя несколько объектов метаданных, в этом разделе также могут быть размещены служебные экспортные процедуры и функции, предназначенные только для вызова из других объектов данной подсистемы.
\nПроцедуры и функции, связанные между собой по характеру или по логике работы рекомендуется располагать вместе. В модулях форм не рекомендуется явно группировать процедуры и функции модуля на серверные, клиентские и функции без контекста, так как такое «технологическое» упорядочивание затрудняет понимание логики модуля, отвлекая внимание разработчика на детали ее реализации.
\n2.7. Раздел инициализации содержит операторы, инициализирующие переменные модуля или объект (форму).
Например:
русск.
#Область Инициализация\n\nАдресПоддержки = \"v8@1c.ru\"; \nВыполнитьИнициализацию();\n...\n\n#КонецОбласти\nангл.
#Region Initialize\n\nSupportEmail = \"v8@1c.ru\";\nCtor();\n...\n\n#EndRegion\n\n
Для оформления разделов кода в виде областей рекомендуется воспользоваться приложенной обработкой.
\n\n\n\n\n\n2.5.6. При разработке конфигураций разделы и подразделы оформляются в виде областей. Правила и примеры оформления разделов и подразделов приведены в статье «Структура модуля» документа \"Система стандартов и методик разработки конфигураций для платформы «1С:Предприятие 8», опубликованном на диске ИТС.
", "type": "BUG" }, { "engineId": "acc", "ruleId": "93 : Представление объекта и списка", "name": "Не заполнено ни представление объекта, ни представление списка (93)", "severity": "CRITICAL", "description": "\nОбласть применения: управляемое приложение.
Если для объекта метаданных определены свойства пользовательского представления, они заполняются следующим образом.
1. Синоним объекта должен быть определен так, чтобы осмысленно, лаконично описывать объект. Заполняется обязательно.
\n\nСм. также: Имя, синоним, комментарий, Тексты
2. Представление объекта (для регистра - представление записи). Задается название объекта в единственном числе, например, \"Валюта\". Название должно быть лаконичным и понятным. Например, вместо \"Версия проверяемой конфигурации\" нужно использовать \"Версия\".
\nПредставление объекта заполняется в случае, если синоним не может быть использован, как название объекта в единственном числе.
3. Расширенное представление объекта (для регистра - расширенное представление записи). Задается полное название объекта в единственном числе. Заполняется в случае, когда название объекта, заданное в представлении объекта (или, если не заполнено, то - в синониме) менее информативно, чем его полное название. Например, в расширенном представлении объекта указано \"Реализация товаров и услуг\", в то время как в представлении объекта указано \"Реализация\".
4. Представление списка. Задается название объектов во множественном числе, например, \"Валюты\". Кроме этого, в некоторых случаях может указываться название списка, если оно является самостоятельным термином, например, «Классификатор единиц измерения». Название должно быть лаконичным и понятным. Например, вместо \"Общероссийский классификатор основных фондов\" нужно использовать \"Классификатор ОКОФ\".
Заполняется в случае, если синоним не может быть использован, как название списка объектов.
5. Расширенное представление списка. Задается полное название списка объектов. Заполняется в случае, когда заданное в представлении списка (или, если не заполнено, то в синониме) название списка менее информативно, чем полное название списка.
Например, в расширенном представлении списка указано \"Номенклатура (товары и услуги)\", представление списка не заполнено, а в синониме указано \"Номенклатура\".
6. Расширенное представление. Задается полное название объекта метаданных. Заполняется в случае, когда заданное в синониме название объекта менее информативно, чем его полное название.
Например, синоним обработки - \"Клиент банка\", а расширенное представление - \"Клиент банка (обмен платежными документами)\".
7. Пояснение. Задается пояснение по назначению данного объекта метаданных. Пояснение задается в виде законченных предложений. Заполняется для объектов метаданных, представление которых не достаточно точно передает их назначение.
Например, для справочника \"Организации\" пояснение может быть задано так: \"Юридические лица и предприниматели нашей компании.\".
8. Картинка. Задается для подсистем верхнего уровня с установленным флажком \"Включать в командный интерфейс\". Размер картинки: 32 на 32.
\nОбласть применения: управляемое приложение.
1. Для свойства История выбора большинства объектов метаданных должно быть установлено значение Авто.
\n2.1. Историю выбора в свойствах объекта метаданных рекомендуется отключать, если ее использование не соответствует прикладной логике конфигурации:
\n\n\n• для объектов, сценарий использования которых не предполагает повторный выбор из 5 ранее выбранных вариантов.
\nПримеры:
\n\n\nСпецифика использования большинства документов такова, что повторный их выбор маловероятен, например, выбор объекта расчетов в Поступлении безналичных денежных средств.
• для объектов, в модуле менеджера которых переопределена обработка получения данных выбора (есть обработчик ОбработкаПолученияДанныхВыбора), т.к. прописанные там условия не учитываются механизмом составления списка истории выбора. Поэтому, используя историю выбора в этом случае, пользователь может получить возможность выбрать значение, которое он не мог бы выбрать другими способами.
2.2. После отключения истории выбора в свойствах объекта метаданных необходимо, во всех ссылающихся на него полях ввода, установить для следующих свойств указанные ниже значения:
\n\n\n• КнопкаВыпадающегоСписка – Нет
• КнопкаВыбора – Да
• ОтображениеКнопкиВыбора – В поле ввода
Это необходимо сделать, чтобы пользователю перед началом выбора в поле ввода не отображалось меню, в котором нужно всегда нажимать «Показать все».
Например:
\n
| Правильно | \nНеправильно |
\n
Исключения:
\nМожно не изменять значения свойств полей ввода если:
\n\n\n\n• для поля ввода установлен режим выбора из списка и заполнен (или в метаданных или программно) список выбора
• поле ввода ссылается на объект метаданных с установленным свойством Быстрый выбор
Для автоматического изменения свойств полей выбора можно воспользоваться приложенной обработкой.
", "type": "BUG" }, { "engineId": "acc", "ruleId": "108 : Для всех документов рекомендуется создавать реквизит Комментарий", "name": "Документ не имеет реквизита \"Комментарий\" (108)", "severity": "INFO", "description": "\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
Методическая рекомендация (полезный совет)
\n1. Для всех документов рекомендуется создавать реквизит Комментарий (строка неограниченной длины). В этом реквизите пользователи могут записывать по документу различные заметки служебного характера, которые не относятся к прикладной специфике документа (например, причина пометки на удаления и т.п.). Доступ к реквизиту для пользователей должен быть настроен также как и к самому документу (если документ доступен только для чтения, то и комментарий – только для чтения; если же есть право записи документа, то и значение реквизита также можно изменять).
\n2. Если же штатный сценарий работы пользователя предусматривает внесение произвольной текстовой информации в документ, то для этого необходимо предусмотреть отдельные реквизиты «прикладного» характера. Например, в документе Заказ клиента для описания дополнительных договоренностей с клиентом следует предусмотреть реквизит Дополнительная информация, а не пользоваться служебным реквизитом Комментарий.
\n3. В простейшем случае, в качестве внешнего редактора текста комментария рекомендуется использовать функцию ВвестиСтроку. При использовании в конфигурации Библиотеки стандартных подсистем можно воспользоваться специализированной процедурой ПоказатьФормуРедактированияКомментария общего модуля ОбщегоНазначенияКлиент.
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. Если в модулях конфигурации встречаются строки, предназначенные для пользовательского интерфейса (сообщения пользователю, надписи в формах, названия и подсказки команд, выражения в настройках СКД и т.п.) необходимо обеспечить возможность локализации таких строк.
\nДля этого необходимо применять функцию НСтр вместо прямого использования строковых литералов. Иное использование строк, предназначенных для пользовательского интерфейса, не допускается.
\nНапример, неправильно:
ПоказатьПредупреждение(, \"Для выполнения операции необходимо установить расширение работы с файлами.\");\n
Правильно:
ПоказатьПредупреждение(, НСтр(\"ru='Для выполнения операции необходимо установить расширение работы с файлами.'\"));\n
Также следует обращать внимание на корректное использование функции НСтр.
\nНапример, неправильно:
\nТекстСообщения = \"ru='Для выполнения операции необходимо установить расширение работы с файлами.'\";\nПоказатьПредупреждение(, НСтр(ТекстСообщения));\n
Правильно:
ТекстСообщения = НСтр(\"ru='Для выполнения операции необходимо установить расширение работы с файлами.'\");\nПоказатьПредупреждение(, ТекстСообщения);\n
2. В том случае если строка является составной и включает в себя части, зависящие от тех или иных условий, тем не менее, следует использовать логически завершенные, целостные фразы (предложения). Необходимо применять функцию СтрШаблон (или аналогичную) для подстановки параметров в строки сообщений пользователю.
\nЭто требование обусловлено, во-первых, разным расположением параметров в тексте предложения на различных языках, что приводит к необходимости изменения исходного кода для перестановки складываемых фрагментов строк, а во-вторых, невозможностью корректно перевести отдельные несогласованные части предложения (наличие или отсутствие артиклей, предлогов, разное расположение знаков препинания в тексте предложения на различных языках и т.п.).
\nНеправильно:
\nСообщениеОНехватке = \"Не хватает товара \" + НаименованиеТовара + \" на складе \" + НаименованиеСклада + \".\";\n
Правильно:
ТекстСообщения = НСтр(\"ru = 'Не хватает товара %1 на складе %2.'\");
СообщениеОНехватке = СтрШаблон(ТекстСообщения, НаименованиеТовара, НаименованиеСклада);\n
Также с помощью параметров подстановки не следует разрывать целостную фразу на отдельные логически незавершенные части. Вместо этого следует задавать в коде несколько строк со всеми вариантами фразы.
\nНеправильно:
НСтр(\"ru = '%1 пользователя \"\"%2\"\" в группу \"\"%3\"\"?'\") // где параметр %1 может принимать слова \"Включить\", \"Копировать\" или \"Удалить\".\n
Правильно:
НСтр(\"ru = 'Включить пользователя \"\"%2\"\" в группу \"\"%3\"\"?'\")
НСтр(\"ru = 'Копировать пользователя \"\"%2\"\" в группу \"\"%3\"\"?'\")
НСтр(\"ru = 'Удалить пользователя \"\"%2\"\" в группу \"\"%3\"\"?'\")\n
В то же время допустимым является:
\nВ связи со сложившейся практикой, допускается использовать именованные параметры подстановки (параметры, включающие имя аналогично переменной, а не номер) только в двух вариантах: [Параметр], %Параметр%. Здесь Параметр должен удовлетворять требованиям стандарта Правила образования имен переменных.
\nПравильно:
\nСообщениеОНехватке = НСтр(\"ru='Не хватает товара %Товар% на складе %Склад%.'\") \nСообщениеОНехватке = СтрЗаменить(СообщениеОНехватке, \"%Товар%\", НаименованиеТовара); \nСообщениеОНехватке = СтрЗаменить(СообщениеОНехватке, \"%Склад%\", НаименованиеСклада);\n
3. При использовании в конфигурации Библиотеки стандартных подсистем для составных форматированных строк вместо объекта ФорматированнаяСтрока следует применять функцию ФорматированнаяСтрока общих модулей СтроковыеФункции или СтроковыеФункцииКлиент.
\nНеправильно:
Текст = Новый Массив; \nТекст.Добавить(НСтр(\"ru = 'Перед удалением расширения рекомендуется'\")); \nТекст.Добавить(\" \"); \nТекст.Добавить(Новый ФорматированнаяСтрока(НСтр(\"ru = 'выполнить резервное копирование информационной базы.'\"), ШрифтыСтиля.ПолужирныйШрифт); \nТекстПредупреждения = Новый ФорматированнаяСтрока(Текст);\n\n
Правильно:
\nТекстПредупреждения = СтроковыеФункцииКлиент.ФорматированнаяСтрока(НСтр(\"ru = 'Перед удалением расширения рекомендуется <b>выполнить резервное копирование информационной базы</b>.'\");
\n4. В функции НСтр строка ограничивается символами одинарных кавычек. Такое требование обусловлено частым использованием двойных кавычек в строковых литералах, а также встроенным в платформу механизмом редактирования строк на разных языках.
\nНеправильно:
\nПоказатьПредупреждение(, НСтр(\"ru=Переменная типа \"\"Строка\"\"\")); \nПоказатьПредупреждение(, НСтр(\"ru=\"\"Переменная типа \"\"Строка\"\"\"\"\"));\n
Правильно:
ПоказатьПредупреждение(, НСтр(\"ru='Переменная типа \"\"Строка\"\"'\"));\n
5. При использовании функций ЧислоПрописью, ПредставлениеПериода, СтрокаСЧислом не следует указывать параметр \"Л=\"(\"L=\") в строке форматирования. \n
Неправильно:
СуммаПрописью = ЧислоПрописью(2341.56, \"Л = ru_RU; ДП = Истина\", НСтр(\"ru='доллар,доллара,долларов,м,цент,цента,центов,м,2'\")); \nПравильно:
СуммаПрописью = ЧислоПрописью(2341.56, \"ДП = Истина\", НСтр(\"ru='доллар,доллара,долларов,м,цент,цента,центов,м,2'\")); \n6. В редких случаях, например, когда нужно собрать длинное сообщение с предоставлением лога действий пользователя, допускается применять не замену строк в строке-шаблоне, а сложение строк. При этом неязыковые символы (чаще перенос строки) в начале и конце строк необходимо выделять в отдельные строковые литералы (которые пропускаются при переводе).
\nНеправильно:
\nТекстСообщения = НСтр(\"ru = 'Не удалось сохранить файл документа по причине:\n |'\")\n + ИнформацияОбОшибке;\n
Правильно:
\nТекстСообщения = НСтр(\"ru = 'Не удалось сохранить файл документа по причине:'\")\n + Символы.ПС + ИнформацияОбОшибке;\n
В противном случае, при переводе строки на другой язык концевой пробел легко может быть не замечен переводчиком, так как переводчик не видит всего контекста, а только сводную таблицу строк, подлежащих переводу. Кроме того, может быть искажена при переводе фраза, так как её продолжение переводчику не видно и нет символа шаблона подстановки, поясняющего, что дальше будет продолжение.
\n7. При вызове метода ПоказатьВопрос с указанием кнопок диалога в параметре Кнопки:
• следует по возможности использовать системное перечисление КодВозвратаДиалога;
• Если в перечислении нет нужной кнопки, вместе со значением, связанным с кнопкой, следует задавать его представление с использованием функции НСтр.
Например, неправильно:
Кнопки = Новый СписокЗначений;\nКнопки.Добавить(\"Отключить\");\nКнопки.Добавить(\"Нет\");\nПоказатьВопрос(..., Кнопки);\n\n
Правильно:
Кнопки = Новый СписокЗначений;\nКнопки.Добавить(\"Отключить\", НСтр(\"ru='Отключить'\"));\nКнопки.Добавить(КодВозвратаДиалога.Нет);\nПоказатьВопрос(..., Кнопки);\n\n
См. также
\n\n\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. В некоторых случаях строковые литералы из текстов запросов также могут оказаться частью пользовательского интерфейса. В таких случаях строковые литералы необходимо выносить из текста запроса в параметры.
\nНеправильно:
ЗапросПоВерсиям = Новый Запрос(\" \n |ВЫБРАТЬ \n |Версии.Ссылка, \n |ВЫБОР КОГДА Версии.Выпущена = ИСТИНА \n | ТОГДА \"\"выпущена\"\" \n | ИНАЧЕ \"\"в разработке\"\" \n |КОНЕЦ КАК ТекстПояснения \n | ИЗ \n | Справочник.Версии КАК Версии\");\n
Также неправильно:
ТекстЗапроса = \n \"ВЫБРАТЬ\n |Версии.Ссылка,\n |ВЫБОР КОГДА Версии.Выпущена = ИСТИНА\n | ТОГДА &ТекстВыпущеннойВерсии\n | ИНАЧЕ &ТекстНеВыпущеннойВерсии\n |КОНЕЦ КАК ТекстПояснения\n | ИЗ\n | Справочник.Версии КАК Версии\");\n \n ТекстЗапроса = СтрЗаменить(ТекстЗапроса, \"&ТекстВыпущеннойВерсии\", НСтр(\"ru='выпущена'\"));\n ТекстЗапроса = СтрЗаменить(ТекстЗапроса, \"&ТекстНеВыпущеннойВерсии\", НСтр(\"ru='в разработке'\"));\n
Правильно:
ЗапросПоВерсиям = Новый Запрос(\" \n |ВЫБРАТЬ \n |Версии.Ссылка, \n |ВЫБОР КОГДА Версии.Выпущена = ИСТИНА \n | ТОГДА &ТекстВыпущеннойВерсии \n | ИНАЧЕ &ТекстНеВыпущеннойВерсии \n |КОНЕЦ КАК ТекстПояснения \n | ИЗ \n | Справочник.Версии КАК Версии\"); \n\nЗапросПоВерсиям.УстановитьПараметр(\"ТекстВыпущеннойВерсии\", НСтр(\"ru='выпущена'\")); \nЗапросПоВерсиям.УстановитьПараметр(\"ТекстНеВыпущеннойВерсии\", НСтр(\"ru='в разработке'\"));\n
2. Аналогичные требования предъявляются к выражениям СКД и запросам, которые используются в наборах данных СКД и содержат строковые литералы, выводимые в пользовательском интерфейсе. Например, если в выражении для параметров СКД встречаются строковые константы, требующие перевода, то следует:
\nа) в запросе указывать строковые константы, соответствующие \"Правилам образования имен переменных\" (\"\"ЗавершитеСозданиеДокументов\" КАК Рекомендация \"), а в списке доступных значений поля указать локализуемый строковый литерал (\"Завершите создание документов\");
б) либо значение таких параметров с помощью функции НСтр устанавливать не в колонке Выражение, а в модуле отчета в обработчике события ПриКомпоновкеРезультата
\nНеправильно:
ВЫБОР\n КОГДА ВидОперации = \"Отгрузка клиентам\" ТОГДА 1\n КОГДА ВидОперации = \"Возвраты товаров от клиентов\" ТОГДА 2\n КОГДА ВидОперации = \"Приемка от поставщиков\" ТОГДА 3\nКОНЕЦ\n
Правильно:
ВЫБОР\n КОГДА ВидОперации = &ВидОперацииОтгрузкаКлиентам ТОГДА 1\n КОГДА ВидОперации = &ВидОперацииВозвратыТоваровОтКлиентов ТОГДА 2\n КОГДА ВидОперации = &ВидОперацииПриемкаОтПоставщиков ТОГДА 3\nКОНЕЦ\n
в) В выражениях, используемых в настройках СКД, например Выражение представления и Выражение упорядочивания на закладке Наборы данных, а также в других им подобных, необходимо использовать функцию НСтр, аналогично тому, как это делается в коде модулей (см. стандарт Интерфейсные тексты в коде: требования по локализации).
\nНеправильно:
Выбор Когда Объект = Раздел \n Тогда Выбор \n Когда Раздел = Значение(ПланВидовХарактеристик.РазделыДатЗапретаИзменения.ПустаяСсылка) \n Тогда \"<Для всех разделов и объектов, кроме указанных>\" \n Иначе \"<Для всех объектов, кроме указанных>\" \n Конец \n Иначе Объект \nКонец\n\n
Правильно:
Выбор Когда Объект = Раздел \n Тогда Выбор \n Когда Раздел = Значение(ПланВидовХарактеристик.РазделыДатЗапретаИзменения.ПустаяСсылка) \n Тогда НСтр(\"ru='<Для всех разделов и объектов, кроме указанных>'\")\n Иначе НСтр(\"ru='<Для всех объектов, кроме указанных>'\")\n Конец \n Иначе Объект \nКонец\n\n
3. Для колонок отчета на СКД для поля выборки, полученного вычислением с заданием ему псевдонима, необходимо задавать синоним при разработке. Нельзя опираться на автоматически сгенерированный заголовок по имени/псевдониму.
\nНеправильно:
Правильно:
В отчётах, если не стоит галочка у поля выборки, полученного вычислением с заданием ему псевдонима, оно не попадает в результаты поиска редактирования текстов интерфейсов.
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. В данном обработчике модуля объекта, как правило, должны выполняться действия, которые необходимо выполнить перед удалением объекта. Например, перед удалением присоединенного файла может потребоваться произвести очистку ссылок на этот файл в объекте-владельце.
\n2. Все действия в процедуре-обработчике события ПередУдалением должны выполняться после проверки на ОбменДанными.Загрузка.
\nТ. е. они не должны выполняться перед удалением объекта через механизм обмена данными, так как это может привести к ошибкам. Примером таких ошибок является обращение к предопределенным объектам после очистки области данных.
\n\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. В данном обработчике модуля объекта, как правило, должны выполняться действия, связанные с заполнением значений реквизитов объекта (набора записей, значения константы; далее упрощенно - \"объект\"), проверки правильности их заполнения, связанности состояния объекта с некоторыми внешними данными. Также в данном обработчике следует выполнять действия, связанные с обращением к \"старым\" значениям реквизитов объекта, сохраненным в базу данных (имеет смысл при редактировании уже записанных ранее объектов, наборов записей и т.п.).
\n\n\n
2. Все действия в процедуре-обработчике события ПередЗаписью должны выполняться после проверки на ОбменДанными.Загрузка.
\n\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. В данном обработчике модуля объекта (набора записей, значения константы; далее - \"объект\"), как правило, выполняются действия по записи связанной с объектом данных в других объектах конфигурации, а также выполняются другие действия, связанные с изменением объекта.
Запрещается в данном обработчике изменять содержимое записываемого объекта, поскольку на момент выполнения обработчика, объект уже записан в БД.
2. Все действия в процедуре-обработчике события ПриЗаписи должны выполняться после проверки на ОбменДанными.Загрузка.
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. Все действия в процедурах-обработчиков событий ПередЗаписью, ПриЗаписи, ПередУдалением должны выполняться после проверки на ОбменДанными.Загрузка:
\nПроцедура ПередЗаписью(Отказ)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// код обработчика
// ...
КонецПроцедуры
Это необходимо для того, чтобы никакая бизнес-логика объекта не выполнялась при записи объекта через механизм обмена данными, поскольку она уже была выполнена для объекта в том узле, где он был создан. В этом случае все данные загружаются в ИБ «как есть», без искажений (изменений), проверок или каких-либо других дополнительных действий, препятствующих загрузке данных.
\nКроме механизма обмена данными есть и другие случаи, когда это должно быть так. В общем виде следует руководствоваться следующим подходом: механизмы, не рассчитанные на особенности конкретных конфигураций, должны иметь возможность загрузить данные при установленном флаге загрузки так, как будто текста обработчика нет вообще:
\nОбъект.ОбменДанными.Загрузка = Истина;
Объект.Записать();
Например, требуется загрузить всю базу из XML «как есть». Для этого должно быть достаточно установить записываемым объектам ОбменДанными.Загрузка = Истина и все данные должны загрузиться без искажений, проверок и дополнительных действий, т. е. так же как и при пустом обработчике.
\n2. Исключение составляет механизм обмена данными, который в ходе загрузке данных в базу регистрирует эти данные к выгрузке на других узлах плана обмена.
\nВ тех случаях, когда в конфигурации используется подсистема «Обмен данными» БСП, и возникла необходимость отключить ее, следует устанавливать дополнительное свойство ОтключитьМеханизмРегистрацииОбъектов:
\nОбъект.ОбменДанными.Загрузка = Истина;
Объект.ДополнительныеСвойства.Вставить(\"ОтключитьМеханизмРегистрацииОбъектов\");
Объект.Записать();
В случае других исключений, причина исключения из этого правила должна быть описана в комментарии к выполняемым действиям.
\n3. Требования выше также распространяются на обработчики подписок на эти события.
\n4. При этом вызывающая сторона, выставляя записываемому объекту признак ОбменДанными.Загрузка в Истина, берет на себя ответственность за целостность данных этого объекта.
\nНапример, при записи объекта через механизм обмена данными в РИБ это обеспечивается корректным состоянием объекта в том узле, где он был создан (или изменен).
\nВ других случаях вызывающая сторона должна принять меры по корректному заполнению записываемого объекта. Например, при загрузке данных через механизм обмена данными по правилам конвертации или с помощью формата EnterpriseData, следует выполнять все необходимые действия по (до)заполнению объекта. Эти действия рекомендуется размещать в экспортных процедурах самого объекта, которые используются вызывающей стороной при записи объекта в режиме обмена данными.
", "type": "BUG" }, { "engineId": "acc", "ruleId": "327 : Проверка использования транзакций", "name": "Нарушена схема работы с транзакциями: для вызова \"НачатьТранзакцию()\" отсутствует парный вызов \"ОтменитьТранзакцию()\" (327)", "severity": "CRITICAL", "description": "\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
Транзакции применяются для целостного изменения связанных данных, т.е. все действия с базой данных, выполняемые в рамках транзакции или выполняются целиком, или целиком откатываются.
\n1. Использование транзакций в 1С:Предприятии обладает рядом особенностей:
\nЭти особенности накладывают ряд требований к написанию кода с использованием транзакций. Несоблюдение этих требований может приводить к возникновению ошибок вида «В этой транзакции уже происходили ошибки», которые может быть крайне сложно воспроизвести и отладить.
\n1.1. Поскольку исключение не отменяет транзакцию сразу, но запрещает успешное завершение транзакции, то все вызовы НачатьТранзакцию с одной стороны и ЗафиксироватьТранзакцию или ОтменитьТранзакцию с другой стороны должны быть парными.
\n1.2. Начало транзакции и ее фиксация (отмена) должны происходить в контексте одного метода
\nПравильно
\nПроцедура ЗаписатьДанныеВИБ()
\nНачатьТранзакцию();
\n Попытка
... // чтение или запись данных
ДокументОбъект.Записать()
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
... // дополнительные действия по обработке исключения
КонецПопытки;
КонецПроцедуры
\nНеправильно
\nПроцедура ЗаписатьДанныеВИБ()
НачатьТранзакцию();
ЗаписатьДокумент();
КонецПроцедуры;
\nПроцедура ЗаписатьДокумент()
\n Попытка
... // чтение или запись данных
ДокументОбъект.Записать()
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
... // дополнительные действия по обработке исключения
КонецПопытки;
КонецПроцедуры
\n1.3. При использовании транзакций необходимо предусмотреть обработку исключений, придерживаясь следующих правил:
\nПример
\nНачатьТранзакцию();
Попытка
БлокировкаДанных = Новый БлокировкаДанных;
ЭлементБлокировкиДанных = БлокировкаДанных.Добавить(\"Документ.ПриходнаяНакладная\");
ЭлементБлокировкиДанных.УстановитьЗначение(\"Ссылка\", СсылкаДляОбработки);
ЭлементБлокировкиДанных.Режим = РежимБлокировкиДанных.Исключительный;
БлокировкаДанных.Заблокировать();
... // чтение или запись данных
ДокументОбъект.Записать();
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ЗаписьЖурналаРегистрации(НСтр(\"ru = 'Выполнение операции'\"),
УровеньЖурналаРегистрации.Ошибка,
,
,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
ВызватьИсключение; // есть внешняя транзакция
\nКонецПопытки;
\n1.4. Использование вложенных транзакций приводит к усложнению кода. Принимая решение об использовании этой возможности, нужно очень взвешенно оценить решаемую задачу: возможно, это усложнение просто не оправдано.
\n1.4.1. Не стоит усложнять код, явно используя метод НачатьТранзакцию, когда кроме записи объекта другие действия c базой данных не делаются – платформа при записи сама откроет транзакцию.
\nНе нужно явно открывать транзакцию тогда, когда не требуется выполнять ответственное чтение данных. Например, обычно ответственное чтение не требуется при записи нового объекта (нового набора записей регистра).
\nПри использовании методов ПолучитьОбъект (или Прочитать для наборов записей) необходимо анализировать должно ли чтение быть отвественным и в зависимости от этого принимать решение о явном использовании метода НачатьТранзакцию.
\nПравильно
\nПопытка
ДокументОбъект = Документы.ПриходнаяНакладная.СоздатьДокумент();
... // действия по заполнению объекта
ДокументОбъект.Записать();
Исключение
... // действия по обработке исключения
КонецПопытки;
Неправильно
\nНачатьТранзакцию();
Попытка
ДокументОбъект = Документы.ПриходнаяНакладная.СоздатьДокумент();
... // действия по заполнению объекта
ДокументОбъект.Записать();
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
КонецПопытки;
1.4.2. Если метод рассчитан на вызов только в рамках уже открытой транзакции (например, метод предназначен для вызова только из событий ПередЗаписью, ОбработкаПроведения и т.п.) в общем случае явным образом открывать в нем транзакцию не имеет никакого практического смысла.
\n1.4.3. При необходимости повысить качество сообщений об ошибках – на каждом уровне разработчик может предусмотреть свою обработку исключений, для чего, возможно, потребуется открыть вложенную транзакцию.
\nПример
\nВызывается метод ДобавитьЭлектроннуюПодпись. Внутри, если что-то пошло не так, нужно обработать исключение и добавить текст вида: «Не удалось добавить электронную подпись к объекту %ПредставлениеОбъекта% по причине:%ОписаниеОшибки%». В противном случае исключение будет обработано выше по стеку вызовов, например, при записи файла и будет выдано сообщение вида: «Не удалось записать файл %ИмяФайла% по причине: %ОписаниеОшибки%», где в «%ОписаниеОшибки%», будет просто указание на строчку кода и пользователю будет не понятно, зачем вообще программа записывала файл, если он просто его подписывал.
\n1.4.4. При обработке исключения, если транзакция все еще активна, например, исключение возникло во вложенной транзакции, нельзя обращаться к базе данных, так как это приведет к исключению «В этой транзакции уже происходили ошибки». При этом нужно учитывать, что обращение к базе данных может быть неявным, например, для получения представления ссылки.
\n2. Ограничение на длину транзакции.
\n2.1. В общем случае в рамках одной транзакции нужно выполнять только те действия, которые неделимы, исходя из бизнес-логики.
\nПример
\nПри проведении документа записывается документ и его движения в регистрах. Если не прошла запись хотя бы в один регистр вся операция проведения должна быть отменена.
\n2.1.1. Если с точки зрения бизнес-логики действия могут быть выполнены по отдельности, то их в общем случае не следует объединять в одну транзакцию.
\n2.1.2. Исключением из п.2.1.1 могут быть случаи, когда с целью оптимизации несколько несвязанных объектов обрабатываются в рамках одной транзакции. В этом случае необходимо взвешенно подходить к выбору порции обработки данных: нужно стремиться к достижению золотой середины между длительностью одной транзакции и объемом фиксируемых данных с одной стороны и количеством транзакций с другой.
\n2.2. Следует избегать транзакций, которые выполняются длительное время.
\nПример
\nНеправильно
\nДля загрузки адресного классификатора ФИАС записывать все данные, относящиеся к одной версии классификатора в одной транзакции, для того, чтобы в случае ошибки откатить целиком загружаемую версию классификатора.
\nТ.к. данных по одной версии классификатора много (объем около 1 Гб), то для выполнения такой транзакции, во-первых, может не хватить оперативной памяти (особенно при использовании файловой информационной базы на 32-разрядной ОС), а, во-вторых, такая операция будет выполняться достаточно долго и ее нельзя будет оптимизировать за счет выполнения в несколько потоков.
\nПравильно
\nРазбить загрузку новой версии классификатора ФИАС на небольшие транзакции и реализовать функциональность по откату к предыдущей версии в случае ошибки.
\nСм. также Особенности использования транзакций при обмене данными
\n2.2.1 Чем дольше выполняется транзакция, тем большее время будут заняты ресурсы сервера 1С:Предприятия и СУБД. Как правило длинные транзакции занимают следующие ресурсы:
\nВсе это в целом может снижать эффективность использования ресурсов.
\n2.2.2. Если две транзакции пересекаются по блокируемым ресурсам, то транзакция, которая начала выполняться позже, будет ожидать возможность установления блокировки ограниченное время (по умолчанию – 20 секунд), после чего будет завершена с исключением «Превышено время ожидания установки блокировки». Поэтому длинные транзакции могут сильно снижать удобство параллельной работы пользователей.
\nВозникновение таких исключений – это повод провести анализ действий, которые выполняются в конфликтующих транзакциях
\n2.3. В рамках транзакции нужно стремиться выполнять минимум действий – только те, которые нельзя в соответствии с бизнес-логикой выполнять вне транзакции. В частности:
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. Нельзя присваивать реквизитам, используемым в элементах формы, строковые значения, не прошедшие локализацию. Рекомендуется для этого использовать, списки значений, в которых для каждого значения задается локализуемое представление, или перечисления, если они используются в таблицах базы данных.
\nНеправильно:
\nЕсли Режим = \"Рабочий\" Тогда\n\u0009Режим = \"Демо\";\nИначе\n\u0009Режим = \"Рабочий\";\nКонецЕсли;\n
Правильно:
Правильно:
\nЕсли Режим = Перечисления.РежимыРаботы.Рабочий Тогда\n\u0009Режим = Перечисления.РежимыРаботы.Демо;\nИначе\n\u0009Режим = Перечисления.РежимыРаботы.Рабочий;\nКонецЕсли;
Методическая рекомендация (полезный совет)
\n2. Для всех таблиц и групп на формах необходимо указывать заголовки, и, если эти заголовки не нужно показывать пользователю, в свойствах элемента формы в явном виде убирать отображение заголовка элемента.
\nЭто требование связано с тем, что, если заголовок не указан, при использовании команды Изменить форму пользователь увидит заголовки, автоматически сгенерированные из имен элементов формы, а перевести их будет невозможно, потому что такие заголовки попадут в выгрузку на перевод как пустые, и переведены не будут.
\nНеправильно:
Правильно:
\n
Для автоматической расстановки заголовков можно воспользоваться обработкой автоформатирования кода и локализации.
3. Следует уменьшать количество незначащей информации, подлежащей локализации.
\n3.1. Удалять бессмысленные подсказки у групп форм. См. стандарт Подсказка и проверка заполнения.
\nЭто связано не только со стремлением удешевить перевод, но и с тем, что пользователь может увидеть такие подсказки, например, когда будет изменять форму.
\nНеправильно:
Правильно:
3.2. У реквизитов формы, не размещенных на форме в виде элементов управления, следует очищать заголовки, т.к. они не видны пользователю. Как правило, это служебные реквизиты, используемые для технологических целей.
\nДля удаление бессмысленных подсказок можно воспользоваться обработкой, приложенной к статье Тексты модулей.
\n4. Следует задавать заголовок для колонок динамического списка, получающихся в запросе комбинацией других колонок или для которых задан свой псевдоним. Нельзя опираться на автоматически сгенерированный заголовок по имени/псевдониму.
\nНапример, неправильно:
Правильно:
Примеры, когда заголовок колонок следует задавать в явном виде:
\nВЫБРАТЬ
Таблица.Поле1 КАК Поле2
ВЫРАЗИТЬ(Таблица.Поле1 КАК СТРОКА(100)) КАК Поле3
В таком случае, когда поле создается в запросе и ему присваивается имя, то синоним не \"подтягивается\" автоматически из метаданных, т.к. не существует реквизита, связанного с этим полем. Инструментом редактирования текстов интерфейсов не находится заголовок для колонок в динамическом списке, которым задан псевдоним в запросе. Имя колонки динамического списка должно быть задано, даже если заголовок поля не выводится на форму, так как имена колонок выводятся пользователю при настройке полей формы (команда Еще - Изменить форму...).
\n5. В полях форм со списками выбора следует всегда устанавливать свойство РежимВыбораИзСписка в значение Истина. В этом случае, в поле будет корректно выводиться локализуемое представление, а не значение из списка выбора.
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
\n\n\n 1.1. Свойство «Подсказка». Задается для тех объектов (реквизитов объектов, реквизитов табличных частей, измерений и ресурсов регистров), которые выводятся пользователю в виде элементов интерфейса и которые требуют пояснения, расшифровки и донесения до пользователя подробного описания их назначения. Для реквизитов, используемых в ежедневной работе, подсказки добавлять не следует. \nВ тексте подсказки не рекомендуется приводить инструкции и объяснять работу реквизита, вместо этого следует оптимизировать сценарии работы, с ним связанные. \nПри этом бессмысленные подсказки, автоматические генерируемые конфигуратором при создании элементов управления (групп) на формах, нужно не забывать очищать. Например, «Группа шапка» и пр. \n\n |
2.1. Свойство «Проверка заполнения». Для всех типизированных объектов метаданных, а также для стандартных реквизитов и табличных частей, которые в соответствии с логикой объекта являются обязательными к заполнению, свойство \"Проверка заполнения\" должно быть установлено в \"Выдавать ошибку\".
В ряде случаев проведение документа с незаполненными реквизитами и табличными частями не имеет смысла с точки зрения отражения документа в учете. Например, документ Заказ клиента является запросом клиента на поставку определенного количества товара. Из определения понятно, что методически заказ с незаполненным клиентом и незаполненной табличной частью Товары не имеет смысла, поэтому у реквизита Клиент и табличной части Товары свойство \"Проверка заполнения\" должно быть установлено в \"Выдавать ошибку\".
2.2. При установке свойства «Проверка заполнения» следует исходить из того, что все ограничения и проверки должны быть (насколько это возможно полно) описаны в метаданных конфигурации. Поэтому если хотя бы один из сценариев работы с объектом требует обязательного заполнения реквизита, то свойство «Проверка заполнения» устанавливается в «Выдавать ошибку». Если в других сценариях работы заполнять реквизит не обязательно, то такие случаи должны быть предусмотрены в обработчике события модуля объекта ОбработкаПроверкиЗаполнения.
\nПри этом не следует придерживаться обратной схемы, когда свойство «Проверка заполнения» установлено в «Не проверять», а в обработчике ОбработкаПроверкиЗаполнения дописаны какие-либо проверки заполнения. Такая схема затрудняет анализ логики работы конфигурации.
\n2.3. Если проверка заполнения реквизита зависит от тех или иных условий, рекомендуется управлять автопометкой незаполненного значения с помощью условного оформления форм объектов. Убирать ее в случае, если при данном состоянии объекта заполнение реквизита проверять не требуется.
\n\nОбласть применения: управляемое приложение, мобильное приложение, обычное приложение.
1. Нельзя присваивать реквизитам, используемым в элементах формы, строковые значения, не прошедшие локализацию. Рекомендуется для этого использовать, списки значений, в которых для каждого значения задается локализуемое представление, или перечисления, если они используются в таблицах базы данных.
\nНеправильно:
\nЕсли Режим = \"Рабочий\" Тогда\n\u0009Режим = \"Демо\";\nИначе\n\u0009Режим = \"Рабочий\";\nКонецЕсли;\n
Правильно:
Правильно:
\nЕсли Режим = Перечисления.РежимыРаботы.Рабочий Тогда\n\u0009Режим = Перечисления.РежимыРаботы.Демо;\nИначе\n\u0009Режим = Перечисления.РежимыРаботы.Рабочий;\nКонецЕсли;
Методическая рекомендация (полезный совет)
\n2. Для всех таблиц и групп на формах необходимо указывать заголовки, и, если эти заголовки не нужно показывать пользователю, в свойствах элемента формы в явном виде убирать отображение заголовка элемента.
\nЭто требование связано с тем, что, если заголовок не указан, при использовании команды Изменить форму пользователь увидит заголовки, автоматически сгенерированные из имен элементов формы, а перевести их будет невозможно, потому что такие заголовки попадут в выгрузку на перевод как пустые, и переведены не будут.
\nНеправильно:
Правильно:
\n
Для автоматической расстановки заголовков можно воспользоваться обработкой автоформатирования кода и локализации.
3. Следует уменьшать количество незначащей информации, подлежащей локализации.
\n3.1. Удалять бессмысленные подсказки у групп форм. См. стандарт Подсказка и проверка заполнения.
\nЭто связано не только со стремлением удешевить перевод, но и с тем, что пользователь может увидеть такие подсказки, например, когда будет изменять форму.
\nНеправильно:
Правильно:
3.2. У реквизитов формы, не размещенных на форме в виде элементов управления, следует очищать заголовки, т.к. они не видны пользователю. Как правило, это служебные реквизиты, используемые для технологических целей.
\nДля удаление бессмысленных подсказок можно воспользоваться обработкой, приложенной к статье Тексты модулей.
\n4. Следует задавать заголовок для колонок динамического списка, получающихся в запросе комбинацией других колонок или для которых задан свой псевдоним. Нельзя опираться на автоматически сгенерированный заголовок по имени/псевдониму.
\nНапример, неправильно:
Правильно:
Примеры, когда заголовок колонок следует задавать в явном виде:
\nВЫБРАТЬ
Таблица.Поле1 КАК Поле2
ВЫРАЗИТЬ(Таблица.Поле1 КАК СТРОКА(100)) КАК Поле3
В таком случае, когда поле создается в запросе и ему присваивается имя, то синоним не \"подтягивается\" автоматически из метаданных, т.к. не существует реквизита, связанного с этим полем. Инструментом редактирования текстов интерфейсов не находится заголовок для колонок в динамическом списке, которым задан псевдоним в запросе. Имя колонки динамического списка должно быть задано, даже если заголовок поля не выводится на форму, так как имена колонок выводятся пользователю при настройке полей формы (команда Еще - Изменить форму...).
\n5. В полях форм со списками выбора следует всегда устанавливать свойство РежимВыбораИзСписка в значение Истина. В этом случае, в поле будет корректно выводиться локализуемое представление, а не значение из списка выбора.
\n\nОбласть применения: управляемое приложение, обычное приложение.
\n\nДействует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к использованию.
Содержит уточнения к требованиям других стандартов.
1. Общие положения
\n\n\n1.1. Роли создаются «атомарными», т.е. дающими права на доступ к элементарным функциям программы. Из этих элементарных ролей создаются профили пользователей, которые уже и назначаются пользователям средствами БСП. Деление прав на доступ к объектам между функциями должно быть таким, чтобы на типовом внедрении не возникало необходимости в создании новых ролей.
Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.
\nНапример, в УП(ERP) это роль ПартнерСамообслуживание.
\n1.2. Роль ПолныеПрава (англ. FullAccess) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.
\n1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы) не должна давать право на интерактивное удаление ссылочных объектов.
\n1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.
\n1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.
\n1.6. Если какое-то право может быть использовано только администратором системы (например, использование какого-то отчета или обработки), то достаточно, чтобы это предоставлялось одной из ролей ПолныеПрава и АдминистраторСистемы, создавать отдельные роли в этом случае не требуется.
\n1.7. Во всех документах, предполагающих проведение, должны быть выставлены флаги «Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения», поэтому не нужно создавать роли, дающие права на изменение регистров, подчиненных регистраторам.
\nИсключение: документы, предназначенные для непосредственной корректировки записей регистров, могут проводиться с проверкой прав доступа, но в этом случае необходимо предусмотреть роли, дающие права на изменение регистров.
\n1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».
\nИсключение: в конфигурации могут быть предусмотрены параметризированные ФО, для которых разработчик специально предусматривает различия в получаемых значениях пользователями с разными правами.
Пример: Есть параметризованная ФО ИспользоватьВалютуПриРасчетеСПерсоналом, которая параметризуется организацией. Если пользователь будет получать ее значение в контексте своих прав, то он не увидит поле «валюта» в документе, если у него нет ни одной организации, где применяется валютный учет.
1.9. Не должно быть ролей, кроме стандартных ролей БСП, которые дают общие права (такие как Администрирование, ТонкийКлиент и т.п.).
\n1.10. В отдельных случаях для неконфиденциальных данных и общедоступных функций не требуется создавать отдельную роль на чтение (а также просмотр и ввод по строке - для ссылочных данных), а следует включать эти права в роли БазовыеПрава<ИмяБиблиотеки> (англ. BasicAccess<LibraryName>) и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки> (англ. BasicAccessExternalUser<LibraryName>) (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями). Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.
\n1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.
2. Правила создания ролей к элементарным функциям
\n2.1. Объекты, при проектировании прав доступа, необходимо объединить в элементарные функции. Если объекты входят в одну функцию, то это означает, что не может быть задачи, когда доступ к этим объектам может быть разный.
\nПример:
Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.
Противоположный пример:
Есть документ «Реализация товаров и услуг», выступающий в роли распоряжения на отгрузку товаров. Остатки по распоряжениям на отгрузку товаров хранит регистр накопления «Товары к отгрузке». Объединять «Реализацию товаров и услуг» и регистр «Товары к отгрузке» в рамках одной функции было бы не правильно, т.к., например, кладовщик, вполне может иметь права на чтение регистра «Товары к отгрузке», но может не иметь прав на чтение документа «Реализация товаров и услуг».
2.2. В случае если возникают сомнения в том, что два объекта могут быть отнесены к одной элементарной функции, лучше выделить их в разные.
\n2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.
\n2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.
\n3. Ссылочные объекты и регистры
\n3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли
\nРоли должны содержать следующие права (когда они имеются у объекта метаданных):
\n3.2. Необходимо помнить, что для регистров, подчиненных регистратору, обычно не требуется назначать права на изменение (см. п. 1.7).
\n4. Журналы документов
\n4.1. Если все документы, входящие в журнал, отнесены к одной элементарной функции, то права на чтение и просмотр журнала нужно включить во все роли этой функции.
4.2. Платформа 1С:Предприятие имеет следующую особенность: если у пользователя нет прав на чтение любого документа, входящего в журнал документов, то платформа не дает доступ ко всем графам журнала, в котором отражается этот документ, для всех документов, входящих в журнал. Поэтому нет никакого практического смысла создавать отдельную роль для доступа к журналу: журнал может входить в элементарную функцию, или может быть доступен только пользователю с полными правами.
5. Константы
\n5.1. Если предполагается, что константа должна изменяться только администратором системы, то права на изменение и редактирование должны быть только у одной из ролей: ПолныеПрава или АдминистраторСистемы. Эти роли должны включать также и права на чтение и просмотр констант.
\n5.2. Если предполагается, что константу может менять пользователь, то нужно включить права на чтение, просмотр, изменение и редактирование в уже имеющуюся «настроечную» роль или создать отдельную роль Изменение<ИмяКонстанты> (англ. Update<ConstantName>), дающую права на чтение, просмотр, изменение и редактирование этой константы.
\n5.3. В подавляющем большинстве случаев константа используется для хранения неконфиденциальной информации, поэтому права на чтение и просмотр константы нужно назначать роли БазовыеПрава<ИмяБиблиотеки> и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки>. Это позволяет избежать неоправданной установки привилегированного режима при чтении значения константы из кода.
\n5.4. В редких случаях, когда константа используется для хранения конфиденциальной информации, необходимо создать роль Чтение<ИмяКонстанты> (англ. Read<ConstantName>). При этом, если значение должно быть доступно только администратору, создавать отдельную роль на чтение не требуется.
\nНапример, для константы ПараметрыАдминистрированияИБ создавать отдельную роль на чтение не требуется – достаточно включения прав на чтение и просмотр в роль АдминистраторСистемы.
\n6. Подсистемы, отображаемые в главном командном интерфейсе
\n6.1. Для каждой подсистемы верхнего уровня должна быть создана роль Подсистема<ИмяПодсистемы> (англ. Subsystem<SubsystemName>), дающая право на просмотр
\n6.2. Если интерфейс подсистемы организован так, что часть настроек и справочников отображаются в отдельной форме, то роль, дающая право на подсистему, должна включать права на просмотр этой формы (например, в УП(ERP) часть справочников в разделах командного интерфейса не вынесены и отображаются в форме, вызываемой командой «Настройки и справочники»).
\n7. Отчеты
\n7.1. Если отчет строится на основе данных, входящих в одну элементарную функцию (п. 2.1), то в общем случае права на доступ к такому отчету можно включить в роли, созданные по этой элементарной функции.
\nПример:
Отчет по исполнению заказов клиентов полностью строится на основе данных регистр накопления ЗаказыКлиентов, поэтому права на отчет нужно включить в роль, дающую право на чтение регистра.
7.2. Если на внедрении могут возникнуть задачи отдельной настройки прав к отчету, который строится на основе данных, входящих в одну элементарную функцию, то для доступа к такому отчету необходимо создать отдельную роль ПросмотрОтчета<ИмяОтчета> (англ. ViewReport<ReportName>), дающую права использования и просмотра.
\nПример:
Хотя отчет по контактной информации отображает данные входящие в элементарную функцию информации о клиентах, но на внедрении может потребоваться ограничить доступ к отчету, который позволяет вывести информацию по всем клиентам сразу.
7.3. Если отчет строится на основе данных, входящих в несколько элементарных функций, необходимо создать роль ПросмотрОтчета<ИмяОтчета>, дающую права использования и просмотра.
\nПример:
Отчет по выполнению плана продаж строится на основе данных о планах и данных о продажах. Права чтение этих данных дают роли, относящиеся к разным элементарным функциям. Для реализации доступа к отчету нужно создать отдельную роль.
7.4. Однотипные отчеты при проектировании прав доступа можно объединить в элементарные функции при соблюдении следующих условий:
\n8. Обработки и общие формы
\n8.1. Для каждой обработки, представляющей из себя рабочее место, т.е. в ГКИ есть отдельная команда для открытия этой обработки, должна быть создана роль ИспользованиеОбработки<ИмяОбработки> (англ. Use DataProcessor<DataProcessorName>), дающая права на просмотр и использование.
\nПри этом не допускается объединять права доступа к разным обработкам-рабочим местам в одной роли.
\n8.2. Права ко всем другим типам обработок, например
\nдолжны быть назначены в роли БазовыеПрава<ИмяБиблиотеки>.
\n8.3. Права к обработкам, предназначенным исключительно для администратора программы, нужно назначать только роли ПолныеПрава, не создавая отдельных ролей для таких обработок.
8.4. Все эти правила равным образом применяются для общих форм. Название роли для общей формы, описанной в п. 8.1. – ИспользованиеОбщейФормы<ИмяОбщейФормы> (англ. UseCommonForm<CommonFormName>).
8.5 Исключения из этих правил описаны в п. 6.2
Пример:
В УТ 11 права к обработкам ПодборТоваров и ПоискОбъектовПоШтрихкоду назначены роли БазовыеПраваУТ.
9. Команды
\n9.1. Если команда не предполагает изменение данных, то в общем случае право на просмотр должно быть назначено той роли, которая дает право на просмотр объекта.
\n9.2. Если команда связана с изменением данных, то право на просмотр нужно назначить роли, которая дает права на изменение объектов.
\n10. Права, не связанные с доступом к объектам
\n10.1. В случае если возникает необходимость давать пользователям какие-то дополнительные права, не связанные с доступом к объектам, нужно создавать роль <НаименованиеПрава>, не дающую доступ ни к одному объекту. При этом в наименовании не нужно использовать слово «Право».
\nПример:
Правильно ОтклонениеОтУсловийЗакупок
Неправильно ПравоСозданияВыпускПродукцииБезЗаказа
10.2. В коде конфигурации нужно проверять наличие у пользователя этой роли. Пользователь с ролью ПолныеПрава должен проходить проверку без необходимости включения в его профиль этой роли. Для проверки следует использовать функцию БСП Пользователи.РолиДоступны.
\n10.3. Использование других механизмов, кроме проверки наличия роли (или какого-то права) при реализации дополнительных прав пользователя, не допускается.
\n11. Права для внешних пользователей
\nРоли, предназначенные исключительно для предоставления прав доступа внешним пользователям (представленным в программе одним из объектов, например, элементами справочников Сотрудники, Партнеры, Физические лица и др.), следует называть с определенным префиксом.
Например, префикс Самообслуживание для доступа к рабочему месту по самообслуживанию клиентов в торговом решении:
12. Права к устаревшим объектам
\nУстаревшие объекты метаданных с префиксом Удалить должны быть исключены из всех ролей, кроме ролей ПолныеПрава или АдминистраторСистемы.
\nОбласть применения: управляемое приложение.
\n
1. Общие рекомендации
\n
1.1. Сообщения должны быть достаточно информативными и содержательными. Сообщения составляются в форме безличного предложения: не употребляются местоимения \"Вы\", \"Вас\" и пр.
\n
| \n Правильно | \n\n Неправильно |
| \n \"Недостаточно прав для выполнения обработки\" | \n\n \"У Вас недостаточно прав для выполнения обработки\" |
1.2. Сообщения не должны содержать восклицательных знаков и повелительных тонов, за исключением сообщений, предупреждающих об опасных или критических действиях.
\n
| \n Правильно | \n\n Неправильно |
| \n \"Внимание. Загрузка базы может привести к потере всех данных\" \"Выберите элемент, а не группу\" | \n\n \"Внимание! Загрузка базы может привести к потере всех данных\" Это сообщение не акцентирует внимание пользователя на том, что последствия могут критичны
Это сообщение несет негативный настрой, а также заставляет пользователя чувствовать себя глупо |
\n
1.3. Сообщение должно быть написано текстом, понятным пользователю. В частности, оно не должно содержать технической терминологии (терминологии разработчика). Подобную терминологию допускается использовать только в сообщениях, предназначенных для администратора.
Например, если пользователь указал в качестве кассы отправителя и кассы получателя одно и то же значение, то выводится сообщение: \"Касса отправителя равна кассе получателя\".
В реальности касса не может быть равна другой – она может быть одной и той же.
\n
\n
| \n Правильно | \n\n Неправильно |
| \n \"Касса отправителя и касса получателя должны различаться\" | \n\n \"Касса отправителя равна кассе получателя\" |
1.4. Сообщения, указывающие на ошибку, должны выводиться в момент возникновения ошибки.
Например, в отчете, сдаваемом в Пенсионный фонд, указываются регистрационные номера сотрудников. Эти номера заполняются в карточке сотрудника.
Проверку правильности заполнения этого номера нужно делать в момент его ввода в карточке, а не в момент формирования отчета.
1.5. В тексте сообщений необходимо избегать двусмысленности. Категорически запрещается постановка вопроса с содержанием частиц \"не\" и \"бы\". Подобные вопросы не способны дать однозначного ответа.
\n
| \n Правильно | \n\n Неправильно |
| \n \"Удалить файл?\" | \n\n \"Не хотели бы вы удалить этот файл?\" (Да / Нет) |
1.6. В текстах сообщений не следует использовать сокращения и аббревиатуры. Исключением являются только общеупотребительные и соответствующие целевой аудитории сокращения и аббревиатуры.
Например, сокращения \"НДС\", \"МСФО\" понятны пользователям, а \"К.\" (коэффициент) – нет.
1.7. Если текст сообщения занимает несколько строк, рекомендуется составлять его таким образом, чтобы строки оканчивались на логическую паузу или завершались знаком препинания.
\n\n
Правильно Неправильно Не рекомендуется изменять значение ставки налога, Не рекомендуется изменять значение ставки налога, если\n\n
\n \n\n \n\n \n \n \n
если она уже используется в справочниках или документах.\n
она уже используется в справочниках или документах.
1.8. Следует руководствоваться принципом, что в процедурах и функциях, выполняемых в транзакции, нельзя выполнять каких-либо взаимодействий с пользователем – выводить предупреждения и вопросы.
\n1.9. Сообщения, оповещения, предупреждения или состояние не следует использовать в случае, если нужно вывести протокол, отчет или подробности о результатах выполненной операции. Для этого следует предусмотреть специальную форму.
2. Сообщение об ошибках в форме
Сообщения об ошибках в форме выводятся в панели сообщений об ошибках справа:
\n
2.1. В панели сообщений следует выводить только сообщения об ошибках. Сообщения об успешном завершении операции в панели выводить запрещается.
\n
2.2. Сообщение об ошибке по возможности должно быть привязано к полю, которое породило ошибку или позволяет исправить ее. Если сообщение нельзя привязать к тому или иному полю, то в тексте сообщения следует явно указать, что пользователю нужно сделать для того, чтобы устранить проблему.
2.3. Сообщения об ошибках должны отвечать на 3 вопроса:
Ответов на эти вопросы должно хватить пользователю, чтобы принять решение о дальнейших действиях, а также не повторить данной ошибки в будущем.
Например, пользователь пытается изменить статус документа, помеченного на удаление.
Система выдает сообщение: \"Документ \"Коммерческое предложение <номер> не проведен. Статус не изменен\"
Сообщение создает новый вопрос для пользователя: почему не изменен статус? В тексте сообщения отсутствует информация о том, что документ помечен на удаление, и что именно это является причиной возникновения ошибки.
\n\n
| \n Правильно | \n\n Неправильно |
| \n \"Невозможно изменить статус: документ \"Коммерческое предложение <номер> помечен на удаление\" | \n\n \"Документ \"Коммерческое предложение <номер> не проведен. Статус не изменен\" |
2.4. Следует учитывать, что в панели сообщений текст сообщения автоматически форматируется, а строки переносятся, сохраняя при этом свои пропорции. Поэтому текст таких сообщений не нужно разбивать на строки.
См. также: Перенос выражений
\n2.5. Сообщение должно быть как можно более кратким и понятным.
Если же поле заполнено, но неправильно, то сообщение должно быть более подробным.
Например, \"Указанного количества товара <название товара> нет на складе. Доступно: <количество доступно> <единица измерения>\".
2.6. Текст сообщения об ошибке должен содержать побудительную часть, призывающую пользователя совершить действия по исправлению ошибки.
\n\n
| \n Правильно | \n\n Неправильно |
| \n \"Укажите хотя бы одну систему налогообложения\" | \n\n \"Необходимо указать хотя бы одну систему налогообложения\" |
\n
3.1. Рекомендуется использовать оповещение для информирования пользователя о произошедших событиях без прерывания основной работы. Пользователю не обязательно реагировать на оповещение, оно выдается для информации.
Оповещение сообщает о том, что запрошенная операция (запись элемента справочника или проведение документа) выполнена.
3.2. Оповещения рекомендуется делать с гиперссылками на соответствующие объекты.
3.3. Текст и пояснение оповещения рекомендуется составлять так, чтобы они целиком помещались в окне оповещения с размерами \"по умолчанию\":
\n
4. Состояние
4.1. Рекомендуется использовать состояние для информирования о выполнении длительных процессов (занимающих более 10 секунд), чтобы у пользователей не сложилось впечатление о том, что программа \"зависла\". Выводите состояние:
· перед началом выполнения (\"Выполняется расчет. Пожалуйста, подождите…\")
· в процессе выполнения (если есть возможность)
· при завершении (\"Расчет выполнен\")
4.2. Состояние используется для длительных операций, состоящих из некоторого числа более мелких операций.
Например, при переносе файлов с жесткого диска в информационную базу можно выводить состояние для каждого переносимого файла:
\n
5. Предупреждение
5.1. Предупреждение рекомендуется использовать только в тех случаях, когда необходимо прервать работу пользователя, чтобы он ознакомился с некоторой информацией. При этом для возобновления работы пользователю не нужно принимать решений.
5.2. Не следует использовать предупреждение для информирования о начале выполнения длительных обработок. Такое сообщения следует выдавать непосредственно в форме обработки.
5.3. В тексте предупреждения следует привести законченные пояснения о последующих действиях и их последствиях.
Например, пользователь пытается заполнить цены товаров в табличной части \"Товары\" документа «Заказ клиента». Программа выдает предупреждение о невозможности выполнения этого действия:
\n\n
\n
6. Вопросы в сообщениях
6.1. Рекомендуется использовать в тех случаях, когда необходимо, чтобы пользователь принял решение, например, о продолжении начатой операции.
6.2. Вопросы рекомендуется выдавать перед выполнением:
· действий, результаты которых отменить потом невозможно
· потенциально опасных для данных пользователя действий
· массовой обработки информационной базы
· длительных процедур
6.3. Ответами на вопрос должны выступать глаголы, обозначающие последующие действия.
Например:
\n\n
\n
6.4. В сообщениях-вопросах кнопкой по умолчанию должна являться та кнопка, выбор которой наиболее безопасен для данных пользователя.
Например, при сохранении файла кнопкой по умолчанию является \"Сохранить\":
\n
\n
ВАЖНО: Чаще всего в ОС Windows кнопкой по умолчанию является первая (самая левая) кнопка. Прибегать к изменению кнопки по умолчанию рекомендуется только в исключительных ситуациях.