Всем привет, как можно сделать неактивной роль? Чтобы и в конфигураторе и в режиме предприятия нельзя было назначить при определенных условиях эту роль?

Удалить эту роль.

Она должна быть активна в определённых случаях

(2) в каких случаях она неактивная нужна?

(3) Идея сделать суперадминистратора, который единственный сможет выгружать базу. И только он может назначать эту роль, для всех остальных ролей роль суперадминистратор будет неактивна

Чем полыне права не устраивают?

полные*

Полные права тоже подойдут, но я же смогу например зайти под ролью администратор  в конфигуратор и назначить полные права другому юзеру, чтобы тот выгрузку делал.  А мне нужно чтобы только одна роль могла раздавать возможность выгрузки, чтобы нельзя было назначать ее в конфигураторе/предприятии другими ролями.

На фрилансе сказали в лёгкую можно сделать неактивной роль, но покажут только по предоплате. В режиме предприятия можно ещё сделать, а в конфигураторе скрывать роль/делать неактивной разве можно?

Тут именно нужно чтобы выгрузка была доступна под одной ролью, и ее нельзя было назначить из под других ролей

в 1с так нельзя

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

сервис конечно на удаленной машине, чтоб пароли никто не знал

Да, но получается в любом случае в конфигураторе будет возможность расшарить выгрузку любому пользователю... а мне нужно чтобы один юзер только мог делать это

Если бы был обработчик перел выгрузкой, там конечно можно было бы программно проверить, кто выгружает... но такого нет же?

(0) право Администрирование?

(13) нет,

либо только суперадминистратор имеет админские/полные права в базе, либо как в (10) настраивать доступ к уже выгруженному файлу

"На фрилансе сказали в лёгкую можно сделать неактивной роль, но покажут только по предоплате"

я бы попробовал, а то вдруг мы чего не знаем)

Интересно - зачем это надо и что вообще пользователи делают в конфигураторе...

(17) на самом деле просто нужно уберечь от выгрузки базу администратором. Он может заходить  в конфигуратор, накатывать обновления, создавать пользователей, присваивать им роли и права, ну и вот нужно лишить его возможности делать выгрузку...

(18) От админа защиты нет. Иначе это не админ. Организационные проблемы программным путем не решаются.

(18) будучи сотрудником франча как то был на доработка у крупного клиента. Были все права в базе, но при попытке выгрузить базу вываливалась ошибка SQL. Видимо какой-то триггер на СУБД срабатывал. Дело было 10 лет назад.

(20) Ну тогда ТС скажет, что его "администратор" должен иметь полные права в SQL, но не имееть возможность менять этот триггер и выгружать базу из SQL :)

ТО есть , выгрузить он ее не может, а скопипастить ее физически или ее беакап может, так ведь, что за бред?
у админа с правами админа +100500 способов скопипастить базу...

(20) звучит убедительно и в тему! :) буду копать в этом направлении...

(23) В sql от админа тоже защиты нет, триггеры тоже отключаются.

потом будет
база при обновлении померла
бекапов нет,так как запретили их делать

вот уж точно,кто обновляет должен делать бекапв и лучше один до а второй после

(25) бекапы как раз есть, делаются отдельным подразделением просто)

(26) тогда в чем вопрос - пусть они и обновляют,а остальным в конфигураторе делать нечего.
для разработчиков создать отдельную базу  с тестовыми данными.

(24) Админ сервера SQL и админ в базе 1С - это два разных понятия. Вообще то.
Но сути это не меняет. Админ базы может делать с неё всё что угодно.

По поводу (20) Могу предположить, что в СУБД была закрыта возможность получения монопольного доступа, необходимого для выгрузки в DT. Но тогда не ясно как происходило обновление конфигурации, требующее реструктуризации.

(26) >> бекапы ... делаются отдельным подразделением просто.

Что у вас там за дичь творится... Бекапы должны делаться автоматически планами обслуживания, а не людьми или подразделениями.

Охренеть. Целое подразделение бекапистов. Интересно, какая у них структура?

Вообще по идее всё можно автоматизировать.
Если по классике, то должно быть 4 изолированных контура - разработочный, тестовый, предрелизный, продуктивный. Разработчики, имея доступ в первые три контура вообще не имеют никакого доступа в продуктивный - ни к серверу СУБД, ни к серверу 1С, ни к базам. В разработочном и тестовом контуре данные далёкие от реальных - либо наполнение данными баз производится специальными обработками, либо обфусцируются реальные данные (для обеих задач есть соответствующие инструменты 1С).
Обновление конфигурации в продуктиве происходит автоматически скриптами из хранилища без участия человека. В конфигурациях на БСП есть целая подсистема обновления конфигурации, где можно создать свою подсистему, вести её версионирование, писать свои обработчики обновления и т.д.
Остаётся пользователь с админскими правами в базе, который заводит других пользователей и раздаёт им права. Эта проблема решается двумя путями. Либо административным путём - этим должен заниматься доверенный пользователь (например, кто-то из руководителей). Либо программным - допилить форму элемента справочника Пользователи таким образом, чтобы к справочнику имел доступ пользователь с урезанными (НЕадминискими) правами (например, только на просмотр), но обработчики некоторых команд и действий на этой форме выполнялись в привилегированном режиме. Или вообще написать свою форму или обработку, позволяющую настраивать права при фактическом отсутствии у пользователя административных прав.

(30) Если у них там 40 баз + каталоги пользователей и прочие файлопомойки + распределённые филиалы - почему бы и не иметь buzzword "отдел бекапирования"?

(32) Да хоть в два раза больше и сложнее. Обычно за подобные вещи отвечает один админ, в сферу ответственности которого входит настройка роботов для автоматического создания бекапов (один раз),  настройка контроля работы созданных роботов с оповещениями о результатах и сбоях (один раз), проверка целостности бекапов (периодически). Целый отдел для этого держать - дичь.
В больших компаниях, где есть отделы админов, может быть так, что за бекапирование каждого отдельного сервиса отвечает отдельный админ (DBA 1С - за за бекапы 1С-ных баз, админ файловых серверов - за них, админ почтовых сервисов - за бекап почты и т.д.). Но в таком случае это не есть их единственная функция. У автора быть может именно такой вариант.