Рассмотрим весьма неприятную ситуацию, с которой может столкнуться каждый администратор или разработчик 1С. При попытке входа в режим Предприятия система выдает сообщение: «Ошибка: недостаточно прав для работы с таблицей Справочник.Пользователи». Самое парадоксальное в этой проблеме то, что ошибка возникает даже при попытке авторизации под пользователем, у которого формально установлена роль «Полные права». В Конфигуратор при этом может как пускать, так и нет. Давайте проанализируем причины такого поведения платформы и разберем по шагам все возможные способы восстановления доступа к вашей базе данных.
Прежде чем приступать к «хирургическому» вмешательству в базу, выясним причину возникновения проблемы. Платформа блокирует доступ, когда внутренние механизмы авторизации не могут сопоставить права пользователя с объектами базы данных. Это может происходить по нескольким причинам:
Справочник.Пользователи или случайно ограничить к нему доступ.Давайте начнем с самых безопасных методов. Если вас пускает в Конфигуратор, но не пускает в Предприятие, проанализируем ситуацию с расширениями и кэшем.
1. Очистка кэша
Первым делом всегда чистите кэш 1С. Удалите базу из списка в окне запуска платформы и добавьте ее заново, либо используйте специальные утилиты для очистки временных файлов 1С в папках AppData\Local\1C и AppData\Roaming\1C.
2. Отключение расширений конфигурации
Если мы подозреваем, что проблема кроется в расширениях, давайте запустим базу в обход их влияния. Для этого в свойствах информационной базы (в окне запуска 1С) в поле «Дополнительные параметры запуска» пропишем следующий ключ:
/DisableEnterpriseExtensions
Этот параметр заставит платформу проигнорировать все подключенные расширения при запуске Предприятия. Если вход прошел успешно, значит, одно из расширений ломает систему прав. Вам останется только найти виновника опытным путем, поочередно отключая их в Конфигураторе.
Если мягкие способы не помогли или доступ закрыт даже в Конфигуратор, нам придется действовать на уровне Системы Управления Базами Данных (СУБД). Рассмотрим подробнее манипуляции с таблицами. Наша задача — временно «спрятать» таблицу пользователей от 1С, чтобы платформа решила, что база пустая, и пустила нас без пароля. После этого мы подменим таблицу обратно.
Откройте SQL Server Management Studio (SSMS), выберите вашу базу данных и выполните первый скрипт. Обязательно сделайте бэкап базы перед выполнением! При регулярном обслуживании нескольких баз процесс создания резервных копий и тестирования автоматизирует программа для пакетного архивирования и обновления 1С.
EXEC sp_rename 'v8users', 'v8users_old'
GO
UPDATE Params
SET FileName = 'users.usr_old'
WHERE FileName = 'users.usr'
GO
Что мы сделали? Мы переименовали физическую таблицу v8users и изменили запись в системной таблице Params, где 1С хранит внутренний файл списка пользователей. Теперь для платформы пользователей не существует.
Далее разберем по шагам:
DROP TABLE v8users
GO
EXEC sp_rename 'v8users_old', 'v8users'
GO
UPDATE Params
SET FileName = 'users.usr'
WHERE FileName = 'users.usr_old'
GO
Мы удалили пустую таблицу, которую 1С успела создать при входе, и вернули наши старые данные. Теперь в открытом Конфигураторе мы можем зайти в меню «Администрирование» — «Пользователи» и пересохранить права проблемному администратору (снять галочку с роли, сохранить, снова поставить галочку и сохранить). Это обновит внутренние идентификаторы.
Проанализируем ту же ситуацию, но если ваша 1С работает на сервере PostgreSQL. Логика остается абсолютно такой же, но синтаксис SQL-запросов будет отличаться. Выполняем скрипты через pgAdmin или консоль.
Скрипт 1: Прячем пользователей от платформы:
ALTER TABLE v8users RENAME TO v8users_old;
UPDATE Params SET FileName = 'users.usr_old' WHERE FileName = 'users.usr';
Заходим в Конфигуратор 1С без пароля, оставляем его открытым и выполняем Скрипт 2 (возвращаем данные):
DROP TABLE v8users;
ALTER TABLE v8users_old RENAME TO v8users;
UPDATE Params SET FileName = 'users.usr' WHERE FileName = 'users.usr_old';
Пересохраняем права пользователей в открытом конфигураторе.
Рассмотрим алгоритм действий, если у вас файловая база данных и SQL-запросы вам не помогут. В этом случае нам понадобится специализированная утилита Tool_1CD (программа для прямого просмотра и редактирования файлов баз 1С) или обычный Hex-редактор.
1Cv8.1CD.cnvdbfl.exe, которая лежит в папке bin установленной платформы. Понизьте формат базы до версии 8.2.14 командой: cnvdbfl.exe -c -f 8.2.14 путь_к_базе\1Cv8.1CD.V8USERS.DATA найдите текущий хэш вашего пароля. Замените его на хэш от пустой строки: 2jmj7l5rSw0yVb/vlWAYkK/YBwk=.cnvdbfl.exe (хотя платформа может сделать это и сама при первом запуске).После того как мы успешно проникли в базу и восстановили права, давайте посмотрим, что именно вызывало отказ. Зайдите в режим Предприятия или Конфигуратора, откройте Журнал регистрации.
Настройте фильтр событий: выберите событие «Доступ. Отказ в доступе». Внимательно проанализируем колонку «Данные». Там будет четко зафиксировано, на какое конкретно право (например, Чтение, Изменение или Добавление) и к какому конкретному объекту метаданных система не пропустила пользователя. Это может быть не только Справочник.Пользователи, но и связанные с ним регистры сведений или константы. Чтобы быстро определить, какие роли и профили дают доступ к заблокированному объекту, подойдёт инструмент для быстрой проверки прав доступа на объект метаданных.
Понимание точной причины отказа позволит вам точечно настроить нужную роль в Конфигураторе или корректно прописать пользователя в группы доступа RLS в режиме Предприятия, чтобы ошибка больше не повторялась. Для комплексного анализа и настройки ролей, профилей и ограничений RLS можно использовать обработку для управления правами и ограничениями доступа.