Программный запрет удаления элемента справочника #670619

Платформа 1С 8.2.16.368 Конфигурация Бухгалтерия 3.0.21.14 Задача в справочнике "Пользователи" добавлен реквизит - доступ к справочнику "Мой справочник". В справочнике "МойСправочник" необходимо запретить установку пометки удаления на элемент списка справочника. Элементы справочника редактируются в форме списка. Процедура модуля формы списка &НаКлиенте тупо не отрабатывает. Процедура в модуле объекта &НаСервере Процедура ПередЗаписью(Отказ) В принципе приводит к желаемому результату, но выглядит не кошерно. Во-первых программа предлагает вопрос "пометить на удаление? да нет" Во-вторых после него появляется предупреждение с ошибкой о невозможности записи элемента. Есть ли более аккуратные способы программно предотвратить установку пометки удаления? в идеале до появления вопроса вывести пользователю предупреждение об отсутствии прав и отменить событие. З.Ы. Настройку прав в конфигураторе просьба не предлагать. Это самый крайний случай.

а почему просто права не отобрать?

рлс рулит)

Если ПометкаУдаления <> Ссылка.ПометкаУдаления тогда

>>Это самый крайний случай Это самый нормальный вариант. программные затычки для этой цели - и есть быдлокод

ну это для того что бы и снять было нельзя. Но кошерности это не добавляет. Все равно вопрос выводиться и все равно процедура сообщает об ошибке записи. я именно это хочу обойти. Собственно есть ли такая возможность или нет смысла биться головой об стену.

тебе уже сказали про права... и вопрос не в тему, на фига в модуле объекта &НаСервере?

а не проще ли подписку на событие ?

а как выглядит нормальный вариант для ситуации Пользователь 1 - имеет право редактировать номенклатуру. Но не имеет права редактировать контрагентов. Пользователь 2 имеет право редактировать контрагентов, но не имеет права редактировать номенклатуру. Пользователь 3 имеет право редактировать и контрагентов и номенклатуру.

от проблем автора это не спасёт

ну я так в нетленке делал. там рлс нету и не хочу. так как конфу переписываем. пока не до них :)

у тебя затычка на запрет интерактивной пометки на удаления. Это легко решается галкой в правах... при чем тут данный пример?

Удали типовую кнопку и размести свою.

Достаточно частая задача, когда права настраиваются не ролями, а настройками в справочниках.

а тупо найти где выводится "пометить на удаление?" и переписать тоже не предлагать или глобальный поиск не рулит?

ну как бы запрет редактирования пользователю предполагает и запрет пометки элемента справочника на удаление. Понятно, что это решается правами - но в пределе это ведет к тому что для каждого пользователя формируется индивидуальный набор прав. И когда их набирается штук 30-40 их администрирование и обновление конфигурации становится слегка не тривиальной задачей. Есть еще кнопка del. уже.  Есть такая сообщалка - но в из справочников не вызывается. Вызывается при сохранении настроек отчетов и из дополнительных отчетов и обработок

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

РЛС то чем не нравится?

А чем в данном случае РЛС то отличается? Я так же из ПередЗаписью Вызываю контроль прав. Или я чего то не догоняю?

если в модуле объекта к процедуре ПередЗаписью поставить директиву "наКлиенте" - она тупо не отрабатывает.

да в принципе конечно ничем, если ещё и перед открытием будешь вызывать контроль прав и лочить форму от изменений. Но от вопроса "Пометить на удаление" - не уйти

забери у всех ролей право интерактивной пометки удаления. Потом добавь роль, у которой только это право и есть. Реквизит свой выкинь к херам - он не нужен. Пользователям, которым хотел расставить реквизит, выдай новую роль с одним правом

в том-то и дело, что там вообще директивы компиляции не нужны... модуль объекта всегда на сервере...

так "СписокПередНачаломДобавления" и "СписокПередНачаломИзменения" отрабатывают штатно и никаких проблем не вызывают. В принципе пользователь без галочки ничего сделать в справочнике не может. Формально задача решена - только в случае пометка на удаление - выглядит криво. И не было бы так обидно - если бы в форме списка не было события "ПередУдалением" которое тупо не работает. если бы все так просто - см и

Спс. буду знать. Как то до УФ раньше руки не доходили.

все именно и есть ТАК просто. Это называется проектирование профилей пользователей. А твой реквизит - быдлокод

Ну и как просто решить задачу из пункта 8? умножив ее хотя бы на 5

а есть чтиво (инфа) по этому самому проектированию?

Добавить роли: 1. Редактирование номенклатуры 2. Редактирование контрагентов 3. Пометка удаления номенклатуры и контрагентов Определить (хоть на бумажке, хоть из ДО выдрать) профили: 1. Человек первого сорта - все три роли 2. Человек второго сорта - только первая роль 3. Человек третьего сорта - только вторая роль 4. Вообще не человек, а робот - только третья роль 5. ..... свой вариант, если есть И раздавать людям роли в соответствии с этими профилями. Если группы доступа из документооборота, например, выдрать или что-то подобное самому смастерить, то можно людям прямо непосредственно профили раздавать.

Ага. Главное потом заказчика убедить этим профилям следовать. Потому что на практике все стремится к тому что фактически у каждого пользователя индивидуальный профиль. Создать индивидуальные профили можно - управлять ими примерно через год становится невозможно. Уже проходили.

а реквизитами твоими и костылями в коде, что легко будет через год управлять?

зачем реквизит ? лучше уже РС с доп настройками и подписки на события. если влом РЛС использовать

Как показывает практика - гораздо легче. По факту у заказчика есть только три профиля Главный бухгалтер, пользователь и только просмотр. Однако затем возникают потребности запретить конкретным пользователям доступ к конкретным объектам. Если бы у 1С были права - запретить чтение, запретить изменение, запретить удаление с приоритетом над разрешением и возможность раздать роль всем пользователям (как в файерволлах) было бы проще - создал роль "запрет изменения контрагентов" назначил всем, у нужных снял. Однако по факту получается - есть пользователи - у всех есть права к контрагентам. Потом через месяц выясняется, что некий пользователь накосячил, кто то попал на разборки и следует директива - запретить доступ всем пользователям к изменениям справочника контрагенты, кроме пупкина. Как это происходит в 1С - нужно у роли "пользователь" отключить доступ к контрагентам. Создать отдельную роль "доступ к контрагентам" дать ее Пупкину. И так раз 100. И все бы ничего, но через год-два понять к каким объектам имеет доступ роль "пользователь" тупо невозможно - потому что надо зайти в каждый объект по дереву роли и проверить наличие галочек.

а чем лучше?

посмотри реализацию типовых. у них доп права реализованы через РС и РЛС. ты можешь использовать РС и подписки на событие

делай через реквизит, мне пофиг