СППР Регламент описания профилей доступа

Данные > Статьи и инструкции > Инструкция

ИНСТРУКЦИЯ 1С 8 → перейти в меню [СТАТЬИ И ИНСТРУКЦИИ]

Глава 0. Целеполагание.

1. Упорядочить процесс описания состава ролей профилей доступа пользователей. Каждому участнику проектной команды: от руководителя проекта до конечного разработчика конечной функции системы должно быть известно, где описан текущий состав ролей каждого из “нетиповых” профилей доступа, разрабатываемых на проекте. Эту информацию необходимо использовать при подготовке баз каждого из контуров: разработки, тестирования (сдачи работ) и промышленной эксплуатации. Недопустима ситуация, при которой:
a. Разработчик в ходе разработки и собственного тестирования “накидал” себе свой состав ролей в тестовые профили доступа, в случае ошибки исправил состав ролей в собственной базе, но никому ничего не сообщил, в надежде что или “методологи сами потом разберутся”.
b. Методолог, ответственный за функциональную область, аналогично разработчику, прошел заново долгий путь проб и ошибок по наполнению нетиповых профилей доступа и выдохнул с облегчением “здесь у меня все хорошо”, остается потом повторить этот состав ролей в промышленной базе. Дело в том, что соседний методолог по другой, но смежной функциональной области, может в то же самое время проходить ровно тот же путь, натыкаясь на те же ошибки, делая даже возможно собственные выводы.

2. Ускорить процесс “подготовки” нетиповых разрабатываемых профилей доступа в информационных базах на всех этапах проекта от разработки, последующего тестирования и сдачи работ до инициализации и ввода в эксплуатацию опытной и промышленной информационных баз. Данный процесс должен быть максимально автоматизирован и лишен рутины ручного редактирования профилей доступа в пользовательском режиме. Недопустима ситуация, при которой:
a. Разработчик, инициируя для себя новую базу для разработки, вынужден заново (подчас вручную) перенастраивать профили доступы пользователей, подготавливая права для набора “тестовых пользователей”.
b. Методолог, получив от разработчика новый функционал в тестовой базе, вынужден “уточнять” у разработчика, какие именно роли и в какие профили следует добавить, а то и порой просить разработчика выполнить эти настройки самостоятельно.
c. Коллектив проектной команды перед началом (а то и во время) процесса подготовки опытной и/или промышленной базы начинает лихорадочно “приводить к общему знаменателю” состав ролей в профилях доступа, опираясь на тестовые базы, стараясь “ничего не упустить” или устраивая в промышленной базе повторное тестирование перед запуском системы.

Не секрет, что именно отсутствие выстроенной системы общих и принятых всеми участниками проектной команды правил получения информации о том, какие используемые профили какие роли должны содержать, а также необходимость неприятного ручного труда при вводе этих ролей в профили, а главное регулярной актуализации этих данных, приводят к совершенно недопустимой ситуации когда и разработка и тестирование, а подчас и обучение и запуск системы в эксплуатацию происходят под “самыми прекрасными” полными правами. Происходят в надежде на то “сейчас главное сделать функцию”, “сейчас главное протестировать что работает”, “сейчас главное закрыть этап обучения” и т.д., а “уж роли какие-нибудь в промышленной базе в профилях пользователя какие-нибудь соберем”. Как показывает практика, конечно соберем, проблема в том что профили эти будут “какие-нибудь”, имеющие массу избыточности, ошибок, но и даже для того, чтобы сделать это, придется заново переписать часть кода, частично перепроектировать хранение данных, все это заново пере тестировать, но главное, с удивлением обнаружить как сильно за это время мы выбились из графика проекта. Ну если, конечно, мы не решились протестировать все это на конечных пользователях.

Глава 1. Что мы имеем?

