Учётная запись разработчика больше не нужна: убираем её из хранилища 1С
Содержание
Чтобы удалить пользователя из
хранилища конфигурации 1С, откройте Конфигуратор под учётной записью с правом «Административные функции», выберите Конфигурация → Хранилище конфигурации → Администрирование, на вкладке пользователей выделите нужную строку и нажмите кнопку удаления. Перед этим снимите захват с объектов, которые этот пользователь держит: иначе они останутся заблокированными для остальных.
Удаление касается только хранилища. Учётная запись пользователя в самой информационной базе, его локальная конфигурация и уже помещённые им версии никуда не денутся. Ниже по порядку: что проверить, как удалить, что делать с захватами, историей и типичными отказами платформы.
Что проверить до удаления учётной записи
Сама операция занимает минуту. Проблемы возникают из-за того, что её делают «в лоб», не посмотрев на состояние хранилища.
Пройдите по списку:
- 🔑 Права администратора. Удалять пользователей может только тот, у кого в хранилище отмечено право «Административные функции». Обычному разработчику пункт администрирования недоступен или выдаёт отказ.
- 🔒 Захваченные объекты. Откройте окно хранилища (
Конфигурация → Хранилище конфигурации → Хранилище) и посмотрите, нет ли объектов, захваченных уходящим пользователем. Их нужно освободить заранее. - 💾 Незавершённая работа. Если человек ещё доступен, попросите его поместить готовые изменения в хранилище или выгрузить свою конфигурацию в файл
.cf. После удаления он уже ничего не поместит. - 🗂 Резервная копия. Для файлового хранилища скопируйте каталог целиком, для сервера хранилища (
crserver) — каталог, который он обслуживает. Копию делайте, когда к хранилищу никто не подключён. - 👥 Кто ещё администратор. Убедитесь, что после удаления в хранилище останется хотя бы одна учётная запись с административными правами и её пароль известен.
Сколько хранилищ на самом деле
Список пользователей у каждого хранилища свой. Один сервер crserver может обслуживать несколько каталогов, и в каждом сотрудник заведён отдельно. Удалили его в одном — в остальных он по-прежнему может работать.
Отдельно проверьте расширения конфигурации . Каждое расширение подключается к собственному хранилищу, и выбор хранилища для него делается в окне расширений. Если разработчик правил расширения, его учётную запись нужно убрать и там.
Перед началом составьте короткую таблицу: какие хранилища есть у базы, по каким адресам они лежат и где числится уходящий пользователь. Без такой сверки чаще всего остаётся «забытый» доступ к хранилищу расширения: основную конфигурацию почистили, а про расширение с доработками печатных форм никто не вспомнил. Адрес хранилища, к которому подключена база, виден в окне подключения к хранилищу и в заголовке окна хранилища.
Если сотрудник уходит не насовсем, а, например, в отпуск, удалять его не обязательно. Достаточно сменить пароль или снять права на захват. Учётная запись сохранится, история останется связана с привычным именем.
Как удалить пользователя хранилища в Конфигураторе
Порядок одинаков для файлового хранилища и для хранилища на сервере crserver (адрес вида tcp://server/repo). Разница только в том, как вы подключаетесь.
Пошагово
- Запустите Конфигуратор той базы, которая подключена к хранилищу.
- Если база не подключена, выполните
Конфигурация → Хранилище конфигурации → Подключиться к хранилищуи войдите под администратором хранилища. - Откройте
Конфигурация → Хранилище конфигурации → Администрирование. - В окне администрирования перейдите к списку пользователей.
- Выделите учётную запись, которую нужно убрать.
- Нажмите кнопку удаления в командной панели списка (значок с крестиком) или клавишу
Delete. - Подтвердите действие.
Подключаться к хранилищу из рабочей базы для этого не обязательно. Удобнее держать отдельную пустую или тестовую базу, из которой администратор подключается к хранилищу только для обслуживания.
Что происходит с записью после удаления
Пользователь теряет возможность подключиться к хранилищу. При попытке входа платформа сообщит, что имя или пароль неверны.
Версии, которые он помещал, остаются в истории под его именем. В актуальных версиях платформы удалённая запись не стирается бесследно: в списке пользователей можно включить показ удалённых и при необходимости восстановить учётную запись. Это удобно, если удалили по ошибке.
| Что меняется | После удаления |
|---|---|
| Вход в хранилище | Невозможен |
| Версии в истории | Остаются, автор прежний |
| Захваты объектов | Не снимаются автоматически |
| Пользователь в информационной базе | Не затрагивается |
| Локальная конфигурация сотрудника | Остаётся у него, но поместить её нельзя |
Захваченные объекты: как освободить их перед удалением
Это главный подводный камень. Удалили пользователя, а через неделю коллега не может изменить справочник: объект «захвачен» человеком, которого уже нет.
Способ 1. Пользователь сам отменяет захват
Если сотрудник на связи, это самый чистый вариант. Он открывает окно хранилища, выделяет свои объекты и выбирает либо помещение изменений, либо отмену захвата. Его наработки сохраняются в истории или осознанно выбрасываются.
Способ 2. Администратор отменяет чужой захват
Администратор хранилища может отменить захват объектов, захваченных другим пользователем. В окне хранилища:
- Включите отбор по захваченным объектам или найдите их по значку замка.
- Выделите объекты уходящего сотрудника.
- Выполните отмену захвата из контекстного меню.
Изменения, которые этот пользователь сделал у себя локально и не поместил, в хранилище не попадут. Если они нужны, сначала получите от него файл .cf и сравните с конфигурацией хранилища.
Способ 3. Войти от имени пользователя
Приём практика для случая, когда сотрудник недоступен, а изменения на его машине уже не важны:
- Администратор в окне администрирования открывает карточку пользователя и задаёт новый пароль.
- Из тестовой базы подключается к хранилищу под этим именем.
- Отменяет захват всех объектов от его лица.
- Отключается и удаляет учётную запись.
Так видно точный список захватов именно этого пользователя, и ничего лишнего случайно не освобождается.
Можно ли поправить права «вручную» в файлах хранилища
Короткий ответ: штатного файла прав, который можно открыть блокнотом, у хранилища нет.
Список пользователей, их права и пароли хранятся внутри служебной базы хранилища — файла 1cv8ddb.1CD в каталоге хранилища. Это файловая база формата 1С, а не текстовый конфиг. Платформа не предусматривает её правку в обход Конфигуратора.
Когда о ручной правке всё же заходит речь:
- 🔐 Забыт пароль единственного администратора. Штатно восстановить его нельзя. Варианты: вернуть каталог хранилища из резервной копии, где пароль известен, или создать новое хранилище из актуальной конфигурации.
- 🧰 Сторонние утилиты для
.1CD. Существуют программы, которые открывают такие файлы и позволяют менять таблицы, в том числе таблицу пользователей. Это неподдерживаемый путь: одна неверная правка — и хранилище не откроется.
Если всё же идёте этим путём, работайте только с копией каталога, при остановленной службе crserver и без подключённых пользователей. Остановка сервера хранилища обрывает работу всех разработчиков, делайте это вне рабочего времени и предупредите команду.
Для обычной задачи «убрать одного человека» ручная правка не нужна никогда. Хватает окна администрирования.
История версий: что останется от пользователя
Многих смущает, что имя уволенного сотрудника продолжает мелькать в истории. Это нормальное и правильное поведение.
Почему из истории его не убрать
История хранилища — журнал изменений: кто, когда и что поменял. Выборочно удалить версии одного автора, оставив остальные, штатно нельзя. Иначе нарушилась бы цепочка изменений: следующие версии опираются на предыдущие.
Это скорее плюс. Через год вы откроете историю модуля и увидите, кто и с каким комментарием внёс спорную правку.
Если след нужно убрать полностью
Бывает, что требование идёт от службы безопасности или хранилище переносится к другому подрядчику. Тогда вариант один: начать новое хранилище.
- Получите из старого хранилища последнюю версию конфигурации.
- Отключите базу от старого хранилища.
- Создайте новое хранилище через
Конфигурация → Хранилище конфигурации → Создать хранилище. - Заведите в нём только нужных пользователей.
- Старое хранилище сохраните как архив только для чтения.
История в новом хранилище начнётся с первой версии. Всё, что было раньше, останется в архиве, и туда при необходимости можно заглянуть.
Перед переездом поставьте в старом хранилище метку на последнюю версию (например, «Перенос в новое хранилище»). По ней потом легко найти точку разрыва.
Ошибки при удалении и что с ними делать
Ниже собраны ситуации, на которые чаще жалуются администраторы хранилищ. Выберите свою.
Как держать доступ к хранилищу в порядке
Удаление пользователя — частый повод навести порядок во всём списке. Несколько правил, которые избавляют от проблем при следующем увольнении.
Одна учётная запись на одного человека
Общий логин вида «Разработчик» или «Подрядчик» ломает смысл истории: непонятно, кто внёс правку. И его нельзя отключить для одного человека, не задев остальных. Заводите записи по фамилиям.
Минимум прав
| Роль | Захват объектов | Изменение состава версий | Административные функции |
|---|---|---|---|
| Разработчик | Да | Нет | Нет |
| Ведущий разработчик | Да | Да | Нет |
| Администратор хранилища | По необходимости | Да | Да |
| Аудитор, тестировщик | Нет | Нет | Нет |
Учётная запись без прав на захват всё равно может читать хранилище и получать конфигурацию. Этого достаточно для тестировщика и для обновления рабочей базы.
Регламент при уходе сотрудника
Два администратора
Держите минимум две учётные записи с административными правами, пароли храните в менеджере паролей компании. Тогда потеря одного пароля не превратится в вопрос о правке 1cv8ddb.1CD.
Частые вопросы
Удаляется ли пользователь информационной базы вместе с пользователем хранилища?
Администрирование → Пользователи в Конфигураторе или в режиме Предприятия, пользователи хранилища — только в окне администрирования хранилища.