Package ru.bitel.bgbilling.kernel.event.events

# Class ContractSetStatusLogicEvent

java.lang.Object
ru.bitel.bgbilling.kernel.base.server.logger.BGLogger
ru.bitel.bgbilling.kernel.event.common.Event
ru.bitel.bgbilling.kernel.event.common.QueueEvent
ru.bitel.bgbilling.kernel.event.common.LocalEvent
ru.bitel.bgbilling.kernel.event.events.ContractSetStatusLogicEvent

All Implemented Interfaces:
  `Serializable`, `ErrorReturnableEvent`

public class ContractSetStatusLogicEvent extends ru.bitel.bgbilling.kernel.event.common.LocalEvent
Синхронное событие - задание логики перетирания статусов.
Вызывается, когда в конфиге включено задание логики смены/перетирания статуса скриптом.
Унаследован от `LocalEvent`

See Also:
  - Serialized Form

- ## Field Summary

  ### Fields inherited from class ru.bitel.bgbilling.kernel.event.common.Event

  `CONTRACT_GLOBAL, NO_MODULE, NO_PLUGIN`

- ## Constructor Summary

  Constructors
  Constructor
  Description
  `ContractSetStatusLogicEvent(int userId, ContractStatus status1, ContractStatus status2, ContractStatus originalStatus)`
  Конструктор события.

- ## Method Summary

  Modifier and Type
  Method
  Description
  `ContractStatus`
  `getOriginalStatus()`
  Оригинальный статус, который пришёл в changeStatus изначально.
  Может отличаться от status2, если тот уже был изменён на предыдущих шагах итд.
  `ContractStatus`
  `getStatus1()`
  Статус, который лежит в БД уже, "старый".
  `ContractStatus`
  `getStatus2()`
  Статус, который мы пытаемся установить, "новый".
  `boolean`
  `isProcessed()`
  `void`
  `setProcessed(boolean isProcessed)`
  Если скрипт выполнил задуманную логику, то надо установить в скрипте этот флаг.
  Иначе после скрипта будет работать штатная логика!

  ### Methods inherited from class ru.bitel.bgbilling.kernel.event.common.LocalEvent

  `getError, setError`

  ### Methods inherited from class ru.bitel.bgbilling.kernel.event.common.Event

  `getContractId, getDestination, getGenerateTime, getMessageID, getModuleId, getPluginId, getSource, getSuperContractId, getTime, getTimestamp, getTypeId, getUserId, isLogFunctionProcess, prepareMessage, serializeAsObject, setLogFunctionProcess, setMessageID, setSource, toString, toString`

  ### Methods inherited from class ru.bitel.bgbilling.kernel.base.server.logger.BGLogger

  `error, error, error, getLogger, logError, logError`

  ### Methods inherited from class java.lang.Object

  `clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait`

- ## Constructor Details

  - ### ContractSetStatusLogicEvent

    public ContractSetStatusLogicEvent(int userId, ContractStatus status1, ContractStatus status2, ContractStatus originalStatus)
    Конструктор события.
    Parameters:
      `userId` - - id пользователя, сгенерировавшего событие
      `status1` - - статус, который находится в БД, "старый", до него сейчас дошло дело при обработке цепочки смен статусов уже лежащих у нас.
      `status2` - - статус, который кладётся сейчас, "новый", он уже может отличаться от оригинального originalStatus предыдущими вызовами этого же события, то есть быть "покромсаным".
      `originalStatus` - - оригинальный статус, который кладётся сейчас, этот тот статус который изначально пришёл в метод смены статуса, тот который мы стали ставить в клиенте, например.

- ## Method Details

  - ### setProcessed

    public void setProcessed(boolean isProcessed)
    Если скрипт выполнил задуманную логику, то надо установить в скрипте этот флаг.
    Иначе после скрипта будет работать штатная логика!
    Это почти наверняка вызовет странные эффекты. Имеется ввиду исключительно работа по решению вопроса конкретной пары статусов + обновление лежащего в БД итд.
    Parameters:
      `isProcessed` - - флаг обработки события
      true, если обработано

  - ### getStatus1

    public ContractStatus getStatus1()
    Статус, который лежит в БД уже, "старый". Его надо подрезать каким-либо образом. Или что-то типа того.
    Этот объект бесполезно менять. Надо сразу обновить его в БД. Если он разбился на несколько частей - аналогично.
    Если перетёрся - удалить из БД. Итд. Смотреть пример штатной логики, реализованной скриптом в wiki.
    Returns:
      status1 - статус договора

  - ### getStatus2

    public ContractStatus getStatus2()
    Статус, который мы пытаемся установить, "новый". Изначально, в штатной логике нет возможности ему измениться, то есть он всегда и всех перетирает.
    Но в скрипте можно делать хоть что. Например, отколоть кусочки от него "неперетираемым" итд. Этот объект можно в скрипте изменить.
    Например, этот статус можно сократить. Или изменить, тогда на выходе из скрипта тот статус будет уже новым (и в следующий раз придёт для следующего кусочка уже изменённый). И тогда он уже может отличаться от originalStatus, который изначально пришёл в метод смены статуса.
    Returns:
      status2 - статус договора

  - ### isProcessed

    public boolean isProcessed()

  - ### getOriginalStatus

    public ContractStatus getOriginalStatus()
    Оригинальный статус, который пришёл в changeStatus изначально.
    Может отличаться от status2, если тот уже был изменён на предыдущих шагах итд.
    Returns:
      originalStatus - статус договора