Мой вариант:
Изменения в модуле обычного приложения (думаю с легкими модификациями подобный механизм можно использовать и в управляемом режиме, сам не думал: необходимости нет):
Перем глОтображеноПредупреждениеКонфРИБ Экспорт; ... // Проверка на обновление конфигурации РИБ для кассиров с выдачей предупреждения Функция ПроверкаНаОбновлениеКонфигурации() Экспорт Если КонфигурацияИзменена() И НЕ глОтображеноПредупреждениеКонфРИБ Тогда глОтображеноПредупреждениеКонфРИБ = Истина; Предупреждение( "ВНИМАНИЕ!!! ПРИНЯТО ИЗМЕНЕНИЕ КОНФИГУРАЦИИ." + Символы.ПС + Символы.ПС + "Закройте 1С на всех компьютерах и запустить программу с полными правами" + Символы.ПС + "После запуска необходимо согласиться на обновление конфигурации." + Символы.ПС + "В противном случае обмен с учетной системой офиса производиться не будет!", 30, "Обновление конфигурации" ); глОтображеноПредупреждениеКонфРИБ = Ложь; КонецЕсли; КонецФункции // Обновление конфигурации в узле Функция ОбновитьКонфигурациюБазыДанныхРИБ() Экспорт //Если конфигурация изменена, тогда нужно выполнить ее обновление... флОбновлять = Ложь; Если КонфигурацияИзменена() И НЕ глОтображеноПредупреждениеКонфРИБ Тогда глОтображеноПредупреждениеКонфРИБ = Истина; Если Вопрос( "ВНИМАНИЕ!!! ПРИНЯТО ИЗМЕНЕНИЕ КОНФИГУРАЦИИ. РЕКОМЕНДУЕТСЯ ИХ ПРИНЯТЬ." + Символы.ПС + Символы.ПС + "Закройте 1С на всех компьютерах торговой точки и нажмите ""ДА"" для обновления." + Символы.ПС + "Если вы хотите продолжать работу без обновления (не рекомендуется) нажмите ""НЕТ""." + Символы.ПС + "При отказе от немедленного обновления, обязательно сделайте его в ближайшее время."+ Символы.ПС + "В противном случае обмен с учетной системой офиса производиться не будет!"+ Символы.ПС + Символы.ПС + "ОБНОВИТЬ КОНФИГУРАЦИЮ?", РежимДиалогаВопрос.ДаНет, 60, КодВозвратаДиалога.Нет, "Обновление кнфигурации", КодВозвратаДиалога.Нет) = КодВозвратаДиалога.Да Тогда флОбновлять = Истина; КонецЕсли; Если НЕ флОбновлять Тогда Сообщить(Формат(ТекущаяДата(), "ДЛФ=В")+", отказ от обновления конфигурации"); глОтображеноПредупреждениеКонфРИБ = Ложь; Возврат Ложь; КонецЕсли; //Смотрим, чтобы в базе никого не сидело Попытка УстановитьМонопольныйРежим(Истина); Исключение Предупреждение("Ошибка захвата базы в монопольном режиме!" + Символы.ПС + ОписаниеОшибки()); глОтображеноПредупреждениеКонфРИБ = Ложь; Возврат Ложь; КонецПопытки; Предупреждение( "Работа системы будет завершена для обновления конфигурации" + Символы.ПС + Символы.ПС + "ВНИМАНИЕ!!!" + Символы.ПС + "После обновления конфигурации НЕОБХОДИМО ПОВТОРНО ПРОИЗВЕСТИ ОБМЕН!!!" + Символы.ПС + "В противном случае все изменения, полученные из центральной ИБ, обработаны не будут!",30, "Завершение обновления" ); глОтображеноПредупреждениеКонфРИБ = Ложь; ЗавершитьРаботуСистемы(Ложь, Истина, " CONFIG /UpdateDBCfg /Visible "); КонецЕсли; Возврат флОбновлять; КонецФункции // Процедура выполняется перед нначалом работы системы // Процедура ПриНачалеРаботыСистемы() // Проверка обновления конфы в РИБ глОтображеноПредупреждениеКонфРИБ = Ложь; Если ПланыОбмена.ГлавныйУзел() <> Неопределено И ОбщегоНазначения.ИнформационнаяБазаФайловая() Тогда Если РольДоступна(Метаданные.Роли.ПолныеПрава) Тогда Если ОбновитьКонфигурациюБазыДанныхРИБ() Тогда Возврат; КонецЕсли; // Проверка обновления в узле РИБ раз в 5 минут под полными правами ПодключитьОбработчикОжидания("ОбновитьКонфигурациюБазыДанныхРИБ", 300); Иначе // Проверка обновления в узле РИБ раз в 30 минут под кассирами ПодключитьОбработчикОжидания("ПроверкаНаОбновлениеКонфигурации", 1800); КонецЕсли; КонецЕсли; ...
Для стандартных конфигураций дополнительно можно вставить проверку изменения конфигурации после завершения интерактивного обмена в общем модуле «ПроцедурыОбменаДанными»:
// регистрирует что обмен был произведен и фиксирует информацию в протоколе Процедура ЗафиксироватьЗавершениеОбмена(СтруктураДанныхНастройкиОбмена, Знач СтрокаСообщенияОбОшибке = "", ... #Если Клиент Тогда Если СтруктураДанныхНастройкиОбмена.РучнойРежимЗапуска И СтруктураДанныхНастройкиОбмена.ДанныеНастройкиАвтообмена = Неопределено Тогда // для On Line обменов показываем отдельную форму завершения обмена ФормаПоказа = ПолучитьОбщуюФорму("ФормаРезультатOnLineОбмена"); ФормаПоказа.НаборЗаписейИстории = НаборЗаписейИстории; ФормаПоказа.Открыть(); Если ОбщегоНазначения.ИнформационнаяБазаФайловая() Тогда ОбновитьКонфигурациюБазыДанныхРИБ(); КонецЕсли; КонецЕсли; #КонецЕсли КонецПроцедуры
Я прекрасно понимаю что фразы предупреждений и вопросов не универсальны. Но целью публикации было предложить не тиражное решение, а технологию для облегчения жизни администраторам РИБ. Да, самый важный вопрос: ЧЕМ ЭТО ЛУЧШЕ ЧЕМ В ПЕРВОИСТОЧНИКЕ? Считаю такой вариант предпочтительнее чем в Автоматическое обновление конфигурации в узлах РИБ по следующим причинам:
- В первоисточнике строка запуска предполагает заранее известные имя и пароль пользователя для обновления, что накладывает жесткие ограничения на тиражирование решения на различные ИБ, в данном случае решение универсально: запуск конфигуратора происходит от имени пользователя в сеансе которого запущена процедура обновления и повторной регистрации не требуется
- Мелочь, но! Черное окно запуска скрипта не эстетично смотрится 🙂 в данном случае оно отсутствует
- Совсем мелочь, но! НУ НЕ НРАВИТСЯ МНЕ УСЛОВНЫЙ ПЕРЕХОД НА МЕТКУ!!! хоть автор и убеждает что дескать так надо… но глаз режет 🙂
Как пример работы процедуры, прилагаю обработку для обновления конфигурации ИБ в режиме enterprise
З.Ы. Мелкий совет: отключить надоедливое предупреждение при старте о том что конфигурация БД не соответствует сохраненной конфигурации можно при помощи параметра запуска /DisableStartupMessages. При использовании описанной в публикации технологии практический смысл такого предупреждения равен нулю!
(1) ВНИМАТЕЛЬНО!!! смотрите первоисточник практически по всем пунктам комментарии не по месту, и означают только то что автор коммента не разбирался в деталях предложенного fixin метода, хотел писать почему, но….. не вижу смысла вступать в полемику 🙂 давайте демократично: приведенный мной вариант имеет право на существование, но это не означает что первоисточник не имеет
1.
>> В первоисточнике строка запуска предполагает заранее известные имя и пароль пользователя для обновления, что
>> накладывает жесткие ограничения на тиражирование решения на различные ИБ
В первоисточнике, насколько я знаю, имя и пароль пользователя можно указать прямо на форме, а в скрипт они подставятся в момент его генерации.
>>, в данном случае решение универсально:
>> запуск конфигуратора происходит от имени пользователя в сеансе которого запущена процедура обновления и
>> повторной регистрации не требуется
Зато требуются права на запуск конфигуратора (ЗавершитьРаботуСистемы(Ложь, Истина, » CONFIG /UpdateDBCfg /Visible «). По моему мнению — это не очень правильный подход к администрированию ИБ, когда обычный пользователь имеет право доступа в конфигуратор.
2.
>> Мелочь, но! Черное окно запуска скрипта не эстетично смотрится 🙂
А кто мешает написать скрипт на другом языке (vbscript или jscript, например, и запускать его с помощью wscript)? Никаких чёрных окон!
«Черное окно запуска скрипта», между прочим, несёт пользователю информацию о стадиях процесса обновления и избавляет его от лишних действий в процессе обмена.
Кстати, альтернативное решение «черному окну» есть, например, в типовой БП 2.0 — обработка «ОбновлениеКонфигурации».
3.
>> Совсем мелочь, но! НУ НЕ НРАВИТСЯ МНЕ УСЛОВНЫЙ ПЕРЕХОД НА МЕТКУ!!! хоть автор и убеждает что дескать так надо… >> но глаз режет 🙂
Ну уж таков скриптовый язык bat-файлов. По мне — лишь бы работало и помогало автоматизировать рутинные процессы, а не возлагать их выполнение на пользователя.
4.
>> «После обновления конфигурации НЕОБХОДИМО ПОВТОРНО ПРОИЗВЕСТИ ОБМЕН!!!»
А в типовом варианте повторно производит обмен вышеуказанный скрипт с черным окном, а не пользователь.
Вопрос: а для чего же автор всё это писал? Для удобства работы пользователя или для себя, чтобы «глаз не резало»?
Автор комментария очень внимательно изучил предложенный вариант обмена с распределённой базой и, поскольку не один раз приходилось организовывать такой обмен, написал комментарий потому, что небольшая доработка типового функционала позволяет полностью автоматизировать процесс обмена. Велосипед уже изобрели, надо только его немного усовершенствовать! Я понимаю, конечно, что критика, а именно она больше всего присутствовала в моём комментарии, не всегда воспринимается авторами публикаций в позитивном плане. Ну что же, все варианты имеют право на существование, согласен.
А в полемику, действительно, вступать нет смысла… Я всего лишь хотел обратить внимание автора публикации на то, что задачи программиста, как правило, нацелены на автоматизацию бизнес-процессов организации и снижение трудозатрат пользователей, чего я не увидел в предложенном варианте.
P.S.
>> ВНИМАТЕЛЬНО!!! смотрите первоисточник практически по всем пунктам комментарии не по месту, и означают только то >> что автор коммента не разбирался в деталях предложенного fixin метода, хотел писать почему…
Это, как я полагаю, обида на критику? Ещё раз соглашусь: все варианты имеют право на существование. Автор придумал новый вариант — молодец! Но на «плюс» не тянет.
Попробовал ваш вариант, интересно и рабочий. Спасибо.
Но, это же нужно давать пользователям (в моем случаи кассирам пароль от админ. прав), а как раз то у нас специально и обрезаны права кассира, что бы он не видел некую информацию, а коль даем пароль от админ. учетки значит смысла нет в ограничениях.
И админы на всех РИБ не уникальны у меня ) капец ), что бы еще придумать можно было?
Есть ли возможность такая как получить логин и праоль админ. учетки в 1С и потом уже под этими данными входить для обновления?
нет, такой возможности нет
(4) myr4ik07, (1) premier
Во первых, вы оба не совсем внимательно, по моему, смотрели код. Там указано
Во вторых, кто мешает при запуске системы создавать служебного пользователя с фиксированным именем и паролем?
Показать
Ну а при завершении работы просто указывать в параметрах этого пользователя:
И все ваши проблемы с правами исчезли, так как даже кассир может запустить обновление системы, даже не подозревая о существовании служебного пользователя и пароля.