О предстоящем масштабном обновлении модуля антиспама в продуктах Dr.Web для Windows
«Доктор Веб» продолжает совершенствовать модуль антиспама в своих продуктах, повышая эффективность фильтрации нежелательных писем
1.1. Программный продукт, представленный на сертификацию, должен быть предназначен для тиражного распространения, и не иметь ориентации на конкретное внедрение. Это означает, что продукт должен продаваться или быть предназначен для продажи любому юридическому или физическому лицу, изъявившему желание его приобрести, или быть предназначен для бесплатного распространения, и может быть внедрен и использован без помощи специалистов организации-разработчика.
1.2. Продукт должен иметь документацию (руководство пользователя).
1.3. В руководстве пользователя должно быть в явном виде описано взаимодействие продукта с "1С:Предприятием".
1.4. Программный продукт должен использовать только штатные и документированные возможности работы с "1С:Предприятием 8".
1.5. Продукт, ориентированный на конечного пользователя, должен иметь средства установки. Средства установки, при их наличии, должны быть описаны в документации к программному продукту.
1.6. Использование логотипа "1С" в оформлении программного продукта и названия "1С" в его наименовании допускается только по специальному согласованию с фирмой "1С", например, для совместных с фирмой "1С" разработок. Использование логотипа "1C:Франчайзинг" допускается для продуктов партнеров-франчайзи. В случае успешной сертификации фирма-разработчик имеет право использовать для оформления логотип "1C:Совместимо!".
1.7. При внесении исправлений или изменений в сертифицированный продукт, связанных с изменениями в законодательстве и исправлением ошибок, разработчик обеспечивает соответствие измененного продукта требованиям, предъявляемым при сертификации. В случае внесения изменений, нарушающих требования сертификации, фирма "1С" имеет право приостановить действие сертификата. Новые редакции ранее сертифицированных продуктов, отличающиеся по функциональности от предыдущих версий, должны быть сертифицированы заново. Если в продукт не вносятся изменения, необходимые для его корректной работы в связи с изменениями в законодательстве, не исправляются критичные ошибки, не актуализируются механизмы обмена данными с актуальными версиями типовых конфигураций, фирма "1С" имеет право приостановить действие сертификата.
1.8. В заявке на сертификацию разработчик должен предоставить письменную гарантию с подписью руководителя и печатью фирмы-разработчика в том, что продукт является собственной разработкой и при разработке продукта не были нарушены чьи-либо авторские или иные права.
1.9. При включении в конфигурацию объектов, разработанных другими авторами и не являющихся разработкой фирмы "1С", от правообладателей должно быть получено официальное письменное разрешение на это использование.
1.10. Решения, созданные с использованием кода типовой конфигурации, можно распространять только пользователям, правомерно владеющим основной поставкой "1C:Предприятия 8", на основе которой создано данное тиражное решение.
2.1. Общие сведения о конфигурации.
2.1.1. Конфигурации выпускаются версиями и редакциями. Версия - исправление текущих ошибок и внесение незначительных усовершенствований. Выпуск новой версии должен обеспечиваться переходом с предыдущей версии с сохранением данных. Редакция - внесение существенных изменений в структуру учета, требующих преобразования данных. При выпуске новой редакции должен быть обеспечен переход с сохранением данных или описана процедура перехода на новую редакцию (начало работы, перенос начальных остатков и т.д.).
2.1.2. Номер версии указывается в свойствах конфигурации. Номер версии формируется по правилам, описанным в статье "Нумерация редакций и версий" документа "Система стандартов и методик разработки конфигураций для платформы "1С:Предприятие 8", опубликованном на диске ИТС.
2.1.3. Термин "типовая конфигурация" может быть использован только для конфигураций, разработанных фирмой "1С", либо локализованных по заказу фирмы "1С".
2.1.4. Конфигурация должна быть одинаково рассчитана на работу со всеми СУБД, операционными системами, веб-браузерами и различными режимами работы, которые поддерживает платформа "1С:Предприятие 8".
2.1.5. Для поддержки обратной совместимости с различными собственными и сторонними решениями, внешними обработками и отчетами, разработанными на предыдущих версиях платформы, конфигурация должна поддерживать запуск в режимах обычного приложения (толстый клиент) и внешнего соединения для администраторов (пользователей с полными правами). Отказ от поддержки запуска конфигурации в режимах обычного приложения и внешнего соединения для администраторов возможен только в отдельных, обоснованных случаях.
2.1.6. Конфигурации должны быть рассчитаны на работу в условиях, когда часовой пояс на серверном компьютере не совпадает с реальным часовым поясом пользователей информационной базы. Такой сценарий работы часто востребован в клиент-серверных информационных базах и в прикладных решениях в модели сервиса (SaaS).
2.1.7. В конфигурации должна быть предусмотрена возможность исключения случайных выходов из программы "1С:Предприятие", например, если пользователь по ошибке нажал кнопку закрытия главного окна программы. При выходе из программы необходимо задавать пользователю вопрос: "Завершить работу с программой?". Если пользователь подтверждает выход из программы - программа закрывается. Если отказывается от выхода, то он продолжает работать с программой, при этом необходимо предусмотреть возможность отключать вывод вопроса в персональных настройках пользователя.
2.1.8. При использовании в конфигурации внешних компонент, их установка должна быть интерактивной. Пользователь должен самостоятельно принять решение об установке. В диалоге установки должно быть указано, для чего нужна компонента и что не будет работать, если ее не устанавливать.
2.1.9. Если продукт является собственной разработкой, то он должен содержать соответствующую информацию в "Свойствах конфигурации". Разработчик в разделе "Представление" свойств конфигурации в строке "Адрес информации о поставщике" указывает ссылку на ресурс с информацией о своей компании, в строке "Адрес информации о конфигурации" указывает ссылку на ресурс с информацией о своем продукте, в разделе "Разработка" в строке "Поставщик" указывает наименование своей компании, в строке "Адрес каталога обновлений" указывает ссылку на ресурс с обновлениями, если такой есть.
2.2. Начальные действия при работе конфигурации.
2.2.1. В конфигурации должен быть предусмотрен механизм, автоматически определяющий как факт первого запуска конфигурации и выполняющий первоначальное заполнение информационной базы минимально необходимыми данными, так и факт первого запуска нового релиза и выполняющий необходимые изменения в базе.
2.2.2. По результатам обработки информационной базы при первом запуске конфигурации или при первом запуске нового релиза конфигурации пользователю должен быть представлен отчет об изменениях, внесенных в информационную базу. Ситуации, когда обработка не проведена в требуемом объеме, должны контролироваться конфигурацией. при этом пользователю должно выводиться предупреждение о возникновении проблемной ситуации. Для вывода подробного протокола о выполненных операциях и возникших ошибках следует использовать журнал регистрации.
2.3. Оформление объектов конфигурации.
2.3.1. Имена объектов метаданных не должны превышать 80 символов.
2.3.2. Синоним объекта метаданных обязательно заполняется. Синоним должен быть определен так, чтобы осмысленно и лаконично описывать объект.
2.3.2.1. В синонимах объектов и текстовых сообщениях пользователю должны использоваться общепринятые термины, понятные пользователю. Не должно быть сленга, искажения названий продуктов и компаний; англоязычных фраз, записанных русскими буквами; русскоязычных английскими буквами и т.п.
2.3.2.2. В случае если у объекта метаданных имеются стандартные реквизиты (стандартные табличные части), для них следует указывать синонимы, исходя из прикладного смысла каждого реквизита.
2.3.2.3. Для стандартных реквизитов Родитель и Владелец, следует всегда указывать синонимы, отличные от синонимов по умолчанию.
2.3.3. Комментарий задается только в тех случаях, когда необходимо дать участнику разработки конфигурации какие-либо пояснения по данному объекту конфигурации. Комментарий начинается с прописной буквы, точки ставятся только после сокращений.
2.3.4. Имена, синонимы, комментарии объектов метаданных, общих модулей, а также любая текстовая информация, которая выводится пользователю или предназначена для разработчика/внедренца, должны быть составлены по правилам русского языка и не содержать грамматических ошибок. В именах, синонимах и комментариях не допускается использовать букву "ё".
2.3.5. Объекты метаданных верхнего уровня, такие как Справочники, Документы, Общие модули и т.д сортируются в дереве метаданных по имени. Подчиненные объекты метаданных, такие как реквизиты, измерения, формы, располагаются в дереве метаданных в соответствии с проектной логикой.
Исключение составляют:
2.3.6. Конфигурация в целом и ее основные объекты, имеющие свойство "Справочная информация", должны иметь пользовательское описание. Для объектов справочная информация должна содержать сведения:
Cодержимое справочной информации основных объектов конфигурации должно включаться в общее описание конфигурации.
2.3.7. В конфигурации не должно быть неиспользуемых объектов метаданных (справочников, документов, разделов командного интерфейса и т.п.) и программного кода (общих модулей, процедур, функций, переменных и т.п.), который не используется ни в самой конфигурации, ни для интеграции с другими системами.
2.3.8. При использовании в конфигурации Библиотеки стандартных подсистем (БСП) следует использовать ссылки на справочник ИдентификаторыОбъектовМетаданных, который централизованно хранит ссылки на имена объектов метаданных конфигурации, автоматически отслеживает переименование, удаление и добавление объектов метаданных и позволяет избежать массовых операций по замене имен в таблицах, а также позволяет сократить размер записей таблиц, что улучшает общую производительность системы. Исключение составляют роли и подсистемы, для которых автоматически не отслеживаются переименования, и для них требуется в явном виде описать переименования. Подробней в документации по БСП.
2.3.8. В конфигурациях следует использовать "Управляемый" режим блокировок (свойство "Режим управления блокировкой данных" конфигурации устанавливается в значение "Управляемый") и учитывать особенности работы в этом режиме. В случае наличия серьезных обоснований для другого вида блокировок именно для этой конфигурации, то эту особенность и ее обоснование следует отразить в документации к конфигурации.
2.4. Интерфейсы и формы.
2.4.1. В случае использования фрагментов конфигураций, разработанных фирмой "1C", оригинальная часть конфигурации не должна отличаться по стилю оформления и написания от включенных частей типовых конфигураций.
2.4.2. Свойство "Подсказка". Задается для тех объектов (реквизитов объектов, реквизитов табличных частей, измерений и ресурсов регистров), которые выводятся пользователю в виде элементов интерфейса и которые требуют пояснения, расшифровки и донесения до пользователя подробного описания их назначения. Для реквизитов, используемых в ежедневной работе, подсказки добавлять не следует.
2.4.3. Для всех типизированных объектов метаданных, а также для стандартных реквизитов, которые в соответствии с логикой объекта являются обязательными к заполнению, свойство "Проверка заполнения" должно иметь значение "Выдавать ошибку", либо подобная проверка должна быть прописана разработчиком самостоятельно в модуле.
2.4.4. Если продукт предназначен для работы в режиме управляемого приложения, то он должен удовлетворять следующим требованиям:
2.4.4.1. Последним разделом в интерфейсе всегда должен быть раздел для администрирования, настройки и выполнения сервисных действий.
2.4.4.2. Рабочий стол является обязательным разделом и не может быть отключен.
2.4.4.3. Следующие виды форм должны быть всегда доступны пользователю в режиме "1С:Предприятия" из меню "Все функции" вне зависимости от того, размещены ли соответствующие объекты в командный интерфейс приложения или нет:
2.4.5. Если продукт предназначен для работы в обычном режиме, то он должен удовлетворять следующим требованиям:
2.4.5.1. В каждой конфигурации обязательно должны присутствовать интерфейсы "Общий" и "Полный". В интерфейсе "Общий" должны быть отображены общие для всех интерфейсов пункты меню и панели инструментов. У него снят признак "Переключаемый". У остальных интерфейсов признак "Переключаемый" устанавливается.
2.4.5.2. В меню "Сервис" обязательно должно присутствовать подменю "Переключить интерфейс" для переключения текущего интерфейса на другой. Подменю должно содержать список всех интерфейсов конфигурации, кроме "Общий", который как составная часть входит во все остальные интерфейсы.
2.4.5.3. Главное меню обеспечивает доступ ко всем формам, которые требуются пользователю для работы или сервисных функций. В подменю с большим числом элементов, группы элементов должны быть ограничены разделителями. Максимальное число элементов в одной группе не более 7. При любом положении выбора действия из главного меню, его размер должен быть таким, чтобы полностью умещаться на экране при минимальном разрешении, из расчета на которое разработана конфигурация.
2.4.5.4. Элементы диалогов форм должны быть выровнены. Это значит, что левые, правые, верхние или нижние границы любых двух расположенных рядом элементов (за исключением элементов типа "Надпись") должны располагаться на одной вертикальной или горизонтальной линии. Привязка "по умолчанию" должна обеспечивать нормальное поведение форм при изменении размеров.
2.5. Общие принципы оформления модулей.
2.5.1. Тексты модулей оформляются по принципу "один оператор в одной строке". Наличие нескольких операторов допускается только для "однотипных" операторов присваивания, например: А = 0; Б = 0; С = 0;
2.5.2. Текст модулей должен быть выровнен синтаксическим отступом. Для синтаксического отступа следует использовать табуляцию, а не пробелы, чтобы при смене числа знаков в табуляции выравнивание текста сохранялось.
2.5.3. Конфигурация не должна содержать ошибок, обнаруживаемых при синтаксическом контроле модулей.
2.5.4. Конфигурация не должна содержать ошибок, обнаруживаемых при проверке конфигурации. Кроме отдельных, обоснованных случаев (в частности, описанных в статьях Обработчики событий модуля формы, подключаемые из кода, Ограничение на установку признака "Вызов сервера" документа "Система стандартов и методик разработки конфигураций для платформы "1С:Предприятие 8", опубликованном на диске ИТС).
2.5.5. Все переменные модуля обычного приложения, модуля управляемого приложения, модуля сеанса, модуля внешнего соединения, а также все экспортируемые переменные должны иметь комментарии. Комментарии должны быть достаточно подробными, чтобы пояснять назначение переменных. Комментарии ставятся в той же строке после переменной.
2.5.6. При разработке конфигураций разделы и подразделы оформляются в виде областей. Правила и примеры оформления разделов и подразделов приведены в статье "Структура модуля" документа "Система стандартов и методик разработки конфигураций для платформы "1С:Предприятие 8", опубликованном на диске ИТС.
2.5.7. Обязательного комментирования требуют процедуры и функции входящие в программный интерфейс модулей - такие процедуры и функции предназначены для использования в других функциональных подсистемах (или в других приложениях), за которые могут отвечать другие разработчики, поэтому они должны быть хорошо документированы. Комментарий размещается перед объявлением процедуры (функции) и имеет следующий вид:
2.5.8. Тексты модулей в сложных алгоритмах должны содержать комментарии.
2.5.9. Комментарии должны быть достаточно понятными, чтобы пояснять работу модуля или комментируемого оператора. Тексты комментариев должны составляться в деловом стиле, быть эмоционально сдержанными и не содержать слов, не относящихся к функциональности программы.
2.5.10. Имена переменных не должны начинаться с подчеркивания. Имена переменных не могут состоять из одного символа. Использование коротких имен переменных допускается только для счетчиков циклов. Переменные, отражающие состояние некоторого флага, следует называть так, как пишется истинное значение этого флага.
2.5.11. Программные модули не должны иметь неиспользуемых или пустых процедур и функций и закомментированных фрагментов кода.
2.5.12. Функция глобального контекста ПредопределенноеЗначение() не должна применяться в тех условиях, когда доступны менеджеры прикладных объектов, вне кода тонкого или Web-клиента, т.е. в модулях объектов, наборов записей, общих модулях, для которых не установлен флаг компиляции на тонком клиенте, серверных процедурах и функциях модулей форм и т.д. Для указанных выше модулей обращение к предопределенным значениям должно выполняться через менеджер соответствующего объекта.* - данный пункт требований более не действителен в связи с неактуальностью
2.5.13. Запрещается использовать оператор Перейти в общих модулях с признаком "Клиент (управляемое приложение)", модулях команд и в клиентском коде модулей управляемых форм, так как данный метод не поддерживается платформой 1С:Предприятие в режиме веб-клиента.
2.5.14. Не следует размещать экспортные процедуры и функции в модулях форм. Исключения из этого правила возможны в отдельных, обоснованных случаях. Некоторые из них перечислены в системе стандартов и разработки конфигураций, опубликованных на диске ИТС в разделе "Правила создания модулей форм".
2.5.15. Свойство Изменяет данные должно быть установлено в Истина для всех команд, которые изменяют или могут изменять данные объекта.
2.5.16. При разработке конфигураций, предназначенных для работы в веб-клиенте, запрещено использовать модальные формы и диалоги. В противном случае, конфигурация окажется неработоспособной в ряде веб-браузеров, так как модальные окна не входят в стандарт веб-разработки. Для разработки качественных веб-приложений требуются асинхронные средства обеспечения взаимодействия с пользователем, которые предоставляет платформа 1С:Предприятие. Для этого свойство конфигурации "Режим использования модальности" должен быть установлено в "Не использовать", а вместо модальных методов следует вызывать их немодальные аналоги с блокированием окна владельца или всего интерфейса.
2.5.17. Не следует размещать экспортные процедуры и функции в модулях команд и общих команд. К этим модулям нет возможности обращаться из внешнего по отношению к ним кода.
2.5.18. При разработке решений, работающих в модели сервиса, нужно учитывать, что опасно не только непосредственное выполнение кода, написанного в режиме Предприятие, но и те места, где методами Выполнить или Вычислить исполняется код, сконструированный на основе параметров, переданных в серверные функции и процедуры. Исключение могут составлять отдельные обоснованные случаи, когда безопасность пользовательских данных гарантируется какими-либо альтернативными способами. К таким исключениям должны быть даны необходимые пояснения в тексте комментария в коде конфигурации.
2.5.19. В случае если в конфигурации предусмотрен перенос данных в сервис из локальной версии программы, необходимо обеспечить отключение всех пользовательских фрагментов кода или текстов запросов, которые были введены в локальной версии.
2.5.20. В процедуре ПриЗавершенииРаботыСистемы модуля управляемого приложения недопустимо использовать асинхронные вызовы.
2.5.21. Если в процедуре ПередЗавершениемРаботыСистемы модуля управляемого приложения используются асинхронные вызовы, то в ней необходимо установить значение параметра Отказ = Истина и из процедуры оповещения о завершении асинхронного вызова продолжить завершение работы системы.
2.6. Стандартные роли.
2.6.1. Если в конфигурации есть разграничение прав доступа пользователей к данным, то в конфигурации должны быть определены три обязательные роли, которые предназначены для "прикладного" и системного администрирования информационной базы, а также для интерактивного открытия внешних отчетов и обработок: ПолныеПрава (синоним "Полные права"), АдминистраторСистемы (синоним "Администратор системы") и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок (синоним "Интерактивное открытие внешних отчетов и обработок").
2.6.2. ПолныеПрава - обязательная роль, которая предоставляет неограниченный доступ ко всем "прикладным" данным информационной базы, но не дает прав доступа для администрирования информационной базы в целом (обновление конфигурации, работа в конфигураторе и т.п.). Эта роль должна:
В случае если конфигурация рассчитана на работу в модели сервиса, то роль ПолныеПрава назначается администраторам абонентов (администраторам областей данных). При работе конфигурации в локальном режиме роль ПолныеПрава назначается пользователям совместно с ролью АдминистраторСистемы, так как в этом режиме функции системного и "прикладного" администрирования информационной базы, как правило, совмещены.
2.6.3. АдминистраторСистемы - обязательная роль, предоставляющая дополнительные права на администрирование информационной базы в целом (обновление конфигурации, работа в конфигураторе и т.п.). Эта роль должна:
В случае если конфигурация рассчитана на работу в модели сервиса, то роли АдминистраторСистемы и ПолныеПрава назначаются администраторам сервиса.
2.6.4. ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок - обязательная роль, предоставляющая дополнительные права на открытие внешних отчетов и обработок через меню "Файл – Открыть". Эта роль должна включать в себя права к корню конфигурации Интерактивное открытие внешних отчетов и Интерактивное открытие внешних обработок. При работе конфигурации в локальном режиме роль ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок назначается администраторам, но в целях повышения безопасности информационной базы администратор может запретить использование данной роли. При работе в модели сервиса роли АдминистраторСистемы, ПолныеПрава и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок назначаются администраторам сервиса.
2.6.5. Роли ПолныеПрава, АдминистраторСистемы и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок должны устанавливаться как основные роли конфигурации (свойство ОсновныеРоли).
2.6.6. Ни в одной роли, включая ПолныеПрава и АдминистраторСистемы, не должно быть установлено (кроме отдельных обоснованных случаев) следующих прав:
2.7. Оформление текстов запросов.
2.7.1. Все ключевые слова языка запросов пишутся заглавными буквами.
2.7.2. Текст запроса должен быть структурирован, не следует писать запрос в одну строку, даже короткий. Текст запроса должен быть нагляден, поскольку это существенно улучшает его понимание другими разработчиками.
2.8. Сообщения, предупреждения, уведомления.
2.8.1. Все сообщения (предупреждения, уведомления) должны быть достаточно информативными и содержательными. Имена объектов конфигурации в сообщениях (предупреждениях, уведомлениях) должны даваться так, как они представлены в пользовательском интерфейсе. Имена объектов конфигурации всегда заключаются в кавычки. Сообщения составляются в безличной форме: не употребляются местоимения "Вы", "Вас" и пр.
2.8.2. Конфигурация должна выдавать предупреждения с подробными пояснениями перед выполнением потенциально опасных действий. Потенциально опасными действиями считаются такие действия, исправить последствия которых можно либо путем повторного ввода информации, либо восстановлением данных из резервной копии.
2.8.3. Конфигурация должна выдавать предупреждения с подробными пояснениями перед выполнением процедур, занимающих продолжительное время.
2.8.4. Модальные диалоги, вопросы, предупреждения не должны вызываться внутри транзакций записи и проведения.
2.8.5. При выдаче пользователю вопросов с несколькими вариантами выбора ответа, по умолчанию должен предлагаться ответ, выбор которого вызывает действия, либо наиболее безопасные для информационной базы, либо предусматривающие контроль пользователя за выполнением действий.
Пример 1. Если пользователю предлагается выбор между пунктами "Удалить" и "Пометить на удаление", выбором по умолчанию должен быть "Пометить на удаление".
Пример 2. Если пользователю предлагается выбор между ответами "Печатать без предварительного показа" и "Печатать с предварительным показом", выбором по умолчанию должен быть "Печатать с предварительным показом".
2.8.6. Информация об ошибках, выявленных при проверке заполнения, должна выводиться в панели сообщений формы.
2.8.7. Информация об ошибке должна доводиться до пользователя в отдельном диалоге.
2.8.8. Информация об успешном выполнении действия в форме должна выводиться в случае, если факт выполнения команды не очевиден для пользователя.
2.8.9. Информация об успешном выполнении действия в условиях отсутствия формы на экране должна также выводиться в том случае, когда для пользователя может оказаться неочевидным тот факт, что действие выполнено.
2.8.10. Для вывода сообщений пользователю во всех случаях следует использовать объект Сообщение Пользователю, даже когда сообщение не "привязывается" к некоторому элементу управления формы. Метод Сообщить применять не следует.
2.9. Документация по конфигурации.
2.9.1. Конфигурация должна поставляться с документацией. Документация должна включать разделы, описанные ниже.
2.9.2. В описании конфигурации должны быть перечислены все основные объекты и механизмы, заимствованные из типовых конфигураций разработки фирмы "1C" или других авторов, от которых должно быть получено разрешение на использование, со ссылками на соответствующую конфигурацию или разработку.
2.9.3. При использовании в конфигурации внешних компонент их свойства, методы, назначение и способы подключения должны быть описаны в документации. Если эти свойства и методы являются принципиально защищаемыми участками кода программы, то их достаточно перечислить.
2.9.4. Выпуск новых релизов конфигурации должен сопровождаться описанием изменений в релизе. Пользовательское описание изменений готовится в виде файла в формате txt или html, в котором перечислено, что изменилось в этом релизе. Пользовательское описание должно быть ориентировано на конечных пользователей конфигурации.
2.10. Поставка конфигурации.
2.10.1. Для упрощения процесса создания и обновления информационных баз пользователем конфигурация должна инсталлироваться на компьютере пользователя в соответствии с рекомендациями фирмы "1С" определенным образом – все шаблоны должны находиться в подкаталогах предопределенного каталога и сопровождаться файлами-манифестами, описывающими установленные шаблоны. Имена параметров инсталляции должны быть уникальными. Для соблюдения уникальности параметров инсталляции название разработчика должно быть зарегистрировано в соответствии с рекомендациями, опубликованными на сайте "1С:Предприятие 8" в разделе Информация для разработчиков "Регламент регистрации названий разработчиков конфигураций" (https://partners.v8.1c.ru). Конфигурация должна инсталлироваться на компьютер пользователя с названием решения (раздел Catalog в файле-манифесте) и в каталог (раздел Destination в файле-манифесте), утвержденным по итогам регистрации вашей фирмы.
2.10.2. В конце установки продукта пользователю должно показываться содержимое файла readme. В тексте файла readme необходимо указать релиз конфигурации и рекомендуемую к использованию версию "1С:Предприятия 8".
2.10.3. Конфигурация должна поставляться с установленной поддержкой.
2.10.4. Конфигурация должна поставляться с демонстрационным примером в отдельной Информационной Базе, содержащей данные гипотетического предприятия в виде законченного примера. В примере не допускаются имена объектов данных типа "Тест", "Товар 1", "Контрагент 3" и подобные. Также нежелательны "условные" заполнения полей документов и справочников, например: "Назначение 1", "Содержание 1". Введенные в демонстрационную базу данные должны соответствовать специфике той отрасли, к которой относится сертифицируемое решение. Наполнение демонстрационной базы должно быть таким, чтобы сформированные отчеты содержали информацию, отражающую назначение отчета. Недопустимо формирование отчетов, содержащих только заголовки.
2.10.5. Вместо включения в поставку демонстрационной базы допускается предоставление временного доступа к опубликованному примеру на сайте разработчика. Если конфигурация содержит заимствованные фрагменты типового решения фирмы "1С", то публикация должна выполняться способами, изложенными в Информационном письме № 21502 "О правомерном предоставлении удаленного демо-доступа к программам "1С:Предприятие".
2.10.6. Модули конфигурации не должны быть защищены паролями. На сертификацию принимается продукт, в поставку которого включены исходные тексты модулей объектов. Однако допускается, что поставка для пользователей может быть сформирована без включения некоторых исходных текстов модулей.
2.10.7. Конфигурация может быть защищена аппаратным или программным способом. В этом случае в руководстве пользователя должно быть отражено:
2.10.8. Если документацию предполагается поставлять в электронном виде, то в поставку продукта должен быть включен файл описания состава продукта, в котором необходимо указать следующую информацию о документации:
«Доктор Веб» продолжает совершенствовать модуль антиспама в своих продуктах, повышая эффективность фильтрации нежелательных писем
Соглашение о сотрудничестве в области кибербезопасности между вузом и «Лабораторией Касперского» подписано на ЦИПР-2024
Уже несколько лет Минцифры проводит политику импортозамещения ИТ-продукции. В одном из последних проектов министерства введено дополнительное требование к отечественному ПО: обязательная совместимость с двумя операционными системами из Реестра для включения в него
«МойОфис» сообщает, что приложение «МойОфис Документы для ОС Аврора» успешно прошло сертификацию ФСТЭК России. Теперь на устройствах с операционной системой версии 5.1.0.124 и выше можно использовать защищенную версию приложения МойОфис
Компания «Киберпротект» сообщает об обновлении сертификата ФСТЭК России для системы резервного копирования Кибер Бэкап 17.2 — новейшей версии продукта
«Группа Астра» объявляет о выходе новой версии платформы GitFlic. Решение доступно в трех форматах: облачном (SaaS), self-hosted и enterprise – для крупных организаций. Релиз GitFlic 4.0.0 является мажорным и содержит множество востребованных и долгожданных опций, которые сделают работу с проектами еще удобнее
Content AI, российский разработчик решений для интеллектуальной обработки информации, и «Группа Астра», один из лидеров российского рынка информационных технологий в области разработки программного обеспечения и средств защиты информации, заявили о совместимости универсальной IDP-платформы ContentCapture® версии 14.7 и СУБД Tantor Special Edition 16.6.2, разработкой которого занимается компания «Тантор Лабс» (входит в «Группу Астра»)
Новое в версии 3.0.172.30
"Доктор Веб" выпускает обновление линейки Unix-продуктов. Для ОС Astra Linux добавлен новый публичный ключ, который необходим для корректной работы всех компонентов Dr.Web в режиме замкнутой программной среды (ЗПС)
Мы используем куки (cookies) с целью повышения удобства вашей работы с сайтом.
Продолжая работу с сайтом, вы соглашаетесь с нашей
политикой конфиденциальности.
Ваши контактные данные не публикуются на сайте.