Разработка:Принятые соглашения — различия между версиями

Материал из DOF
Перейти к: навигация, поиск
м (Мета-статусы)
(пояснения по статусам)
Строка 27: Строка 27:
 
==== Активный объект (active) ====
 
==== Активный объект (active) ====
 
Объект, участвующий в активной фазе бизнес-процесса (например, учебные процессы в статусе "идёт", договоры в статусе "оказание услуг").
 
Объект, участвующий в активной фазе бизнес-процесса (например, учебные процессы в статусе "идёт", договоры в статусе "оказание услуг").
 +
 +
Все активные объекты объекты являются, одновременно, актуальными и реальными, но не наоборот.
 
==== Актуальный объект (actual) ====
 
==== Актуальный объект (actual) ====
объект, жизненный цикл которого уже начат, но еще не завершен. Он включает в себя активные, запланированные, приостановленные и т.п.
+
Объект, жизненный цикл которого уже начат, но еще не завершен. Он включает в себя все активные объекты (с активными статусами), а так же некоторые не активные, но которые потенциально могут стать активными: запланированные, приостановленные и т.п.
 +
 
 +
Все актуальные объекты являются, одновременно, реальными, но не наоборот.  
 
==== Реальный объект (real) ====
 
==== Реальный объект (real) ====
 
Объект, существование которого система признает. То есть, это используемые объекты, плюс архивные (но не включая удалённые, черновики, отмененные и прочие, которых для системы как бы совсем нет).
 
Объект, существование которого система признает. То есть, это используемые объекты, плюс архивные (но не включая удалённые, черновики, отмененные и прочие, которых для системы как бы совсем нет).
 +
 +
Помимо актуальны объектов (которые являются активными или потенциально могут ими стать), реальные объекты включают в себя объекты, которые были активными, а теперь хранятся в архиве.
 
==== Мусорный объект (junk) ====
 
==== Мусорный объект (junk) ====
 
Объекты, которые хранятся в базе но никак не принимают участия в бизнес-процессе, даже в качестве архива: удалённые, отмененные, черновики.
 
Объекты, которые хранятся в базе но никак не принимают участия в бизнес-процессе, даже в качестве архива: удалённые, отмененные, черновики.
 +
 +
В отличие от перевода в архивный статус, перевод в мусорный статус полностью вычеркивает объект из использования в системе.
 +
В том числе: мусорные объекты не должны отображаться нигде в интерфейсе, кроме специально-отведенных мест ("просмотр удалённых" или "работа с черновиками"), кроме того, они никогда не должны использоваться при подсчете статистики или отображении истории.
  
 
== Права ==
 
== Права ==

Версия 20:08, 29 марта 2013

Принятые соглашения

В этом разделе описываются соглашения, относящиеся больше не к кодированию, а к реализации бизнес-логики: форматы полей для типовых данных, коды статусов и т.п.

Уникальные наименования

Коды программ, дисциплин и т.п. Должны включать в себя только цифры, русские и латинские буквы, дефис. В базу данных код сохраняется всегда только в нижнем регистре. Независимо от того, как был введен в форме.

Правила именования плагинов sync

Все плагины sync, которые производят синхронизацию объектов с moodle должны называться как объект storage и иметь суффикс "tom". Пример: personstom.

Коды и названия статусов.

  • future => предстоящий;
  • new => новый/заявка;
  • deleted => удаленный;
  • active => идет/действует;
  • completed => завершен;
  • canceled => отменен;
  • plan => запланирован;
  • archive => помещен в архив;
  • suspend => приостановлен;
  • approved => подтвержден;
  • notapproved => не подтвержден;
  • available => доступен;
  • notavailable => недоступен;
  • draft => черновик;

Мета-статусы

Объединяют в себе несколько статусов, и используются для того чтобы указать общее состояние объекта. Мета-статус - это виртуальный, иногда мнимый статус, которому соответствуют 1 или несколько реальных статусов

Активный объект (active)

Объект, участвующий в активной фазе бизнес-процесса (например, учебные процессы в статусе "идёт", договоры в статусе "оказание услуг").

Все активные объекты объекты являются, одновременно, актуальными и реальными, но не наоборот.

Актуальный объект (actual)

Объект, жизненный цикл которого уже начат, но еще не завершен. Он включает в себя все активные объекты (с активными статусами), а так же некоторые не активные, но которые потенциально могут стать активными: запланированные, приостановленные и т.п.

Все актуальные объекты являются, одновременно, реальными, но не наоборот.

Реальный объект (real)

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

Помимо актуальны объектов (которые являются активными или потенциально могут ими стать), реальные объекты включают в себя объекты, которые были активными, а теперь хранятся в архиве.

Мусорный объект (junk)

Объекты, которые хранятся в базе но никак не принимают участия в бизнес-процессе, даже в качестве архива: удалённые, отмененные, черновики.

В отличие от перевода в архивный статус, перевод в мусорный статус полностью вычеркивает объект из использования в системе. В том числе: мусорные объекты не должны отображаться нигде в интерфейсе, кроме специально-отведенных мест ("просмотр удалённых" или "работа с черновиками"), кроме того, они никогда не должны использоваться при подсчете статистики или отображении истории.

Права

  • Право dof/view (из moodle) действует только на просмотр блока FDO и на просмотр главной страницы. На всех остальных страницах используется собственная система полномочий
  • Если в блок dof заходит пользователь с полномочиями администратора (admin или danamanage) и для него нет персоны - то персона создается. Все данные берутся из профиля moodle, статус синхронизации (sync2moodle) равен 1.

Синхронизация

При создании плагина sync следует руководствоваться следующими правилами:

  • Функции синхронизации одного объекта FDO (например persons) с двумя разными системами нужно создать два плагина sync для каждой системы.
  • Плагины для разных систем именуются согласно правилам именования плагинов sync .
  • Функции синхронизации следует группировать по принципу принадлежности к объекту FDO. Например функции создания персоны в moodle, получения количества входов на портал и получения информации о персоне из moodle должны находится в плагине sync/personstom

Комментарии

В комментариях при описании параметров, содержащих id записей рекомендуется указывать из каких именно таблиц эти записи были взяты. При этом название таблицы можно писать одним словом, без префиксов. например:

   $personid - id пользователя в таблице persons

В данном случае имеется в виду таблица mdl_block_dof_s_persons