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

Содержание

1. Общие сведения об аудите

1.1. Зачем нужен аудит?

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

• безопасны, не приведут к потере или хищению данных пользователей сервиса;
• не повредят штатной функциональности приложений сервиса;
• не вызовут деградацию производительности сервиса или иные нежелательные последствия,

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

1.2. Кто выполняет аудит?

Аудит выполняется сотрудниками провайдера сервиса (фирмы «1С»).

1.3. Как долго проводится аудит?

Это зависит от количества строк кода, сложности понимания кода, количества форм и т. д. Как правило, аудит выполняется в течение 2–3 рабочих дней.

1.4. Задачи аудита

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

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

1.5. Результат аудита

Прошедшие аудит расширения конфигурации, дополнительные отчеты или обработки могут использоваться в сервисе — встраиваться в размещенные в сервисе приложения.

Для того чтобы расширение конфигурации было разрешено использовать не только абоненту-правообладателю, но и другим абонентам, необходимо, чтобы описание расширения прошло аудит.

2. Процедура отправки на аудит

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

• Как загрузить расширение конфигурации в сервис?
• Как загрузить дополнительный отчет или обработку в сервис?

Описание расширения можно отправить на аудит также из формы описания расширения:

3. Оповещения о задачах аудита

При отрицательном результате аудита расширения конфигурации, дополнительного отчета или обработки:

• разработчику отправляется электронное письмо с уведомлением об отрицательном результате аудита и с замечаниями аудитора;
• для разработчика создается задача на выполнение исправлений.

О наличии задач на исправление замечаний аудита разработчику выводятся оповещения:

1. При работе разработчика в менеджере сервиса (личном кабинете) в правом нижнем углу экрана периодически будет выводиться уведомление:

   

2. Справа от гиперссылки Адаптация в панели действий окна менеджера сервиса (личного кабинета) в скобках будет показано количество задач на исправление замечаний аудита:

   

3. В  области данных пользователя в скобках справа от гиперссылки Мои задачи показывается количество задач пользователя:

   

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

4. Вывод карточки задачи на исправление замечаний аудита

Чтобы вывести карточку задачи на исправление замечаний аудита, разработчик должен:

1. Войти в свой личный кабинет, например, щелкнув ссылку  Личный кабинет на странице Мои приложения сайта сервиса;

   

2. Щелкнуть гиперссылку Адаптация в панели действий окна менеджера сервиса (личного кабинета):

   

3. В выведенной форме Адаптация приложений перейти на вкладку Задачи.

   

4. Щелкнуть двойным щелчком мыши нужную строку в выведенном списке задач. Откроется карточка задачи на исправление замечаний аудита.

   

5. Учет замечаний аудитора

В выведенной карточке задачи на исправление замечаний аудита разработчик может:

• ознакомиться с замечаниями аудитора;
• нажав гиперссылку История аудита, ознакомиться с историей аудита объекта разработки;
• получить файл, по которому проводился аудит (для аудита версии расширения, дополнительного отчета или обработки).

Разработчик может учесть замечания аудитора и отправить объект разработки на повторный аудит, или прекратить аудит проверяемого объекта.

5.1. Повторный аудит расширения

Чтобы повторно отправить на аудит разрабатываемую версию расширения, разработчик должен:

1. Ознакомиться с замечаниями аудитора, приведенными в карточке задачи.
2. Если для исправления замечаний необходимо изменение кода расширения — внести исправления в код расширения и сохранить конфигурацию расширения в файл.
3. Добавить в карточку задачи на исправление замечаний аудита комментарии об исправлениях, сделанных по замечаниям аудита.
4. Нажать кнопку Повторить аудит.
5. Будет выведено окно мастера добавления расширения. С его помощью следует добавить версию расширения в сервис, как описано в статье по ссылке. При внесении исправлений в расширение в мастере нужно указать файл исправленной версии расширения.

5.2. Повторный аудит описания расширения

Чтобы повторно отправить на аудит разрабатываемую версию описания расширения, разработчик должен:

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

5.3. Повторный аудит дополнительного отчета или обработки

Чтобы повторно отправить на аудит разрабатываемую версию дополнительного отчета или обработки, разработчик должен:

1. Ознакомиться с замечаниями аудитора, приведенными в карточке задачи.
2. Внести исправления в код дополнительного отчета или обработки.
3. Создать новый комплект поставки (см. статью по ссылке).
4. Добавить в карточку задачи комментарии об исправлениях, сделанных по замечаниям аудита.
5. Нажать кнопку Повторить аудит.
6. Будет выведено окно мастера добавления дополнительного отчета или обработки. С его помощью следует добавить в сервис новую версию комплекта поставки дополнительного отчета или обработки, как описано в статье по ссылке.

6. Прекращение прохождения аудита

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

7. Если аудит прошел успешно

При положительном результате аудита:

• разработчику отправляется электронное письмо с уведомлением об успешном прохождении аудита;
• состояние принятой версии расширения конфигурации, дополнительного отчета и обработки изменится на «Опубликовано».

7.1. Использование в приложениях

Расширения конфигурации, дополнительные отчеты и обработки, успешно прошедшие аудит, могут использоваться в приложениях абонентов сервиса (см. статью по ссылке).

Круг этих абонентов зависит от того, кто является владельцем (правообладателем) расширения конфигурации, дополнительного отчета или обработки:

7.2. Предоставление доступа

Если владельцем (правообладателем) расширения конфигурации, дополнительного отчета или обработки является обслуживающая организация, то она может предоставить доступ к расширению конфигурации, дополнительному отчету или обработке обслуживаемым ею абонентам (см. статью по ссылке).

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

См. также: