Управление доступом и навигацией в 1С:Предприятие строится на гибкой системе разделов и групп, которые формируют так называемый командный интерфейс. Для пользователя это привычная панель разделов в верхней части экрана, где сосредоточены основные функции программы: бухгалтерия, продажи, склад или кадры. Правильная организация этой структуры критически важна для удобства работы, так как хаотичное расположение кнопок снижает скорость выполнения операций и увеличивает количество ошибок сотрудников.
Добавление новой подсистемы — это не просто создание папки в дереве метаданных, а комплексный процесс настройки видимости объектов для конкретных ролей. В современных версиях платформы 8.3 механизм формирования интерфейса стал более строгим, требуя явного указания прав доступа. Если вы разработчик или администратор конфигурации, вам необходимо понимать разницу между объектом метаданных «Подсистема» и тем, как он отображается в так называемом панели разделов конечного пользователя.
В этой статье мы разберем пошаговый алгоритм внедрения нового раздела, рассмотрим нюансы настройки ролей и профильных групп, а также ответим на вопросы, почему созданная подсистема может быть не видна в работающей базе. Особое внимание уделим различиям между режимами «Такси» и классическим интерфейсом, так как логика отображения в них существенно отличается.
Структура метаданных и понятие подсистемы
Прежде чем приступать к практическим действиям в конфигураторе, важно четко разграничить понятия. В дереве метаданных объект Подсистема выполняет роль логического контейнера. Он группирует справочники, документы, отчеты и обработки, относящиеся к одной предметной области. Однако само наличие объекта в дереве не гарантирует его появление в интерфейсе пользователя.
Командный интерфейс формируется динамически на основе прав доступа пользователя. Платформа сканирует список доступных пользователю объектов и строит навигационную цепочку. Если у роли нет прав на чтение хотя бы одного объекта, находящегося внутри подсистемы, или если подсистема явно не включена в состав интерфейса конкретной роли, раздел просто исчезнет из виду. Это механизм безопасности, предотвращающий показ пустых или недоступных разделов.
Существует два основных типа подсистем в контексте навигации: обычные и подсистемы панели разделов. Обычные служат для группировки внутри окна приложения, а вторые — для создания вкладок верхнего уровня. Для добавления раздела в верхнее меню необходимо использовать специальные свойства объекта или включать его в состав интерфейса через настройки роли.
⚠️ Внимание: В типовых конфигурациях (например, Бухгалтерия предприятия 3.0 или Управление торговлей 11) прямое изменение метаданных может привести к проблемам при обновлении релиза от фирмы 1С. Все изменения рекомендуется проводить в собственной конфигурации или через расширения, если версия платформы позволяет.
Используйте префикс для всех создаваемых объектов (например, "ДР_Продажи"), чтобы легко отличать свои доработки от типовых объектов при анализе конфигурации или обновлении.
Пошаговая инструкция: создание объекта в конфигураторе
Процесс начинается в окне конфигуратора под правами администратора. Откройте дерево метаданных вашей конфигурации и найдите ветку Подсистемы. Щелкните правой кнопкой мыши и выберите пункт «Добавить». В открывшемся окне свойств задайте уникальное имя, желательно на английском языке, чтобы избежать проблем с кодировкой при выгрузке в файлы или работе со сторонними инструментами.
Ключевым моментом является настройка синонима. Именно текст, указанный в поле Синоним, будет отображаться на вкладке раздела для пользователя. Если вы оставите это поле пустым, система попытается использовать имя объекта, что часто выглядит непрофессионально. Также обратите внимание на параметр «Включать в командный интерфейс». В старых версиях платформы это была галочка, в новых — управление осуществляется через состав интерфейсов ролей.
После создания самой подсистемы необходимо наполнить её содержанием. Перетащите в неё нужные справочники, документы или отчеты. Без наполнения раздел может не сформироваться, так как платформе нечего будет показывать внутри этой группы. Структура должна быть логичной: не создавайте подсистему ради одной единственной кнопки, лучше поместите этот объект в существующую логическую группу.
Конфигурация → Подсистемы → Добавить → Имя: SalesModule
Синоним: Продажи и CRM
Включать в командный интерфейс: Да (для старых версий)
☑️ Контрольный список создания подсистемы
Важно учитывать вложенность. Подсистемы могут быть дочерними по отношению к другим подсистемам. Если вы создаете раздел верхнего уровня, убедитесь, что у него нет родителя, либо он назначен корректно. Ошибка в иерархии часто приводит к тому, что раздел «проваливается» внутрь другого меню и становится труднодоступным для оперативной работы.
Настройка прав доступа и ролей
Самая распространенная причина, по которой новая подсистема не появляется у пользователя — отсутствие прав. Механизм RLS (Record Level Security) и обычные права доступа тесно связаны с отображением интерфейса. Перейдите в ветку метаданных Роли и откройте роль, под которой заходит пользователь (например, «ПолныеПрава» или «МенеджерПоПродажам»).
В окне редактирования роли найдите раздел «Прочее» или «Командный интерфейс» (название зависит от версии платформы и типа конфигурации). Здесь представлен список всех доступных подсистем. Вам необходимо найти вашу новую подсистему в списке и установить галочку напротив неё. Это действие явно говорит платформе: «Пользователь с этой ролью должен видеть данный раздел в своем меню».
- 🔐 Проверьте, что у роли есть право
Чтениехотя бы на один объект внутри подсистемы. - 👁️ Убедитесь, что в составе интерфейса роли отмечена галочка напротив новой подсистемы.
- 🔄 После сохранения роли обязательно обновите конфигурацию базы данных.
Если вы используете профильные группы доступа, логика остается той же, но настройка производится через интерфейс пользователя в режиме предприятия, а не в конфигураторе. Администратор системы заходит в НСИ и Администрирование → Настройка пользователей и прав → Профили групп доступа и там визуально собирает интерфейс, перетаскивая нужные разделы в активную зону.
⚠️ Внимание: Изменения в правах доступа вступают в силу только после переподключения пользователя к информационной базе. Простого обновления окна может быть недостаточно, требуется полный выход из системы и новый вход.
Особенности интерфейса «Такси» и версии платформы
Начиная с версии платформы 8.3.8, компания 1С внедрила новый интерфейс «Такси», который кардинально изменил принципы навигации. В этом интерфейсе понятие «Панель разделов» стало центральным элементом. Здесь подсистемы отображаются как крупные плитки или вкладки в верхней части экрана, а не как дерево в левой панели, как это было в классическом режиме.
Для корректного отображения в «Такси» критически важно свойство подсистемы Панель разделов. Если вы создаете раздел, который должен быть виден сразу при входе в программу, убедитесь, что в свойствах подсистемы в конфигураторе установлена соответствующая опция. В некоторых случаях требуется создание специальной подсистемы-обертки, которая будет служить корнем для панели разделов.
Также стоит учитывать ограничения веб-клиента и толстого клиента. В веб-клиенте некоторые элементы управления могут отображаться иначе, а сложные иерархические структуры меню иногда сворачиваются в пункт «Еще». Всегда тестируйте внешний вид созданного раздела в том клиентском приложении, которое используется основными пользователями.
| Версия платформы | Тип интерфейса | Место настройки видимости | Особенности отображения |
|---|---|---|---|
| 8.3.6 и ниже | Обычный | Свойства подсистемы | Дерево слева, галочка "Включать" |
| 8.3.8 - 8.3.15 | Такси (базовый) | Состав интерфейса роли | Вкладки сверху, плитка |
| 8.3.20+ | Такси (улучшенный) | Профили групп доступа | Адаптивная верстка, поиск |
| Любая | Веб-клиент | Состав интерфейса роли | Зависит от браузера и настроек |
Разработчикам следует помнить, что поведение интерфейса может зависеть от установленных расширений. Если в базе работают расширения конфигурации, они могут перехватывать формирование командного интерфейса, скрывая или перемещая стандартные разделы. В таких случаях диагностику нужно проводить, временно отключая расширения.
Что делать, если галочка в роли не помогает?
Если установка галочки в составе интерфейса роли не дала результата, проверьте свойство подсистемы "Включать в командный интерфейс" непосредственно в свойствах объекта метаданных. В некоторых версиях платформы эти настройки дублируют друг друга, и отсутствие разрешения на уровне объекта блокирует настройку на уровне роли.
Диагностика проблем: почему раздел не виден
Ситуация, когда все сделано по инструкции, но раздел так и не появился, встречается довольно часто. Первым делом проверьте журнал регистрации. Ошибки прав доступа или конфликты метаданных часто фиксируются там. Ищите записи с типом события seAccessDenied или сообщения о неудачной попытке формирования интерфейса.
Второй частой причиной является кэширование на стороне клиента. Толстый клиент 1С агрессивно кэширует структуру метаданных для ускорения запуска. Попробуйте запустить базу с ключом командной строки /ClearCache или просто удалите файлы кэша в профиле пользователя. Это заставит систему перестроить интерфейс с нуля при следующем входе.
Третья причина — конфликты имен или дублирование подсистем. Если в конфигурации есть две подсистемы с одинаковыми внутренними именами (что возможно при некорректном слиянии конфигураций), платформа может вести себя непредсказуемо. Используйте обработку «Анализ конфигурации» для поиска дублей и битых ссылок.
- 🧹 Очистите кэш клиентского приложения ключом
/ClearCache. - 📂 Проверьте журнал регистрации на наличие ошибок доступа.
- 🔍 Убедитесь, что в подсистеме есть хотя бы один объект с правом чтения.
Также не стоит забывать про человеческий фактор. Пользователь может случайно свернуть панель разделов или изменить настройки отображения через меню «Еще» → «Настройка панели разделов». Попросите пользователя проверить, не скрыт ли раздел вручную в его персональных настройках интерфейса.
⚠️ Внимание: Если вы работаете в арендованной базе (1С:Линк или сервисы), права на изменение метаданных могут быть ограничены провайдером. В таких случаях добавление подсистем возможно только через механизмы расширений, а не через прямой режим конфигуратора.
90% проблем с исчезновением разделов решаются проверкой прав чтения на объекты внутри подсистемы и очисткой кэша клиентского приложения.
Частые вопросы и ответы (FAQ)
Можно ли добавить подсистему без права на редактирование конфигурации?
В режиме предприятия без прав администратора изменить структуру метаданных нельзя. Однако, если в базе включена функциональность расширений, пользователь с правами на добавление расширений может создать новое расширение, добавить туда подсистему и подключить её. Это отобразит новый раздел для всех пользователей, имеющих доступ к этому расширению.
Как скрыть подсистему для одних пользователей и показать для других?
Для этого используется механизм ролей. Создайте две роли: в одной в составе интерфейса отметьте новую подсистему, в другой — нет. Затем назначьте эти роли соответствующим пользователям. Платформа автоматически сформирует индивидуальный командный интерфейс для каждого сотрудника в зависимости от набора его ролей.
Влияет ли добавление подсистемы на скорость работы базы?
Само по себе добавление одной подсистемы не оказывает заметного влияния на производительность. Однако, если внутри подсистемы находятся сложные отчеты или регистры, которые рассчитываются при формировании списка, это может замедлить открытие раздела. Оптимизировать нужно содержимое, а не структуру навигации.
Что такое "Панель разделов" и чем она отличается от обычной подсистемы?
Панель разделов — это специальный режим отображения подсистем в интерфейсе «Такси», когда они выносятся на самый верхний уровень навигации. Обычная подсистема может быть просто папкой внутри раздела. Различие задается в свойствах объекта метаданных и определяет визуальное представление в клиентском приложении.
Можно ли переименовать подсистему в работающей базе без потери данных?
Да, изменение синонима (названия, видимого пользователю) безопасно и не влияет на данные. Однако изменение внутреннего имени объекта метаданных требует осторожности. При обновлении конфигурации базы данных ссылки на объект могут сбиться, если они жестко зашиты в коде модулей. Рекомендуется менять только синоним.