Как говорилось в известном фильме, “что нам было известно до операции”? Допустим, что мы имеем средней величины и сложности проект разработки “с нуля” (конечно, не с чистого нуля, а на базе БСП) системы под условным названием “Судовой модуль”. Согласно плану проекта он поделен на следующие функциональные области, разрабатываемые параллельно:

1. Судовое снабжение (СНБ)
2. Судовые ремонты и техобслуживание (ТОР)
3. Система управления безопасностью судна (СУБ)

Для простоты считаем, что над каждой функциональной областью, относительно независимо от других областей, трудятся по одному методологу и по двое разработчиков. В самом простом и линейном понимании процесса мы имеем 6 баз для разработки (своя и у каждого разработчика) и 3 базы для моделирования процессов функциональной области (своя у каждого методолога). Очень возможно, что все они договорились вести также и Базу №10 - Сводную базу для сквозного моделирования процессов проекта. Итого 10 баз.

Согласно проектной документации пользователи системы поделены на следующие виды пользователей:

1. Администратор системы (про него все понятно, далее речь о нем вести не будем)
2. Член экипажа судна
3. Капитан судна (является членом экипажа, но имеет ряд доп. прав)
4. Внешний аудитор на судне (имеет права на просмотр отдельной информации)
5. Системный пользователь сервиса автоматического обмена с “берегом”.

Глава 2. Описываем перечень профилей доступа

В рамках проектирования будущей системы в соответствии с видами пользователей было зафиксировано следующее “дерево доступа”. Для будущей системы это дерево в какой-то степени является прообразом состава справочника “Группы пользователей”:

● Пользователи со входом в систему
○ Члены экипажа судна
■ Капитаны судов
○ Внешние аудиторы на судах
● Пользователи без интерактивного входа в систему
○ Сервис автоматического обмена с “берегом”

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

Таким образом, по итогам проектирования справочник “Профили пользователей” в СППР будет содержать следующие элементы:

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

На данном этапе такого описания перечня профилей нам достаточно. Там же, в списке профилей пользователей вызываем команду Ещё - Сформировать программу начального заполнения профилей доступа.

Результатом её выполняется является некий код, автоматически сформированный СППР, примерно такого вида

// Описание для заполнения профиля "Капитаны судов (дополнительный)".

ОписаниеПрофиля = УправлениеДоступом.НовоеОписаниеПрофиляГруппДоступа();
ОписаниеПрофиля.Идентификатор = "ce81fd63-0ece-11eb-8925-005056b5077b";
ОписаниеПрофиля.Наименование = "Капитан (дополнительные права)";
ОписанияПрофилей.Добавить(ОписаниеПрофиля);

// Описание для заполнения профиля "Члены экипажа судна".
ОписаниеПрофиля = УправлениеДоступом.НовоеОписаниеПрофиляГруппДоступа();
ОписаниеПрофиля.Идентификатор = "9efef89b-5b17-11eb-8156-14dda9d639df";
ОписаниеПрофиля.Наименование = "Пользователь";
ОписанияПрофилей.Добавить(ОписаниеПрофиля);

//… и т.д. для всех профилей доступа.

//Данный код необходимо добавить в процедуру
//ОбщийМодуль.УправлениеДоступомПереопределяемый.
//ПриЗаполненииПоставляемыхПрофилейГруппДоступа()

При распространении данного функционала механизмами групповой разработки (хранилище конфигурации или git) достаточно получить эти изменения в любой конечной базе (одной из 10-ти ранее описанных) и выполнении обработчиков обновления (например, запустив конфигурацию с параметром запуска "/С ЗапуститьОбновлениеИнформационнойБазы")

Одно дело уже сделано - мы знаем, что в программе у нас на уровне кода уже прописан перечень необходимых профилей доступа, причем, т.к. данные профили являются “поставляемыми”, т.е. чей состав определяется разработчиком системы, можно говорить о том, что участники проектной команды, работая каждый в своей базе, не может отредактировать состав этих профилей вручную.

Глава 3. Описываем состав ролей профилей доступа

