Коллеги, здравствуйте! Имеется задача: пользователю с базовыми правами (типовая конфигурация, не важно какая, 8.2, толстый клиент) требуется "поднять" права до требуемых, но без использования новой Роли, то бишь программно (а как же еще!?). Вопрос: зачем? Ответ: надо! :) (а вы думаете, что мне иначе ответили?). Как думаете, что можно сделать? Желательно, все сделать через код, допускается изменение шаблонов ограничений. Спасибо!
(1) DoctorRoza, у нас в базе есть такая фишка как дополнительные права пользователей. Добавляется в план видов характеристик реквизит, пишется код. Затем юзеру у кого этот реквизит проставлен повышаются права.
(1) DoctorRoza, требуется разовое повышение прав во время выполнения процедуры или конкретно добавить пользователю права на постоянку?
в первом случае подойдет УстановитьПривилегированныйРежим(ИСТИНА); во втором пока не подскажу
(8) AnryMc, дело в том, что нельзя просто создать новую Роль, инспекция потребует обоснование (компания такая). Руководство, избранным пользователям, хочет дать определенные права - например, главБуха, но чтобы инспекция не заметила. Сам знаю, что сие не комильфо, но требуется решение. При том, только кодом, например, при инициализации сеанса или что-то в этом роде.
(11) DoctorRoza,
Потому и спрашиваю что собственно нужно... Возможны какие нибудь "технологические" решения - например через внешние формы (отчеты, обработки) например с учетом
(3) nihfalck, использовать "нетипично" http://infostart.ru/public/163222/
(17) AnryMc, постановка задачи простая: есть пользователь (Маша). Она очень хороший бухгалтер и может выполнять работу главного бухгалтера (например, видеть ЗП), но ей не могут дать права главБуха, так как она только бухгалтер. Почему не могут? Политика ограничений прав .. и точка. Это не пробиваемо, чеслово! Вот и задача от директора по БУ, сделать так, чтобы Маша, могла получить права глав буха, только чтобы .. Большой Брат .. не обнаружил! Передача паролей, логинов наказуемо преданием анафиме и увольнением с жуткой записью в трудовой. Как-то так!
(19) DoctorRoza, вот и не нужно нарушать политику. Нельзя так сделать и точка. Если все так строго, то тем более, если вскроется, то и вас за компанию под расход пустят.
(21) Boneman, когда я, будучи курсантом, сказал ротному, мол то и то сделать нельзя, на что он меня спросил: "А что ты сделал, что пришел к такому выводу? Покажи порядок своих действий!". Вот! Сейчас я все перепроверю, если действительно не знаю, и только тогда даю ответ. Но с Вами согласен, не совсем благодарное дело.
(24) DoctorRoza, учитывая все имеющиеся ограничения и тп, я не вижу адекватных способов решения проблемы.
Впрочем неадекватные методы есть и без Привилегированного Режима не обойтись..
Неадекватны они потому, что трудоемки и это будет не пара строчек кода, которые будут давать права юзеру, а возможно много строк кода и времени займет немало:
1) если пользователь видит необходимые справочники и документы, но не может их править или проводить, тогда всё просто (относительно) - УстановитьПривилегированныйРежим() и сохраняем\проводим программно (добавив избранному пользователю отдельные кнопки, так как стандартные будут неактивны или скрыты при отсутствии прав)
2) если же права юзера не позволяют даже видеть нужные документы, тогда добавляется много геморроя) можно в любой другой форме, которую пользователь видит, сделать скрытую страницу или страницы, копирующие формы необходимых документов) сделать их видимыми только нужному пользователю программно и опять же через привилегированный режим программно работать с нужными документами, но тут уж сами понимаете, что это не на пол часа работы... стоит ли игра свеч? По-моему нет)))
К тому же в таких методах стоит учитывать тот факт, что в документе может фиксироваться кто его создал или кто последний вносил изменения, получится не очень весело, если там будет фигурировать бесправный пользователь. Я бы не стал к такому прибегать и попытался как-то уладить "бумажный" вопрос с политикой компании и согласовать с нужными службами повышение прав пользователю... последовать совету из (22) в общем)))
(11) DoctorRoza, решение - пойти к начальству и сказать: "У нас в бухгалтерии завелись вредители, которые хотят тайно повысить права пользователей".
По-моему если на2.718бывать фирму, то уж хотя бы ради какого-то профита, а так-то это вам зачем?
(13) vasyak319, никто фирму не на2.718бывает, пытаемся обойти некоторые препоны. Руководство само поставило такой вопрос, сам бы не догадался ! :) Сейчас уже интересуюсь эксперимента ради!
(11) DoctorRoza, то есть Вы хотите, чтобы права появились, но записей об этом никаких не было?) в смысле пользователь не добавляется в какие-то группы, у него не появляются новые роли, в общем чтоб глядя на пользователя нельзя было сказать, что у него эти права есть?
(11) DoctorRoza, непонятно, роль - есть, или роли нету ?
Смотри, предопределенный набор ролей программно изменить нельзя,
т.е. в конфигурации присутствуют всякие разные роли.
А вот назначить/убрать пользователю какую-то имеющуюся роль, вполне можно, это в (10) DJDUH уже написал как сделать,
в принципе в типовых конфах это все есть, можно вполне в пользовательском режиме дать нужному пользователю хоть полные права.
Правда зайдя в конфигуратор, мы естественно увидим, что у пользователя проставилась галка на нужной роли.
Создать в принципе новую роль, программно нельзя.
Все копания в коде, имхо, но занятие бесполезное. Т.к, роли регулируют различного рода доступы к регистрам, справочниками, документам, проведения, задними числами и т.п.
да даже элементарные запросы перестанут работать.
Привелигированный режим, работает только в рамках процедуры а не навсегда. И это, только то-что платформой отсекается. А еще возможны проверки на доступность ролей в самых разных местах конфигурации, и даже во внешних каких то обработках. Замучаетесь лопатить.
Так можно сделать, только если есть какой то определенный документ, и в нем что-то не работает, можно попытаться его немного переделать под нужного пользователя.
на счет политики компании - уж очень странная она... если регламенты мешают нормальной работе - нафиг такие регламенты.
а по теме - имейте в виду, что изменение данных фиксируется в журнале регистрации. так что Большой Брат все равно спалит.