|
Сделать неактивной галку выбора определенной роли | ☑ | ||
---|---|---|---|---|
0
Dobriy
23.10.19
✎
09:21
|
Всем привет, как можно сделать неактивной роль? Чтобы и в конфигураторе и в режиме предприятия нельзя было назначить при определенных условиях эту роль?
|
|||
1
ДенисЧ
23.10.19
✎
09:27
|
Удалить эту роль.
|
|||
2
Dobriy
23.10.19
✎
09:33
|
Она должна быть активна в определённых случаях
|
|||
3
Kol Pecivanovich
23.10.19
✎
09:39
|
(2) в каких случаях она неактивная нужна?
|
|||
4
Dobriy
23.10.19
✎
09:43
|
(3) Идея сделать суперадминистратора, который единственный сможет выгружать базу. И только он может назначать эту роль, для всех остальных ролей роль суперадминистратор будет неактивна
|
|||
5
vicof
23.10.19
✎
09:48
|
Чем полыне права не устраивают?
|
|||
6
vicof
23.10.19
✎
09:48
|
полные*
|
|||
7
Dobriy
23.10.19
✎
10:03
|
Полные права тоже подойдут, но я же смогу например зайти под ролью администратор в конфигуратор и назначить полные права другому юзеру, чтобы тот выгрузку делал. А мне нужно чтобы только одна роль могла раздавать возможность выгрузки, чтобы нельзя было назначать ее в конфигураторе/предприятии другими ролями.
На фрилансе сказали в лёгкую можно сделать неактивной роль, но покажут только по предоплате. В режиме предприятия можно ещё сделать, а в конфигураторе скрывать роль/делать неактивной разве можно? |
|||
8
Dobriy
23.10.19
✎
10:33
|
Тут именно нужно чтобы выгрузка была доступна под одной ролью, и ее нельзя было назначить из под других ролей
|
|||
9
pechkin
23.10.19
✎
10:40
|
в 1с так нельзя
|
|||
10
pechkin
23.10.19
✎
10:42
|
но можно сделать сервис, который по бат файлу например запустит выгрузку и положит в католог.
а вот на католог уже нужные права |
|||
11
pechkin
23.10.19
✎
10:42
|
сервис конечно на удаленной машине, чтоб пароли никто не знал
|
|||
12
Dobriy
23.10.19
✎
10:47
|
Да, но получается в любом случае в конфигураторе будет возможность расшарить выгрузку любому пользователю... а мне нужно чтобы один юзер только мог делать это
|
|||
13
Dobriy
23.10.19
✎
10:48
|
Если бы был обработчик перел выгрузкой, там конечно можно было бы программно проверить, кто выгружает... но такого нет же?
|
|||
14
ssh2006
23.10.19
✎
10:54
|
(0) право Администрирование?
|
|||
15
Kol Pecivanovich
23.10.19
✎
10:56
|
(13) нет,
либо только суперадминистратор имеет админские/полные права в базе, либо как в (10) настраивать доступ к уже выгруженному файлу |
|||
16
Kol Pecivanovich
23.10.19
✎
11:04
|
"На фрилансе сказали в лёгкую можно сделать неактивной роль, но покажут только по предоплате"
я бы попробовал, а то вдруг мы чего не знаем) |
|||
17
unregistered
23.10.19
✎
11:30
|
Интересно - зачем это надо и что вообще пользователи делают в конфигураторе...
|
|||
18
Dobriy
23.10.19
✎
12:07
|
(17) на самом деле просто нужно уберечь от выгрузки базу администратором. Он может заходить в конфигуратор, накатывать обновления, создавать пользователей, присваивать им роли и права, ну и вот нужно лишить его возможности делать выгрузку...
|
|||
19
SSSSS_AAAAA
23.10.19
✎
12:16
|
(18) От админа защиты нет. Иначе это не админ. Организационные проблемы программным путем не решаются.
|
|||
20
ssh2006
23.10.19
✎
12:46
|
(18) будучи сотрудником франча как то был на доработка у крупного клиента. Были все права в базе, но при попытке выгрузить базу вываливалась ошибка SQL. Видимо какой-то триггер на СУБД срабатывал. Дело было 10 лет назад.
|
|||
21
Smile 8D
23.10.19
✎
14:22
|
(20) Ну тогда ТС скажет, что его "администратор" должен иметь полные права в SQL, но не имееть возможность менять этот триггер и выгружать базу из SQL :)
|
|||
22
Kigo_Kigo
23.10.19
✎
15:09
|
ТО есть , выгрузить он ее не может, а скопипастить ее физически или ее беакап может, так ведь, что за бред?
у админа с правами админа +100500 способов скопипастить базу... |
|||
23
Dobriy
23.10.19
✎
16:36
|
(20) звучит убедительно и в тему! :) буду копать в этом направлении...
|
|||
24
SSSSS_AAAAA
23.10.19
✎
17:09
|
(23) В sql от админа тоже защиты нет, триггеры тоже отключаются.
|
|||
25
Сияющий в темноте
23.10.19
✎
19:01
|
потом будет
база при обновлении померла бекапов нет,так как запретили их делать вот уж точно,кто обновляет должен делать бекапв и лучше один до а второй после |
|||
26
Dobriy
23.10.19
✎
22:30
|
(25) бекапы как раз есть, делаются отдельным подразделением просто)
|
|||
27
Сияющий в темноте
24.10.19
✎
08:39
|
(26) тогда в чем вопрос - пусть они и обновляют,а остальным в конфигураторе делать нечего.
для разработчиков создать отдельную базу с тестовыми данными. |
|||
28
unregistered
24.10.19
✎
08:56
|
(24) Админ сервера SQL и админ в базе 1С - это два разных понятия. Вообще то.
Но сути это не меняет. Админ базы может делать с неё всё что угодно. По поводу (20) Могу предположить, что в СУБД была закрыта возможность получения монопольного доступа, необходимого для выгрузки в DT. Но тогда не ясно как происходило обновление конфигурации, требующее реструктуризации. |
|||
29
unregistered
24.10.19
✎
08:59
|
(26) >> бекапы ... делаются отдельным подразделением просто.
Что у вас там за дичь творится... Бекапы должны делаться автоматически планами обслуживания, а не людьми или подразделениями. |
|||
30
Fish
24.10.19
✎
09:00
|
Охренеть. Целое подразделение бекапистов. Интересно, какая у них структура?
|
|||
31
unregistered
24.10.19
✎
10:14
|
Вообще по идее всё можно автоматизировать.
Если по классике, то должно быть 4 изолированных контура - разработочный, тестовый, предрелизный, продуктивный. Разработчики, имея доступ в первые три контура вообще не имеют никакого доступа в продуктивный - ни к серверу СУБД, ни к серверу 1С, ни к базам. В разработочном и тестовом контуре данные далёкие от реальных - либо наполнение данными баз производится специальными обработками, либо обфусцируются реальные данные (для обеих задач есть соответствующие инструменты 1С). Обновление конфигурации в продуктиве происходит автоматически скриптами из хранилища без участия человека. В конфигурациях на БСП есть целая подсистема обновления конфигурации, где можно создать свою подсистему, вести её версионирование, писать свои обработчики обновления и т.д. Остаётся пользователь с админскими правами в базе, который заводит других пользователей и раздаёт им права. Эта проблема решается двумя путями. Либо административным путём - этим должен заниматься доверенный пользователь (например, кто-то из руководителей). Либо программным - допилить форму элемента справочника Пользователи таким образом, чтобы к справочнику имел доступ пользователь с урезанными (НЕадминискими) правами (например, только на просмотр), но обработчики некоторых команд и действий на этой форме выполнялись в привилегированном режиме. Или вообще написать свою форму или обработку, позволяющую настраивать права при фактическом отсутствии у пользователя административных прав. |
|||
32
ДенисЧ
24.10.19
✎
10:21
|
(30) Если у них там 40 баз + каталоги пользователей и прочие файлопомойки + распределённые филиалы - почему бы и не иметь buzzword "отдел бекапирования"?
|
|||
33
unregistered
24.10.19
✎
10:46
|
(32) Да хоть в два раза больше и сложнее. Обычно за подобные вещи отвечает один админ, в сферу ответственности которого входит настройка роботов для автоматического создания бекапов (один раз), настройка контроля работы созданных роботов с оповещениями о результатах и сбоях (один раз), проверка целостности бекапов (периодически). Целый отдел для этого держать - дичь.
В больших компаниях, где есть отделы админов, может быть так, что за бекапирование каждого отдельного сервиса отвечает отдельный админ (DBA 1С - за за бекапы 1С-ных баз, админ файловых серверов - за них, админ почтовых сервисов - за бекап почты и т.д.). Но в таком случае это не есть их единственная функция. У автора быть может именно такой вариант. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |