В конфигурации запрещена модальность. Но перед записью нужно спросить пользователя и в зависимости от ответа или разрешить запись или запретить.

Как выкручиваться?

Своя кнопка записать

А если закрыл и записал

также своя кнопка "записать и закрыть"

не записал и закрыл. а закрыл, а тебя система спрашивает - записать изменения или нет

Добавляем реквизит на форму РежимЗакрытия. По умолчанию пусть будет Ложь
ПередЗакрытием смотрим, если Не РежимЗакрытия, тогда Отказ = Истина и спрашиваем. А если РежимЗакрытия = Истина, тогда закрываемся.

без своей кнопки никак

потому что в перед записью никак не определить, нажал юзер на записать или на записать и закрыть

Вопрос в обработчике формы ПередЗаписью

В обработчике события формы ПередЗаписью также может возникнуть потребность задать вопрос. Как и в предыдущем примере. Однако здесь вопрос так просто не решается. Отличие заключается в следующем.

В предыдущем примере, оказываясь в обработчике ПередЗакрытием, мы однозначно знали действие, которое должно быть выполнено. Это закрытие формы. Поэтому в обработке оповещения мы смело писали Закрыть().

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

Поэтому тут можно предложить три варианта, но все они, к сожалению, обладают недостатками:

    Изменить логику прикладного решения так, чтобы не было диалога с пользователем в этом обработчике. Это не всегда возможно;
    В обработке оповещения с помощью собственной блокирующей формы задавать пользователю развернутый вопрос, предполагающий точное описание дальнейших действий: Отказаться?, Только записать?, Записать и закрыть? Это может выглядеть не очень красиво, ведь пользователь уже нажал "Записать и закрыть", а его опять об этом спрашивают;
    Не использовать стандартные команды формы Записать, "Записать и закрыть". Вместо них создать собственные команды, в которых и выполнять необходимые алгоритмы. Создание собственных команд потребует дополнительных трудозатрат.

http://its.1c.ru/docs/v8nonmodal/

тут целая поэма на этот счет http://catalog.mista.ru/public/372973/

казалось бы простая задача , да?

меня прям умиляют защитники УФ, когда им говоришь, что в УФ куча головняков (на пустом месте). а они только и знают, что про прямые руки.

(0) 1. проверить наличие Параметра записи, напр, "Программно" Если параметр есть обходить задавание вопроса.
2. Если параметра нет, то задавать вопрос и уходить в отказ.
3. в процедуре обработки ответа если надо записать, то записать программно с установлением параметра записи "Программно"
Как-то так

(10) этот головняк имеет отношение не к УФ, а к браузеру Хром и подобным

(10) уф и то, что 1с называет "отказом от модальности" (который по факту не является отказом от модальности) и "асинхронностью" (которая не является асинхронностью) - разные вещи. к сожалению., за ту неделю, которую 1с пилила поддержку хрома, когда он запретил блокирование основного потока, они не смогли сделать по нормальному, а потом уже было "нельзя нарушать обратную совместимость", и, что еще хуже - признавать то, что можно было выпустить через две недели, но с автоматическим async/await тем самым признав ошибку

(12) если бы разработчики озаботились проблемами программистов, то добавили еще какой-нить обработчики. ПослеПослеЗаписи :)

(14) Чтобы 1с озаботилось проблемами программистов? не в этой жизни

(15) да ладно. чо уж поныть нельзя :)