Статус система
Версии
Видео презентации
Статус системата позволява на потребителя да конфигурира сам статуси на обектите и да дефинира зависимости между тях, имплементирайки по този начин съвсем основна бизнес логика в приложението си. Например, ако потребителят настройва статуси на обекта Поръчка, то може да иска да укаже, че една поръчка не може да има статус Приключила, ако е Анулирана.

Статусите са организирани в групи. Групата има функцията да укаже, че по едно и също време, един запис може да има само един статус от тази група. Към един обект могат да бъдат дефинирани повече от една групи статуси, позволявайки по този начин да има повече от един статус. Например една поръчка може да има от производствена гледна точка статус Приключила, а от финансов – Неплатена. Така могат да се следят различни процеси в приложението.

ОБЕКТИ
Настройките на статусите се съхраняват в няколко бизнес обекта:
  • AOStatusGroup – дефинира групите
  • AOStatus – основния обект за статусите
  • AOStatusAdditionalTask – дефинира релация между статус и обекта AdditionalTask
  • AdditionalTask – това са списък с допълнителни задачи, които могат да се извършват при промяна на статус. Специфични са за приложението.
  • AOStatusApplicationObjectUse – указва кой обект ползва статусите на друг. Например даден обект, може да има релация едно към едно с обекта, който има статуси и можем да разрешим на потребителя да сменя статуси и от този обект.
  • AOStatusCustomCheck – тази таблица съхранява какви допълнителни проверки са регистрирани от обектите в системата. Това са проверки, които се извършват при промяна на статус, но са логически зависими и не могат да бъдат описани с параметри. Разработчикът създава метод с определена сигнатура в класа си и го регистрира в тази таблица. Методът се извиква при смяна на съответния статус и може да забрани промяната и да изведе съобщение за грешка.
  • AOStatusCustomSchedule – указва се насрочената смяна на статусите
  • AOStatusDependency – указва зависимостите от други статуси
  • AOStatusRelatedObjectDependency – указва зависимостите от други статуси
  • AOStatusUserDelay – указва отложена смяна по потребители
  • AOStatusUsersGroupAccessRight – указва права за промяна на статус по групи потребители
  • AOStatusUsersGroupEditingRight – указва права за редактиране на запис в определен статус по групи потребители.
ДЕФИНИЦИЯ НА СТАТУС
Един статус се дефинира с кода, името, групата си и за кой обект се отнася. Допълнително се указва дали е статус по подразбиране, дали е видим и дали разрешава overwriting. Също може да се указва дали статуса изисква потребителски интерфейс при промяна или не.

ОГРАНИЧЕНИЯ И ПРОВЕРКИ
За един статус могат да бъдат дефинирани ограничения от други статуси или от статуси на свързани обекти (например една поръчка не може да бъде платена, ако всичките й падежи не са платени). За всяко ограничение от друг статус (или такъв на свързан обект) може да се въведе следните ограничения:
  • Да се е случвал
  • Да не се е случвал
  • Да е текущ
  • Да не е текущ
Допълнително могат да се укажат проверки, дефинирани при проектирането на системата и написани специално за обекта.

ПРАВА НА ДОСТЪП
Дефинират се два типа права на достъп, и двете са на ниво групи потребители:
  • Право за смяна на статус – указва се коя група потребители може да сменя дадения статус
  • Право за редакция на запис в определен статус – указва се коя група потребители може да редактира запис в определен статус (например само технолози могат да редактират поръчка в статус „В производство”). Този статус може да бъде допълнително ограничен с условие за това потребител от коя група е сменил статуса:
    • Винаги
    • Само ако потребител от същата група го е променил
    • Освен ако потребител от същата група го е променил
    • Ако потребител от изброени групи го е променил
    • Освен ако потребител от изброените групи го е променил
ПЕРСОНАЛНИ СТАТУСИ
Статусите могат да се дефинират като персонални. Това означава, че при промяна на статус трябва да се укаже потребител, на когото се „изпраща” записа. Оттам нататък само този потребител може да го редактира.

ОТЛОЖЕНА ПРОМЯНА НА СТАТУС
Това е вид промяна, която забавя смяната на статуса с определено количество време, дефинирано по потребител.

НАСРОЧЕНА ПРОМЯНА НА СТАТУС
Възможно е да се дефинира, че дадено количество време след промяната на указан статус, следва друг статус. Например, ако контактите на някой клиент има нужда да се потвърждават през 2 месеца, може да се насрочи статус „За потвърждение”, който да се сменя 2 месеца след статус „Потвърден”.

ИСТОРИЯ НА ПРОМЯНАТА
При дефиниране на статус към даден обект, Елемент автоматично създава свързан обект „История на статуси”, който се записва в отделна таблица и пише кой потребител на коя дата кой статус от коя група е променил.

ТЕХНИЧЕСКИ ДЕТАЙЛИ
При добавяне на статус към обект за първи път, към този обект се регистрира разширението AOStatus, което добавя в списъка колони за всяка група, а във формата добавя информация за всяка група статуси – кой е текущ, кога е променен и кой потребител го е променил. Като действия на обекта се добавят всички видими статуси. Също така се създава обект "object name" StatusHistory, който става неконтекстно свързан на обекта. Освен това, обектът AOStatus се регистрира за събитието AddComplete на обекта. При възникване на това събитие се слага статусът по подразбиране.

Преди всяка промяна на статус се проверяват правата на текущо логнатия потребител. След това се проверява дали обекта не предоставя някакви допълнителни проверки и след това се проверяват всички проверки дали са изпълнени. Ако статусът не изисква потребителски интерфейс и проверките са удовлетворени, статусът се променя. При останалите случаи се показва прозорец на потребителя с резултатите от проверките и, ако те са удовлетворени, има възможност за добавяне на бележка, която се записва в StatusHistory. При промяна на статус на повече от един запис наведнъж, проверките се тестват за всеки запис поотделно.

При показване на формата има възможност за предоставяне на персонализиран интерфейс от обекта, който задължително наследява формата на StatusHistory за промяна. По този начин обекта може да събере допълнителна информация при промяна на статус.

При успешна промяна на статус възниква събитието StatusChange, което може да бъде следено от всички обекти в приложението.
 
EnglishКарта на сайта
Уеб сайт, SEO от Калипърс

Ladger