Ситуация...
В последние 2-3 года всё отчётливее проявляется тенденция в типовых конфигурациях - чрезвычайно назойливо добиваться от пользователей перехода на самые свежие релизы.
Авторов типовых продуктов ещё можно понять, когда речь идёт о релизах самих конфигураций, т.к. это бывает необходимо для соответствия законодательству, органичного обмена, всяких интеграций и прочего. В этом случае напоминание или, жёстче, требование о переходе на новый релиз конфы достаточно обосновано.
Иначе обстоит дело с релизами платформы. В большинство типовых конфигураций так или иначе встраивается всевозможное вынуждение перейти на "самый-самый" свежий релиз, хотя в механизме этих конфигураций в 80-90% случаев не наблюдается ничего, что вынуждало бы это сделать. Кардинальной новизны мало, и её использование не спешит за её появлением, хотя прогресс налицо (если инструментарий XDTO писатели типовых освоили спустя 5 лет после его появления, то с JSON дело пошло живее). Но типовая конфа, в привычном и понятном пользователю виде, редко содержит использование чего-то такого, что появилось "буквально вчера" в платформе. Эта гонка имеет одно простое объяснение - фирма "1С" откровенно использует рядовых конечных пользователей для бета-тестирования новых, зачастую полусырых и кривых, платформ.
И это не голословное утверждение. Берём УТ 11.2.3.66, где при запуске настойчиво предлагается перейти на 8.3.7 не ниже совсем недавнего релиза 8.3.7.1790. Имеющие доступ сами могут ознакомиться со списками замеченных ошибок и представить эту прелесть в работе боевой крупной базы. Спасибо, хотя бы не ставится ультимативное требование о переходе, оставлена возможность работать "как раньше". По изучении отличий 11.2.3.66 от 11.2.2.119 навскидку не очень ясно, что же такого появилось, что не может работать, например, на 8.3.6, всё-таки более стабильной версии. Далее, работаем на 8.3.7 и получаем изрядное количество всевозможных косяков, ряд которых завершается позорными падениями конфигуратора, rmngr, консоли кластера и т.д. Как говорится, врать не буду, сам постоянно сталкиваюсь.
Политкорректности ради надо заметить, что это общемировая практика со времён выхода Windows 95, и более половины ведущих вендоров не считают её предосудительной. Но что, если клиент устал от объективно наблюдаемых багов и не рвётся обновляться дальше, а конфигурация активно напоминает об этом?
Есть ещё один момент. Предположим, ведётся разработка, и надо держать платформу именно определённого релиза (ну, допустим, там com-обмен, и минорно различающиеся comcntr ссорятся, или нет возможности обновить все клиентские места). При каждом запуске конфигурация требует обновления. Ключ запуска "РежимОтладки" не помогает, т.е. игнорируется. Через 10-15 минут можно либо озвереть, либо промахнуться и таки обновить случайно платформу.
Аналогично, в процессе работы могут всплывать всевозможные напоминания, оповещения и прочий мусор, совершенно не нужный пользователю по его бизнесу, но, увы, не всегда отключаемый настройками. Одно необходимое действие может сопровождаться 2-3 ненужными окнами, формами, вопросами, причём такими, неверный (неквалифицированный) ответ на которые может осложнить всем жизнь. При закрытии Предприятия тоже порой запрашиваются опасные вещи - навроде выполнения "тяжёлых" заданий. Был у меня случай, когда главбух случайно подтвердила "ускорение проведения документов", выйдя в середине дня ради перезагрузки своей рабочей станции, а потом 14 других бухгалтеров пару часов курили бамбук накануне сдачи НДС. Весело.
Что делать?
Способ есть. Называется "расширения". Никаких изменений в типовых конфигурациях, ни-ни. Только небольшое расширение, где унаследованы те формы (обработок или общие), которые вам и вашему клиенту мешают жить. В этих формах надлежит правильным образом установить отказы, обходы, принудительные вызовы и прочее. Разумеется, просто и тупо выставить "Отказ=Истина" почти всегда ошибка, т.к. многие такие формы работают в "живой" неразрывной цепочке оповещений, и её разрыв нарушит функциональность каких-то других механизмов, инициализиремых позже вызова этой формы. Важно именно изучить ситуацию и поставить правильные "заглушки".
В качестве иллюстрации к концепции прилагаю расширение для вышеупомянутой УТ 11.2.3.66
Замечу, что ещё более "красивым" вариантом является тонкий тюнинг подписок, оповещалок и всяких "дел", на которые ориентируется конфигурация и средствами которой зачастую запрашивается некое обновление, и в вашей расширенной форме вы можете "гасить", удалять эти зарегистрированнные, но ненужные вам действия.
От рекламы при запуске так тоже можно избавиться.
Надеюсь, этот подход поможет более гибко управлять работой конфигураций, переходя на новые релизы, более стабильные релизы тогда, когда это нужно вам, и не тратя нервы на множество назойливых ненужных окошек.
Красиво и качественно эта идея уже воплощена ранее: //infostart.ru/public/371628/
