Тонкий клиент 8.3. Некоторые проверки на корректность документов выведены в ПриЗаписиНаСервере с "РежимЗаписи=Проведение" форм документов.

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

Платформой можно запретить интерактивное проведение, разрешив неинтерактивное, но не наоборот.

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

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

Вопрос: как?

>> ПриЗаписиНаСервере с "РежимЗаписи=Проведение"
Тут всё норм, работает как и задумано. Просто это форма говнокода такая.
Более частая разновидность - вместо ОбработкиЗаполнения использовать "ПриСозданииНаСервере".

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

>> В идеале...
Все проверки критичные делать в обработчиках событий ОБЪЕКТА, а иначе это звучит как: "Помогите заставить работать говнокод не трогая его".

>>Проведение из формы списка тоже интерактивное.
Давайте не будем скатываться в демагогию, я ж написал, что под "интерактивным" понимается проведение с отработкой обработчиков ФормыДокумента (ПриЗаписиНаСервере и это вот всё). Можете назвать это любым другим термином, но вопрос не о терминологии.

>>Все проверки критичные делать в обработчиках событий ОБЪЕКТА, а иначе это звучит как: "Помогите заставить работать говнокод не трогая его".
Вы это, категоричность джуна-то приберегите для других джунов) Т.к. можете быть не правы чуть менее, чем полностью.

В пользу 100% оправданности подобного подхода в ряде ситуаций я с ходу могу привести с десяток причин. Некоторые из них:

1. Любые ресурсоемкие и не критичные с точки зрения консистентности данных БД проверки имеет смысл запускать при создании или изменении документа пользователем, но они становятся избыточными при автоматическом перепроведении без изменения (например, сложные проверки на права доступа, типа, "если правится док старше Х дней по такой-то организации и с таким-то ассортиментом, то отказ") важны при создании дока, но если он уже создан и проведен, то эти проверки при автоматическом перепроведении без изменения не имеют смысла и только тратят ресурсы). Вынос конкретных проверок, позволяющих это сделать без ущерба функциональности, в форму документа, как и полное отключение RLS и привилегированный режим в регламентных процедурах, может ускорить восстановление последовательностей документов в разы/порядки (8 часов против 5-6 суток перепроведения квартала, как живой пример вам).

2. Часто смысл проверки заключается в том, чтобы не дать провести документ с нелегитимными данными, но нелегитимность можно разделить на внутреннюю (согласованность данных документа) и внешнюю (согласованность дока с прочими данными БД). "Нельзя давать проводить док с заполненным некорректным значением реквизитом" - это внутренняя проверка, ее можно поместить в модуль объекта. Если документ, отражающий хозоперацию уже был проведен, а изменились вводные данные (остатки в регистре на момент времени дока), то не давать перепроводить его в рамках автоматического перепроведения - часто ненужная глупость. Например: при заведении оплаты м.б. проверка на то, чтобы пользователь не проводил оплату на сумму, превышающую суммы задолженности. Или при отгрузке м.б. запрет отгрузки товаров в минус. Но если фактичскую оплату УЖЕ УСПЕШНО ПРОВЕЛИ и отпечатали чек ККМ, вручили клиенту, а потом в задних числах что-то поменяли в отгрузке, или увели другими доками остатки для отгрузки в минус, то мешать автоматическому перепроведению действительно свершившейся ОПЛАТЫ часто нет никакого смысла (зачастую важно перепровести ВСЁ и потом разбираться точечно с 2-3 косячными доками, чем увидеть, что ночь прошла зря, и ничего не провелось вообще). Давать сигнал о косяках кому надо, писать в логи и т.д. - да, сколько угодно, но, скажем, останавливать с исключением восстановление последовательности на технически корректной свершившейся ВЫПЛАТЕ, т.к. не хватило денег в кассе из-за заведенного задним числом совсем другого дока выпдаты, это в ряде случаев чистый в(б)ред.

3. Добавление/включение новых проверок с течением времени (параметрически). Вчера можно было отгружать без какого-то допусловия, а сегодня поставили галочку в настройках "не давать проводить без заполнения реквизита Х",а потом и захотели автоматически перепровести 100500 старых документов с незаполненным "Х", и всё, приплыли(и начинается праздник быдлокода вида "Если Не РольДоступна("ПолныеПрава") Или Дата < '20200101' Тогда Отказ = Истина; Возврат; КонецЕсли;")

И мн. др.

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

(2) Самое прекрасное в этой истории - это то, что человек сыпящий умными словами и поучениями, приходит на форум задавать вопросы.

>>Некоторые ушлые юзеры обходят это, записывая док без проведения, а потом через контекстное меню формы списка проводят.

Убрать проведение из контекстного меню списка не предлагать?

(5) Во-первых ТС неохота. Во-вторых - не из списка, а как минимум из всех форм, где есть динамический список с основной таблицей - документом =)

Конфигурация на замочке? Изменение только через расширпение?

расширение

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

Нужно на уровне абстракции в виде обработки событий с объектами это рассматривать?
Ну ок. Тогда это точно нужно поверх конфигурации чего-то сажать свое.
Что угодно.
Одно время было цепляние к процедуре "Обработка проведения"
Другое - подписку на При записи или После записи - на разном уровне экстремизма.
Третье - расширением перехватить
На уровне тяжеловесов - доходит до пристегивания модулей с вкл словом Переопределяемый.
Причем, далее не столь важно, где именно будет происходить это самое переопределение: или в расширении или в новом модуле внутри основной типовой

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

