Настраиваем раздел и права администратора в базе 1С

Раздел «Администрирование» в типовых конфигурациях на платформе 8.3 уже есть — его не «добавляют», как новую подсистему, а открывают пользователю с нужными правами. Чтобы администрирование появилось в интерфейсе и работало в полном объёме, пользователю нужна роль «Полные права» (или профиль «Администратор»), а в пустой базе — первый вход, который эти права назначает.

Ниже — как получить и проверить права, как завести администратора через Конфигуратор и через режим «Предприятие», как настроить профили групп доступа, журнал регистрации, обслуживание базы и резервное копирование . Всё по интерфейсу «Такси» актуальных релизов.

Что значит «добавить администрирование» и кто это делает

Под «добавить администрирование» на практике понимают одно из двух:

• 🔑 Дать пользователю права администратора — чтобы в меню появился раздел Администрирование и стали доступны настройки пользователей, обмена, обслуживания.
• 🧩 Настроить саму подсистему — пользователи и роли, профили групп доступа, журнал событий, регламентные операции.

Сделать это может тот, у кого уже есть полные права. В типовых конфигурациях (Бухгалтерия 3.0, ЗУП 3.1, Управление торговлей 11) подсистема администрирования входит в состав конфигурации изначально — отдельно её подключать не нужно. Задача сводится к правам и настройкам.

Если же речь о собственной (нетиповой) конфигурации, которую разрабатывают с нуля, то «добавить администрирование» означает другое — подключить в Конфигураторе готовую подсистему из Библиотеки стандартных подсистем (БСП). Это работа разработчика, а не администратора базы, и в типовых решениях она уже выполнена поставщиком.

Как проверить и получить права администратора

Сначала убедитесь, что у вас есть права. Признак простой: в главном меню (панель разделов) виден раздел Администрирование. Если его нет — прав недостаточно.

Назначить права другому пользователю можно двумя путями.

Через режим «Предприятие» (рекомендуемый для типовых конфигураций):

1. Откройте Администрирование → Настройки пользователей и прав → Пользователи.
2. Откройте карточку пользователя или создайте нового кнопкой Создать.
3. Перейдите по ссылке Права доступа в карточке.
4. Включите профиль Администратор (флажок напротив профиля) и запишите.

Через Конфигуратор (если в «Предприятии» администрирование недоступно вообще):

1. Запустите базу в режиме Конфигуратор.
2. Меню Администрирование → Пользователи.
3. Создайте пользователя или откройте существующего, вкладка Прочие.
4. Установите флажок у роли Полные права, при необходимости — Администратор системы.
5. Запишите пользователя.

Роль «Полные права», выданная в Конфигураторе, и профиль «Администратор» в «Предприятии» — это разные механизмы; в типовых базах правильнее управлять доступом через профили групп доступа, а не расставлять роли вручную в Конфигураторе. Ручная правка ролей в Конфигураторе нужна, когда штатный механизм профилей ещё не работает (например, в базу вообще не пускает).

Профили групп доступа и ролевая модель

В типовых конфигурациях права раздают не отдельными ролями, а профилями групп доступа. Профиль — это набор ролей под определённую должность: «Бухгалтер», «Кадровик», «Администратор» и т. д.

Путь: Администрирование → Настройки пользователей и прав → Профили групп доступа.

Как это устроено:

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

Для администратора используется предопределённый профиль Администратор — он уже содержит роль полных прав. Создавать копию профиля имеет смысл, когда нужен «администратор с ограничениями»: например, человек управляет пользователями, но не видит зарплату. Тогда копируют профиль, убирают лишние роли и назначают его отдельной группе доступа.

Полезно разделять два разных понятия, которые новички путают:

• Пользователь ИБ — учётная запись для входа в базу (логин, пароль, способ аутентификации). Живёт на уровне платформы.
• Элемент справочника «Пользователи» — карточка сотрудника в прикладном решении, к которой привязаны права, физлицо, настройки. Живёт на уровне конфигурации.

В типовых базах их связывает штатный механизм: создавая пользователя через Настройки пользователей и прав, вы заводите и то и другое согласованно. Если же пользователя ИБ создать напрямую в Конфигураторе в обход справочника, в «Предприятии» он может не получить прикладных настроек — отсюда частые жалобы «пользователь есть, а прав нет».

Настройки входа и политика паролей

Администрирование доступа — это не только «кому что можно», но и как люди входят в базу. В типовых конфигурациях за это отвечает группа настроек: Администрирование → Настройки пользователей и прав → Пользователи (там же ссылки на параметры входа).

Что настраивается:

• 🔐 Способ входа — по логину и паролю 1С либо по учётной записи операционной системы (доменная аутентификация). Для организации с Active Directory удобнее второе: не нужно помнить отдельный пароль.
• 📏 Политика паролей — минимальная длина, требование сложности, срок действия пароля. Задаёт планку безопасности для всех, кто входит по паролю 1С.
• 🚪 Разрешение входа — флажок Вход в программу разрешён в карточке пользователя. Снятый флажок блокирует вход, не удаляя саму учётную запись и её историю.
• ⏱️ Ограничение по сроку — учётную запись можно сделать действующей до определённой даты (удобно для временных сотрудников и подрядчиков).

Эти настройки — часть администрирования наравне с правами: без них «администрирование добавлено» лишь наполовину.

Журнал регистрации: аудит действий пользователей

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

Открыть журнал в «Предприятии»: Администрирование → Обслуживание → Журнал регистрации. В Конфигураторе: меню Администрирование → Журнал регистрации.

