Написал вторую часть правил внесения изменений (первая была тут). Как упоминал в первой публикации, это не хухры-мухры, а методическое пособие, по которому мои программисты учатся и сдают потом экзамен. Поэтому, если заметите критическую ошибку – пишите, не стесняйтесь, если сойдемся во мнениях – исправлю.
В каждом пункте я постарался не просто изложить правила, но и объяснить, почему они именно такие. Мне важно, чтобы человек не просто их запомнил, но и мог объяснить суть правил, их происхождение, отличия во внесении изменений в разных конфигурациях и версиях платформы. Так что не обессудьте на большое количество текста.
И чем дальше пишу, тем больше понимаю, что правил намного больше, чем я представлял себе изначально.
Добавление новых подписок на события
Добавление новых подписок на события – самый, пожалуй, безопасный способ доработки типовых объектов, особенно ссылочных. Странно при этом, что лишь недавно подписки на события стали поддерживаться в расширениях конфигурации.
Первое, что стоит отметить – имя подписки. Оно должно отражать имя события и примерный состав объектов, включенных в ней. Если вы делаете универсальную подписку-шлюз для обработки события «ПриЗаписи» у документов, то нормально будет дать ей имя «ПриЗаписиДокумента». В этом случае человек, ищущий подписки на определенные события, без труда её найдёт. Равно как и человек, который хочет найти все подписки на документы.
Включать в имя подписки функциональное назначение стоит только в том случае, если вы делаете прям какой-то механизм, рассчитанный на множество типов объектов, и являющийся более или менее обособленным. Например, какое-то своё версионирование, проверку при записи или автозаполнение реквизитов. В этом случае будет нормально назвать подписку типа «ПриЗаписиДокументовВерсионированиеСережино» - тут и событие отражено, и тип объектов, и назначение механизма.
Типичная ошибка новичков – считать важным механизмом свою доработку конкретного объекта, вроде стирания комментария при копировании заказа покупателя. Новичок в таком случае создает подписку вроде «ПриКопированииЗаказаПокупателяСтираниеКомментарияСережаПридумал», которая обрабатывает объекты одного типа – просто стирает комментарий.
Для таких мелких доработок лучше использовать подписки-шлюзы, или подписки-кейсы (case, оператор выбора во многих языках программирования). Суть проста – делаете подписку вроде «ПередЗаписьюДокумента», а в обработчике пишете разветвление выполняемого кода в зависимости от типа объекта. Процедуры для обработки объектов конкретных типов лучше оформлять отдельно, не создавая дикий код в обработчике подписки – пусть он остаётся шлюзом, роль которого – перенаправление выполнения кода. Сначала там будет один объект и один кусок кода, потом придёт следующий разработчик (или вы, со следующей задачей), расширит тип объектов подписки, добавит свою процедуру.
Еще одна мелочь: если создали ветку обработки объектов определенного типа, не добавляйте безусловный Возврат – дальше по коду может быть обработка объектов того же типа, но с другой целью.
Изменение типовых подписок
В общем случае – идея так себе. Как правило, меняют состав объектов подписки. Тут многое зависит от платформы – старые её версии не показывали нормально изменения в составе подписки. Но даже в новых версиях, при наличии встречных изменений в составе, головной боли обновлятору вы добавите.
Если вам нужно добавить какой-то объект в состав типовой подписки, есть простой способ – создать новую подписку, и указать в качестве обработчика ту же процедуру, что и в типовой подписке. Понятно, что перед этим надо глянуть код обработчика – там может быть фильтр по типу объекта, в этом случае без доработки не обойтись. Но вроде разработчики фильтрацией по типу не страдают.
Изменение кода обработчика типовой подписки стоит делать, только если вы прям уверены в себе. Правила тут примерно такие же, как в доработке любой другой процедуры или функции типового общего модуля, просто в качестве аргументов всегда используются объекты, а не ссылки, таблицы или еще черт знает что.
Как устроены типовые роли
Вынесу краткую справку по устройству типовых ролей в отдельный пункт, чтобы потом не возвращаться к этому вопросу.
В старых конфигурациях, вроде УПП или УТ 10.3, когда еще не было профилей полномочий, их функцию выполняли роли. Роль содержала в себе практически всё, что нужно для работы человека на определенной должности. Например, были роли МенеджерПоЗакупкам, ЗаведующийУчетом, Кладовщик, Расчетчик и т.д.
Позже, с развитием и применением ограничений на уровне записей (RLS), появились роли-двойники, типа менеджера по продажам с ограничением прав – всё то же самое, что и в исходной роли, только с прописанными запросами для ограничения прав. Сейчас эти роли-двойники убрали, но у некоторых клиентов они еще встречаются, если люди не любят обновляться.
Прелесть такого подхода в том, что ролей очень мало – буквально пара десятков. Недостаток вытекает из преимущества – ролей слишком мало. На реальном внедрении типовые роли в 99% случаях не позволяют настроить права человека так, как это требуется. Поэтому, в 99% случаев роли приходится дорабатывать.
Когда придумали профили (справочник, содержащий перечень ролей, и назначаемый пользователю или группе), то всё стало совсем странно. У нас есть роли вроде МенеджерПоПродажам, и появляется профиль МенеджерПоПродажам, который содержит одну якорную роль, и несколько мелких вспомогательных, вроде права на использование ЭДО или электронной почты. Вроде как профиль в профиле.
Система ролей в современных конфигурациях строилась уже с учетом накопленного опыта. Стало понятно, что в качестве контейнера, содержащего права для конкретной должности или пользователя, надо использовать профили (справочник), а не роли. Поэтому роли начали делать по другому принципу – они теперь дают право на выполнение конкретных, весьма узких операций.
Например, используются роли вроде ДобавлениеИзменениеЗонДоставки, ДобавлениеИзменениеОжидаемыхПоступленийДенежныхСредств, ДобавлениеИзменениеПриказовНаДоплату и даже ИспользованиеОбработкиФормированиеЗаказовНаПередачуВПроизводствоПоПлану. Как видите, каждая роль даёт право использования очень ограниченного перечня объектов, вплоть до одной обработки.
По сравнению со старым подходом, количество ролей увеличилось в десятки раз. Например, знаете, сколько ролей в ERP 2.4.8.82? 1316. Количество ролей как бы говорит: не лезь ко мне, развлекайся в другом месте.
Составить из таких ролей профиль для пользователя – задача не из простых. Поэтому разработчики типовых конфигураций идут навстречу, и делают предопределенные профили и группы доступа, чтобы хоть как-то облегчить нам эту непосильную задачу.
Собственно, вот и вся разница. Раньше было мало ролей с мощным содержанием, сейчас делают сотни атомарных ролей.
Доработка старых ролей
В принципе, сейчас уже нет ничего страшного в том, чтобы дорабатывать типовые роли в старых конфигурациях. Принципиально в них уже ничего не меняется. Если добавляется новая функциональность, то только прицепом, вроде маркировки. Изменения вроде повышения ставки НДС встречаются редко. Для новых объектов роли делают по-новому – добавляют атомарные. Точнее, тащат их… Откуда-то там.
В старые времена, когда УПП и УТ 10.3 еще обновлялись, подход был такой. Если хочешь кастомизировать роль менеджера по продажам под конкретное предприятие – копируй типовую и исправляй, а типовую не трожь. Потом, правда, уже никак нормально не разберешься, что изменилось в типовой роли при обновлении, но хоть замочки целы. Где что перестало работать – там и ищи разницу.
Потом, с появлением профилей, подход к доработке поменялся – кастомизаторы начали создавать собственные атомарные роли, и включать их в профили. Так сильно, конечно, не мельчили, как сейчас в ERP, но суть подхода была такой же.
Поэтому, если вам нужно доработать права доступа в старой конфигурации, думать особо не надо.
Если вы добавили новую, отдельностояющую функциональность, вроде заявок на заправку картриджей – создавайте новые роли для обслуживания прав доступа на неё.
Если вам нужно расширить права типовой роли, то добавляйте новую роль, типа ДопПраваМенеджераПоПродажам, и расширяйте права там. Убедитесь только, что скопированной роли еще нет – наверняка кто-то до вас этим озаботился.
Если же вам нужно сузить права типовой роли, то либо дорабатывайте её, либо копируйте, уменьшайте права там, и заменяйте типовую роль на свою в профилях.
Доработка ролей в современных конфигурациях
Всё очень просто – не трогайте типовые роли в современных конфигурациях. Если вы добавили в конфигурацию новую функциональность – создавайте собственные атомарные роли, которые будут регулировать права на неё.
Если же вам надо изменить права существующей типовой роли, используйте расширения.
Доработка ролей через расширения
Я к расширениям отношусь прохладно, но одну вещь там сделали так, что не стыдно пацанам показывать, а именно – доработку ролей. Если не сталкивались, то сейчас со стула упадёте – расширением можно переопределять значения конкретных прав на объект внутри роли. Я когда увидел, не мог поверить, пошел создавать пустую конфигурацию, чтобы убедиться – не может быть, чтобы 1С что-то сделала так офигенно.
Например, хотите вы доработать роль менеджера по продажам, дав ему право на новый или какой-то типовой отчет – нет ничего проще. Добавляете роль и объекты в расширение, ставите галку на нужный отчет, и вуаля – роль типовая, всем назначена, а отчет виден.
Настоящие же чудеса начинаются, когда вам надо изменить значение конкретного права. Например, забрать право на добавление элементов справочника, оставив только изменение. Нет ничего проще – тащите роль в расширение вместе с объектом, и просто снимайте галку (добавление или интерактивное добавление, что правильнее под задачу).
Главная фишка – все остальные права останутся на месте. В расширении они будут помечены затененными флажками – это типа наследование. Только вдумайтесь: наследование в 1С. И не чего-то там, а прав в ролях.
Так что, в современных типовых конфигурациях доработка ролей – одно сплошное удовольствие, без особого риска. Конечно, может выйти обновление, в котором ваше расширение по ролям вдруг станет неактуальным, но вероятность краха намного ниже, чем при ручной доработке типовых ролей.
Да, если используете расширения (а их в современных конфигурациях используют почти все), то и новые роли логично добавлять именно в расширениях.
