Платформа 1С 8.2.16.368
Конфигурация Бухгалтерия 3.0.21.14

Задача в справочнике "Пользователи" добавлен реквизит - доступ к справочнику "Мой справочник".
В справочнике "МойСправочник" необходимо запретить установку пометки удаления на элемент списка справочника. Элементы справочника редактируются в форме списка.

Процедура модуля формы списка
&НаКлиенте
Процедура СписокПередУдалением(Элемент, Отказ)
   // Вставить содержимое обработчика.
КонецПроцедуры

тупо не отрабатывает.

Процедура в модуле объекта
&НаСервере
Процедура ПередЗаписью(Отказ)
    Если ПометкаУдаления тогда
         Отказ = не ЕстьПрава();
       Если Отказ тогда
           Возврат;
       КонецЕсли;
   КонецЕсли;
КонецПроцедуры

В принципе приводит к желаемому результату, но выглядит не кошерно.

Во-первых программа предлагает вопрос "пометить на удаление? да нет"
Во-вторых после него появляется предупреждение с ошибкой о невозможности записи элемента.

Есть ли более аккуратные способы программно предотвратить установку пометки удаления? в идеале до появления вопроса вывести пользователю предупреждение об отсутствии прав и отменить событие.

З.Ы. Настройку прав в конфигураторе просьба не предлагать. Это самый крайний случай.

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

рлс рулит)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(14) уже.  Есть такая сообщалка - но в из справочников не вызывается. Вызывается при сохранении настроек отчетов и из дополнительных отчетов и обработок

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

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

(17) А чем в данном случае РЛС то отличается?

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

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

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

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

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

(20)
так "СписокПередНачаломДобавления" и "СписокПередНачаломИзменения" отрабатывают штатно и никаких проблем не вызывают.

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

(21) если бы все так просто - см (8) и (15)

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

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

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

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

(26) Добавить роли:
1. Редактирование номенклатуры
2. Редактирование контрагентов
3. Пометка удаления номенклатуры и контрагентов

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

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

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

Создать индивидуальные профили можно - управлять ими примерно через год становится невозможно.
Уже проходили.

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

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

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

Однако по факту получается - есть пользователи - у всех есть права к контрагентам. Потом через месяц выясняется, что некий пользователь накосячил, кто то попал на разборки и следует директива - запретить доступ всем пользователям к изменениям справочника контрагенты, кроме пупкина.

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

(31) а чем лучше?

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

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