Полезные приёмы работы:

• 📅 Отбор по периоду, пользователю и важности события — так журнал из простыни превращается в точечный отчёт.
• 🔎 Отбор по конкретному объекту: правой кнопкой на документе → команда просмотра событий, либо отбор по данным в самом журнале.
• 🧹 Настройка состава регистрируемых событий — чтобы не писать лишнего и не раздувать журнал.

Настройка глубины журнала задаётся в Конфигураторе: Администрирование → Настройка журнала регистрации. Там выбирают, какие события писать (вплоть до отдельных транзакций) и период разделения файлов — день, неделя, месяц. Физически в файловой базе журнал хранится в служебном каталоге базы (файл с расширением .lgd).

Пара вещей, о которых забывают:

• Журнал не бесконечен по смыслу: старые записи имеет смысл периодически сокращать (команда сокращения в том же окне настройки), иначе файл растёт месяцами и замедляет открытие.
• Перед сокращением журнала выгрузите нужный период в отдельный файл, если записи могут понадобиться для разбора инцидента позже.
• Важность события (ошибка, предупреждение, информация, примечание) — главный фильтр при разборе: начинайте с ошибок и предупреждений, а не листайте всё подряд.

Техническое обслуживание и контроль состояния базы

Администрирование — это не только права. Регулярное обслуживание держит базу быстрой и целой.

Активные пользователи и сеансы. Администрирование → Обслуживание → Активные пользователи (в Конфигураторе — меню Администрирование → Активные пользователи). Здесь видно, кто сейчас в базе. Это нужно перед операциями, требующими монопольного доступа.

Тестирование и исправление (ТиИ). Запускается из Конфигуратора: Администрирование → Тестирование и исправление. Проверяет логическую и ссылочную целостность файловой базы, пересчитывает итоги, реиндексирует таблицы.

Удаление помеченных объектов. Администрирование → Обслуживание → Удаление помеченных объектов — чистит базу от мусора, но проверяет ссылки: объект, на который кто-то ссылается, удалён не будет.

Регламентные и фоновые задания. Администрирование → Обслуживание → Регламентные и фоновые задания. Здесь видно, какие автоматические операции выполняются: обмен данными, отправка отчётности, пересчёт итогов, индексация полнотекстового поиска. Если база «тормозит по расписанию» или что-то перестало обновляться автоматически — смотреть нужно сюда: задание могло завершиться с ошибкой или оказаться отключённым.

Несколько практических ориентиров по мониторингу:

• 📉 Длинные и частые фоновые задания — первый подозреваемый при периодических «подвисаниях».
• 🔁 Отключённое задание обмена — типичная причина того, что данные между базами перестали ходить.
• 🧾 Ошибки регламентных заданий дублируются в журнал регистрации — удобно разбирать их там вместе с остальными событиями.

Монопольный доступ в 1С 8.3 нужен не «всегда при администрировании», а точечно: при тестировании и исправлении, загрузке базы из файла и обновлении структуры конфигурации. Для выдачи прав, работы с журналом и настройками монополия не требуется.

Резервное копирование и восстановление

Резервная копия — страховка перед любыми изменениями в администрировании. Способ зависит от варианта базы.

Файловая база. Проще всего — выгрузка в файл .dt:

• В «Предприятии»: Администрирование → Обслуживание → Резервное копирование и восстановление → Создать резервную копию. Здесь же настраивается расписание автоматических копий.
• В Конфигураторе: Администрирование → Выгрузить информационную базу.

Выгрузка .dt из Конфигуратора требует монопольного доступа — перед ней все должны выйти из базы.

Клиент-серверная база (СУБД). Файл .dt годится как разовый «слепок», но штатное резервное копирование делают средствами СУБД (например, бэкап базы PostgreSQL или MS SQL Server по расписанию). Это надёжнее и не требует выгонять пользователей.

Восстановление. Из .dt — обратной командой (Загрузить информационную базу в Конфигураторе). Загрузка полностью затирает текущую базу данными из копии — всё, что сделано после создания копии, пропадёт. Поэтому перед восстановлением сохраняют ещё одну свежую выгрузку текущего состояния.

Несколько правил, которые экономят данные:

• 🗂️ Храните копии не на том же диске, где лежит база. Сбой диска не должен уносить и базу, и её бэкапы разом.
• 📆 Настройте расписание: ежедневная копия файловой базы и несколько последних версий «в глубину» (вчера, позавчера, неделю назад).
• ✅ Периодически проверяйте, что копия разворачивается. Нечитаемый .dt обнаруживается только в момент восстановления — худшее время для сюрпризов.

Для клиент-серверной базы расписание и глубину хранения удобнее задавать на стороне СУБД — там есть полноценные инструменты резервного копирования и ротации.

Частые ошибки при настройке администрирования

• ❌ Раздают роли вручную в Конфигураторе вместо профилей. В типовых базах такие права «теряются» при обновлении и ломают штатный механизм. Используйте профили групп доступа.
• ❌ Единственный администратор. Забытый пароль или уход сотрудника блокируют управление базой. Нужен запасной администратор.
• ❌ Запускают ТиИ или загрузку .dt в рабочее время. Сеансы пользователей обрываются, данные можно потерять. Только в простой и с копией.
• ❌ Журнал регистрации пишет «всё». Файл разрастается, база тормозит. Настройте состав событий под задачу.
• ❌ Путают выгрузку .dt с бэкапом СУБД. Для серверной базы .dt — не замена регулярному резервному копированию средствами СУБД.