(3) Безусловно, за "логику бизнес-данных" отвечает модуль объекта. А за что-то типа "проверь, можно ли этому пользователю создать док на этого клиента в эту фазу луны" вполне сойдет и модуль формы. Более того, в модуле документа эти проверки могут даже мешать, коль скоро документ уже создан, о чем написал в (2). Можно делать всё то же и в модуле объекта, но тогда вопрос переформулируется в "как в модуле объекта понять, что данное перепроведение интерактивное" и эти проверки не проводить. На него у меня есть не очень изящный ответ, но хотелось бы получить ответ на исходный вопрос.

(7)(8)(9)(10) Конфа не на замочке и это самописка (где из стандартного лишь БСП, БПО и БИП, поэтому каких-то скрытых механизмов, реализующих сабж, как в ERP, тут точно нет). И уточню, что суть вопроса не в том, как это сделать, а как это сделать не запотев, правя сотню доков вручную, а централизованно.

(9) > Одно время было цепляние к процедуре "Обработка проведения"
> Другое - подписку на При записи или После записи - на разном уровне экстремизма.
> Третье - расширением перехватить
Вот конкретика бы не помешала. В глобальной подписке ОбработкиПроведения или ПриЗаписи объекта состояние объекта, проводящегося из формы или из списка идентично. Про расширение не понял как оно тут поможет.

(4) [OFF]Как говорится, "Какой поп, таков и приход". Мне в Мисте наиболее прекрасно то, что определенная устоявшаяся часть аудитории, вместо того, чтобы на форуме давать ответы или в случае откровенно нубского/дурацкого вопроса пройти мимо, начинают опускать ТС, устраивать махач писюнами и иными способами тешить свое ЧСВ :) Почему это наиболее выражено именно на Мисте - вопрос философский :)[/OFF]

(11) Ну тем более. Зная заранее, как оно будет - все равно приходишь и задаешь свой Вопрос. Мазохиcт?

(12) ну тут только часть персонажей этим занимается, а не все подряд :-)

(11) // Про расширение не понял как оно тут поможет.
Так ведь и не было инфы, что это самописка, у которой нет своих специфических болезней старой УПП или новой ERP

Понятно, что при отсутствии замка есть произвольный выбор.
Подписка может заканчиваться присвоением Отказ = Истина. Но она отрабатывает уже в самом конце транзакции. Если документы легкие, то и все равно, когда от записи отказаться.
Но если документы достаточно тяжелые.
Можно в расширение забрать простые процедуры ПередЗаписью. Проверить там все условий и выставить Отказ. Лаконично. Сугубо на одно действие.
И продолжить Вызов или даже прервать вызов. Можно продолжить, потому что обычное наполнение процедуры - проверка на Отказ = Истина в самом ее начале.

Чем это может быть выгодно? Когда вдруг условие принятие решения на Отказ начнут усложняться, то они все равно останутся собраны просто в коде Расширения.
Понятно, что там же в коде расширения и Общий модуль и ... Ну много всего там можно накрутить :-)

Пои этом, на содержание основного поведения конфигурации это Расширение прямого влияния не окажет. При работе на полных правах и вовсе можно не устанавливать расширения. Ну вот как-то так.

(2)
>> я ж написал, что под "интерактивным" понимается проведение проведение с отработкой обработчиков Формы...
Вот именно, что это никак не соотносится с
>> платформой можно запретить интерактивное проведение, разрешив неинтерактивное, но не наоборот.

>> В пользу 100% оправданности подобного подхода в ряде ситуаций... 1... 2... 3...,
И ни одного слова по существу в пользу этого "подхода".

В чем проблема с отключением проверки в модуле объекта?
Ведь, внезапно, у всех давно прекрасно работает что-то типа:
Если ДополнительныеСвойства.Свойство("НеДелатьПроверку") Тогда

(13) Да, это всё прекрасно, даже поспорить не с чем). Но в случае с самопиской подписка никаких допвозможностей не предоставляет, и сама по себе поставленную задачу тоже не решает.

(14) >>В чем проблема с отключением проверки в модуле объекта? Ведь, внезапно, у всех давно прекрасно работает что-то типа:
Всё классно. Но вопрос не в том, как проверить допсвойство, а исходя из каких свойств/методов, предоставляемых платформой, определить значение для его установки. Не переворашивая миллион модулей форм (и чтобы на новые виды доков автоматом распространялось без лишних телодвижений тоже).

>>Если ДополнительныеСвойства.Свойство("НеДелатьПроверку") Тогда
Иными словами, проверить допсвойство проблемы нет, проблема в автоматическом установке некоего допсвойства при проведении из любой формы формы (или, наоборот, из любого списка с доступной командой "Провести").
В текущей редакции у меня реализация именно через допсвойство, в глобальной подписке на ДокументОбъект.ПередЗаписью устанавливается допсвойство по значению ДокументОбъект.Модифицированность(), а в глобальной подписке ДокументОбъект.ОбработкаПроведения потом считывается, и это в целом работает (т.к. при вызове из списка это свойство всегда Ложь, а при проведении из формы оно всегда Истина, даже если просто зашел в форму жамкнуть "Провести и закрыть"). Но это работает, скажем так, с особенностями и оговорками при программном создании доков, которую в некоторых обработках инициируют рядовые пользователи. И это также обходится, дописанием этих обработок. Короче, рабочий вариант есть, но он за собой тянет определенный шлейф костылей.

(12) "Не знаю, как сделать в принципе" <> "Хочу сделать с минимумом извращений"

Всё х...я, переделывай. Всё проверки вынести в модуль документа в 'перед записью', обрамив какой-нибудь, специальной ролью "могу перепроверить документы". Супер-пупер ночным обработкам выдавать эту роль. Покаяться, отразить опыт в резюме и больше так не делать.

Перепроверить - перепроводить

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