В ходе разработки разработчик, добавляя в систему новые объекты метаданных или описывая дополнительные привилегии, не связанные с объектами метаданных создает в конфигурации новые роли, руководствуясь при этом стандартом разработки https://its.1c.ru/db/v8std#content:689:hdoc

ЧтениеЗаявокНаСнабжение
ДобавлениеИзменениеЗаявокНаСнабжение
ПравоОтправкиРапортаНаБерег
и т.д.

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

Для этого разработчик в СППР в справочнике “Профили пользователей” в карточке соответствующих профилей добавляет новые роли на закладке “Разрешенные действия и виды доступа”.

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

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

При этом важное главное: есть единственный путь описания в программе состава ролей профилей доступа, пусть чуть более “длинный” чем обычно, но зато изменения эти гарантированно распространяются на все остальные информационные базы, задействованные в проекте, а также изменения коллег в других функциональных областях проекта гарантированно сопровождаются изменениями в профилях доступа. А значит достигается первая из поставленных целей - упорядочивание процесса описания состава ролей. Каждому члену проектной команды известно и понятно, что единственный достоверный состав ролей описан в СППР, а единственный способ обновить состав профилей доступа - взять из СППР его описание в виде автокода и применить для информационной базы. А значит (при определенном контроле со стороны архитектора проекта) - минимален риск всем десятерым регулярно делать одно и то же, неоправданно увеличивая время разработки.

Глава 4. Разворачиваем новые базы

Нередко на проекте приходится разворачивать новые информационные базы:

Появился новый/сменился имеющийся разработчик - он разворачивает себе новую базу для разработки
Появился новый/сменился имеющийся методолог - он разворачивает себе новую базу для тестирования
Организуем учебный стенд для проведения обучения и тестирования пользователей Заказчика - опять новая база.
Наконец инициируем промышленную среду - вновь требуется развернуть новую информационную базу.

Причем в отличие от НСИ, начальных данных, состава пользователей желательно чтобы всякий раз профили доступа в ней были актуальными на текущий момент времени. Следуя описанной выше методике всякий раз это требование выполняется автоматически - достаточно для любой информационной базы актуальной конфигурации выполнить обработчики обновления информационной базы, как мы получаем в самой информационной базе актуальный перечень профилей доступа с заполненным составом ролей. А значит достигается вторая поставленная цель - процесс “подготовки” нетиповых разрабатываемых профилей доступа в информационных базах максимально автоматизирован, все профили заполняются автоматически и процесс наполнения их абсолютно лишен ручного, а значит рутинного труда. А значит - неизбежных в этом случае ошибок.

Глава 5. Что не хватает и что требуется автоматизировать дополнительно

Описанный способ разработки профилей “с нуля” как правило хорошо подходит только для тех конфигураций, которые также “с нуля” и разрабатываются. В случае адаптации типовых конфигураций, чаще всего за основу “нетиповых” профилей доступа приходится брать описание типовых профилей. А значит и нужна обратная функция - заполнения состава ролей описания профиля доступа в СППР согласно аналогичному “автокоду” описания типового поставляемого профиля доступа. В ERP примером процедуры, где содержится описания профилей может быть процедура

УправлениеДоступомУТ.ПриЗаполненииПоставляемыхПрофилейГруппДоступа()

Будь в СППР функция “Заполнить профиль по программе начального заполнения профиля”, в процессе разработки можно было бы с легкостью отказываться от типовых поставляемых профилей доступа и переходить на собственные поставляемые профили доступа, управлять составом которых гораздо легче. Достаточно было бы непосредственно в коде конфигурации найти код описания профиля доступа, на его основе один раз заполнить состав собственного профиля, а далее уже привычно работать с ним - удалить из состава избыточные роли, добавить новые необходимые и т.д.
// Материал от участника 1С Вики

комментарии

____________________

Перепечатка текста и фотографий разрешена при наличии прямой ссылки на источник