Добрый день!
Может кто-то сталкивался с проблемой работы пользователей с процессами в разных часовых поясах?
(Не хочется изобретать велосипед)
Например, есть представительство на Дальнем востоке. Запускают процесс, доходит до шага, который должен выполниться у сотрудника в Москве. В параметр ExecuteDate шага записывается местное время пользователя, например, 14:00.
Приходит сотрудник, под которым должен выполниться шаг в Москве в 9 утра (в ДВ уже вечер и ...все ушли домой - тогда проблем нет :) ...на самом деле, время работы перекрывается), но шаг "висит" в ожидании, пока в Москве не наступит 14:00.
Вопрос: где формируется время выполнения шага при его создании? Каким образом сделать так, чтобы время выполнения шага не на клиенте бралось, а с сервера?
Естественно, формат поля в БД Террасофта не предполагает хранение часовых поясов... видимо при разработке функционала не учитывали, что в РФ немного больше, чем 1 часовой пояс...
Спасибо!
Нравится
В принципе, быстрый путь - понятен:
В скрипте в том месте, где происходит переназначение "Ответственного" за шаг (OwnerID) выполнить вычисление часового пояса текущего пользователя и часового пояса того, на кого переводим шаг, вычислить разницу и добавить к ExecuteDate.
Тут возникает еще одна проблема: как получать часовой пояс пользователей?
Для вычисления пояса текущего пользователя наверное есть какие-то функции для получения инфы из ОС. Но тогда вычислить часовой пояс юзера, на которого переводим процесс - не получится.
Значит нужно хранить его в БД (не уверен если в коробочной версии это делается и в какой таблице - tbl_Contact или tbl_AdminUnit... теоретически лучше tbl_Contact - мало ли, нужно запланировать звонок клиенту из Мск на Дальний Восток...)
Как заполнять значение часового пояса в таблице?
То, что оно будет меняться - нет сомнений. Например, пользователь залогинился в систему не на своем компе, а используя rdp... сбилось время на компе польззователя... он приехал в представительство в другом регионе и т.п. В общем, получил доступ к системе в которой ОС не в том часовом поясе, который записан в БД. Т.е. выполнять апдейт часового пояса при необходимости, нужно каждый раз при логине пользователя в систему... (Естественно, что случай, когда юзер меняет часовой пояс на компе, прямо во время сеанса работы, можно считать невероятным, и не наворачивать дополнительно функционал)
При таком подходе в общем то должно работать.
А чтобы уж наверняка, без всяких "исключений" - нужно конечно "поломать" еще функционал, который "забирает" свои шаги на выполнение: привести все к времени сервера - установку даты выполнения и сбор шагов для выполнения.
Добрый день.
Если у Вас установлены системные настройки UseServerTimeZone в true, а в ServerTimeZone установлен какой либо часовой пояс, то время в БД будет храниться именно в данном часовом поясе (т.е. для всей системы, для всех пользователей). Далее, в карточке контакта есть поле "Часовой пояс", каждый сотрудник может установить свой часовой пояс.
Добрый день.
Ок, но если что (появятся вопросы и пр.) - обращайтесь.
Добрый день!
С процессами конечно все вроде круто, но теперь есть другая проблема...
Пользователь из Екатеринбурга создает карточку контакта, заполняет дату выдачи паспорта 23.07.2013
Потом эту карточку открывает пользователь из Москвы... видит 22.07.2013
Распечатывает детализацию, и эта дата у него 22.07.2013 22:00 (разница между часовыми поясами 4 часа)
Что делать с этим? (Вариант переписывать обработчики всех форм и пр. не предлагать :))
Логика следующая:
если установлена сис. настройка "Использовать часовой пояс сервера"(UseServerTimeZone) - время хранится в БД на сервере в том часовом поясе, который указан в настройке ServerTimeZone.
Соответственно два варианта:
либо убрать настройку UseServerTimeZone, либо проверить, чтобы у всех контактов пользователей поля "Часовой пояс" были заполнены корректно.
Итак, вернемся к первоначальному вопросу:
Подскажите пожалуйста, как сделать НАСТРОЙКАМИ, так, чтобы пользователи из разных часовых поясов могли НОРМАЛЬНО работать в Террасофте?
А именно:
1) Нужно чтобы шаг, запущенный под пользователем в Хабаровске в 17 часов, выполнялся у пользователя в Москве в 10 часов а не в 17
2) Нужно чтобы если пользователь в Хабаровске проставляет значение даты в карточке 23.07.2013 оно же отображалось и у пользователя в Москве, а не 22.07.2013
3) Чтобы в журнале изменений запись о "Вставке" была раньше, чем запись об апдейтах и желательно, с достоверным таймстемпом :)
Манипуляции с галочкой привели к тому, что п.3 не выполняется... я еще не смотрел почему, но вставка выполняется с добавлением часового пояса (следовательно, с неправильным таймстемпом)
Апдейты вроде с правильным временем.
Спасибо!
Здравствуйте.
По поводу журнала изменений - это вы сейчас о колонке CreatedOn (Создано)? Т.к. данная колонка всегда заполняется временем сервера - проверьте это на уровне БД.
Далее, попробуйте вытащить в реестр именно её.
Бог с ней, с датой создания... но все-таки мне непонятно, почему происходит следующее:
Пользователь в Хабаровске в поле с типом Дата/Время, например, дата выдачи паспорта (Тип Даты/Времени такой же) указывает дату (руками, ни о каких там таймстемпах речи не идет):
01.03.2013
Пользователь в Москве открывает карточку и видит: 28.02.2013. В БД хранится значение 2013-02-28 13:00:00.000
И что делать то? Дата выдачи паспорта у человека 01.03.2013, независимо от того, где его выдали - в Хабаровске или в Калининграде...
В настройках выставлено:
У пользователя из Хабаровска UTC + 11
У пользователя в Москве UTC + 4
Часовой пояс сервера UTC + 4
Галочка Использовать зону сервера сброшена.
Все же считаю что вопрос с работой пользователей в нескольких зонах абсолютно не продуман:
Для бизнес-логики должен быть один механизм, для процессов и пр. - другой.
Добрый день.
Попробуйте либо отключить USe Server Time Zone, либо сбросить поле "Часовой пояс" для всех контактов пользователей.
Тогда время будет сохранятся в базу так, как указано руками.
Либо второй вариант, для таких полей, где применения логики изменения даты/времени в зависимости от часовых поясов не требуется, изменить тип поля на MaskDataControl, настроить маску в виде даты:
xx.xx.xxxx и использовать его, вместо контрола DateTimeDataControl.