BiTel

Пытаюсь в событии "Изменение статуса договора" получить текущий статус:

Получаю пустой StatusContractList.

Пытаюсь так:

Получаю curStatus == null

Скрин статусов договора прилагается.
Статус пытаюсь сменить с 29.09.2010 (с открытой второй датой)
Как получить статус договора на момент начала действия нового статуса?

ContractStatusManager как раз отдаёт всё из этой таблички с промежутками. если там нет этого промежутка, то статуса никакого не будет. Если в какую-то дату никакой из отрезочков не попадает, то считается, что статус "активен".

_________________
I'm clever. I've got a computer.

status.getDate1() это у вас начало нового статуса, если до того был закрытый промежуток, то вернётся null потому что под этой датой статуса нет. или что у вас было до того как вы ставили этот ваш статус?

_________________
I'm clever. I've got a computer.

Ещё такая тонкость: в момент срабатывания события все статусы в БД уже изменены, потому рыться там на предмет того, что было ДО этого какбы бессмысленно. Опишите что именно вам надо и для чего именно...

_________________
I'm clever. I've got a computer.

В первом посте на скриншоте состояние статусов ДО изменения. Я меняю статус с 29.09.2010 и я ожидаю, что cstm.getStatus(cid, status.getDate1()) вернёт мне последний статус с открытой датой (29.09.2010- Активен)

Я хочу сделать так(псевдокод):

Нет, если вы ставите статус 29-го, то сначала алгоритм разберётся какие именно статусы и как надо перетереть (в вашем случае из БД удалится последний открытый промежуток), а потом вызовется событие и отработает скрипт, внутри которого 29-го уже будет пустота. А после события новый статус запишется уже на это новое пустое место.
Вот в данный момент так. Вот здесь смотрите алгоритм смены статуса в псевдокоде, если непонятно - спрашивайте: viewtopic.php?f=22&t=4544

_________________
I'm clever. I've got a computer.

Ну, у меня-то 4.6, так что меня это не особо касается. Однако, я понял, что на момент вызова события в БД уже затёрты статусы, которые должны быть перекрыты.
Из этого всего следует, что я НИКАК не могу узнать, какой был (должен был быть) статус договора ДО смены статуса? Может быть, стоит добавить в ContractStatusChangingEvent список всех статусов до затирания? Или хотя бы список тех статусов, которые пересекаются с периодом устанавливаемого статуса?

А если с логов вытягивать

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Ага, и самому высчитывать перекрытие всех статусов?

Не вдавался в суть вопроса, просто предложил

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Да, в 4.6 аналогично всё работает, за исключением варианта, когда включаются приоритеты.
Статус самого договора (!) на момент срабатывания этого события ещё не менялся. То есть можно запросить договор по cid и там getStatus покажет статус договора. Уже после этого события у договора меняется статус, если устанавливаемый промежуток затрагивает и сегодняшний день, тогда он ставится для договора статус + генерируется событие "изменился статус договора".

_________________
I'm clever. I've got a computer.

То есть разница между событиями "Изменение статуса договора" и "Статус договора изменен" только в статусе довора, а сама история статусов уже перетерта?

Так я узнаю только текущий статус. А если новый статус не включает сегодняшний день?
И как насчёт моего предложения передавать в событии старые статусы?

Может правильнее восстановить семантику события "изменение статуса"? Что бы в обработчике этого события можно было изменить статус и система корректировала статусы имеенно под измененный статус.

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

_________________
I'm clever. I've got a computer.

В общем виде это в TODO прописано, пока непонятно, как сделать, чтобы было красиво и всем понравилось. Вскоре переделывать придётся немного всю схему, тогда и реализуется так или иначе.

_________________
I'm clever. I've got a computer.

Чтобы событие вызывалось вообще до каких-либо сдвигов и затираний статусов? Возможно... но надо посмотреть зачем именно было сделано так, как сейчас.

_________________
I'm clever. I've got a computer.

Именно так.
И что бы перетирание статусов производилось уже по установленному (если конечно, обработчик события решит его изменить) статусу.
Например у нас, при ручном управлении АТС, смена абонотделом статуса на "отключен" подменяется обработчиком на "в отключении". А меняет статус договора на "отключен" уже обработчик выполнения CRM задачи и запросто на следующий день, а то и через несколько дней.

Вот и получается, что смотрит оператор на историю статусов и понять не может, почему она такая.

Ненене, о чём вы говорите? ЗАПИСЫВАЕТСЯ новый статус и история смены уже после события. Что в скрипте сменится, то и будет в БД для нового статуса.

_________________
I'm clever. I've got a computer.

Так вы же сами написали, что история статусов перетирается до вызова "изменение статуса".

Перетирается именно промежутки, привязанные к договору. Но не лог изменений и не новый пришедший статус.

_________________
I'm clever. I've got a computer.

Операторы и смотрят промежутки. Абоненсткая плата по ним начисляется. И вся повременка.

Я к тому, что как можно не понять почему именно такая история статусов? И причём тут событие до или после? Что изменится то?

_________________
I'm clever. I've got a computer.

Потому что статусы были поправлены по событию "отключен", а обработчик события "изменение статуса" поставил статус "активен". Фактически это означает, что договор вообще не переключался в статус "отключен", а история статусов этому не соответствует.

Может быть уже пора узнать причину, почему обработчик "изменение статуса" вызывается после того, как практически все изменения проведены, в то время как семантика "тонко намекает" на то, что пользователь может изменить статус внутри этого обработчика и получить реакцию системы именно на измененный статус?