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

Материал из DOF
Перейти к: навигация, поиск
м (Уникальные наименования (коды): мелкие правки)
(Права)
 
(не показана 21 промежуточная версия 4 участников)
Строка 1: Строка 1:
 
=Принятые соглашения=
 
=Принятые соглашения=
 +
 +
В этом разделе описываются соглашения, относящиеся больше не к кодированию, а к реализации бизнес-логики: форматы полей для типовых данных, коды статусов и т.п.
 +
 
==Уникальные наименования==
 
==Уникальные наименования==
 
Коды программ, дисциплин и т.п. Должны включать в себя только цифры, русские и латинские буквы, дефис. В базу данных код сохраняется всегда только в нижнем регистре. Независимо от того, как был введен в форме.
 
Коды программ, дисциплин и т.п. Должны включать в себя только цифры, русские и латинские буквы, дефис. В базу данных код сохраняется всегда только в нижнем регистре. Независимо от того, как был введен в форме.
 +
=== Правила именования плагинов sync ===
 +
Все плагины sync, которые производят синхронизацию объектов с moodle должны называться как объект storage и иметь суффикс "tom". Пример: ''persons'''''tom'''.
  
 
==Коды и названия статусов.==
 
==Коды и названия статусов.==
используется в ages:
+
* future => предстоящий; - (от Алексея: нужно уточнить, для чего нужен этот статус)
* future => предстоящий;
+
* new => новый/заявка; - актуальный статус, он  уже существут для системы (не мусорный), но еще не перешел в активный статус.
* createstreams = созданы учебные потоки;
+
* deleted => удаленный; - мусорный статус, объекта "не существует" для системы, он не показывается даже в архиве. В него, например, могут быть переведены черновики. Обычные пользователи могут перевести в этот статус только объекты, которые еще не успели побывать в активном статусе.
* createsbc => сформированы ручные подписки;
+
* active => идет/действует; - активный статус
* createschedule => сформировано расписание;
+
* completed => завершен; - реальный конечный статус, аналогичный архивному, но обозначает успех в изучения дисциплины, программы.
* active => идет учебный процесс;
+
* failed => неуспешно завершен; - реальный конечный статус, аналогичный архивному, но обозначает неудачу в изучении дисциплины, программы по вине слушателя (двойка, отчислен).
* past => прошедший;
+
* canceled => отменен; - реальный конечный статус. Аналогичен архивному, но обозначает неудачу по объективным причинам (обучение отменено, студент переведен в середине семестра).
используется в programms:
+
* plan => запланирован; - для запланированных событий и объектов, в отличие от черновиков, их предварительное редактирование уже закончено и мы используем объекты для моделирования будущей ситуации. Пример: изменения расписания, которые вступят в силу с определенной даты.
* draft => черновик;
+
* archive => помещен в архив; - конечный статус, объект остается только для архива.
* available => доступна для заказа;
+
* suspend => приостановлен; - это не конечный статус, объект временно исключен из бизнес-процессов, но может быть возвращен.
* notavailable => не доступна для нового заказа;
+
* approved => подтвержден; - это не конечный статус, актуальный статус. Аналогичен запланированному, но для приказов, договоров, заявок.
* archive => архив;
+
* notapproved => не подтвержден; - это не конечный статус объекта, ожидающиего подтверждения.
используется в plans:
+
* returned => возвращен; - это не конечный, актуальный статус, обозначающий, что объект возвращен на доработку, но еще не потерявший шанса стать активным.
* active => действующая
+
* rejected => отклонён; - это конечный, реальный статус. Объект отклонён навсегда, вместо подтверждения, но должен остаться для архива рассмотренных заявок.
* excluded => временно исключена
+
* available => доступен; - вариация активного статуса обозначающая, что с объектом можно выполнять определенные действия (подписываться на программу).
* deleted => удаленная
+
* notavailable => недоступен; - вариация активного статуса, например, для программы: подписки на программу активны, но новых временно создать нельзя.
* information => справочная (не попадает в ведомости, нельзя поставить оценку, но видна преподавателю, он может от нее наследовать темы для своего курса)
+
* draft => черновик; - это не конечный статус, объект пока еще не существует для системы, но пользователь может сменить статус, когда объект будет "готов".
* additional => дополнительная оценка (тема не попадает в план, оценка считается дополнительной к родительской контрольной точке)
+
=== Мета-статусы ===
используется в cpasseds:
+
Объединяют в себе несколько статусов, и используются для того чтобы указать общее состояние объекта. Мета-статус - это виртуальный, иногда мнимый статус, которому соответствуют 1 или несколько реальных статусов
* plan => запланирован;
+
==== Активный объект (active) ====
* go => идет обучение;
+
Объект, участвующий в активной фазе бизнес-процесса (например, учебные процессы в статусе "идёт", договоры в статусе "оказание услуг").
* приостановлен => ;
+
 
* отменен => ;
+
Все активные объекты объекты являются, одновременно, актуальными и реальными, но не наоборот.
* complete => завершен;
+
==== Актуальный объект (actual) ====
* reoffset => перезачет из другой программы или учебного заведения;
+
Объект, жизненный цикл которого уже начат, но еще не завершен. Он включает в себя все активные объекты (с активными статусами), а так же некоторые не активные, но которые потенциально могут стать активными: запланированные, приостановленные, подтвержденные и т.п.
* repeating => пересдан в другой подписке;
+
 
используется в departments:
+
Все актуальные объекты являются, одновременно, реальными, но не наоборот.
* new => новый;
+
==== Реальный объект (real) ====
* active => действует;
+
Объект, существование которого система признает. Помимо актуальны объектов (которые являются активными или потенциально могут ими стать), реальные объекты включают в себя объекты, которые были активными, а теперь хранятся в архиве (но не включая удалённые, черновики и прочие, которых для системы как бы совсем нет).
* disband => расформирован;
+
 
используется в persons:
+
==== Мусорный объект (junk) ====
* новый =>
+
Объекты, которые хранятся в базе но никак не принимают участия в бизнес-процессе, даже в качестве архива: удалённые, отмененные, черновики.
* подтвержденный =>
+
 
* удаленный =>
+
В отличие от перевода в архивный статус, перевод в мусорный статус полностью вычеркивает объект из использования в системе.
используется в addresses:
+
В том числе: мусорные объекты не должны отображаться нигде в интерфейсе, кроме специально-отведенных мест ("просмотр удалённых" или "работа с черновиками"), кроме того, они никогда не должны использоваться при подсчете статистики или отображении истории.
* действительный =>
+
 
* неподтвержденный =>
+
== Права ==
* удаленный =>
+
 
Используется в programmssbc
+
=== Набор стандартных прав ===
* заявка
+
 
* подтверждена =>
+
* view - Право видеть полную информацию по объекту.
* действующая =>
+
* viewdesk - Право видеть интерфейсы объекта
* приостановлена =>
+
* create - Право создавать новый объект
* отмененная =>
+
* edit - Право редактировать существующий объект
* полностью остановлена =>
+
* use - Право ссылаться на объект в других объектах
* успешно-завершенная =>
+
 
используется в programmitems:
+
=== Общие положения ===
* действующий =>
+
* Основной набор прав доступа к объектам Деканата хранится в плагине STORAGE соответствующего объекта.
* приостановленный =>
+
* Право dof/view (из moodle) действует только на просмотр блока FDO и на просмотр главной страницы. На всех остальных страницах используется собственная система полномочий
* удаленный =>
+
* Если в блок dof заходит пользователь с полномочиями администратора (admin или danamanage) и для него нет персоны - то персона создается. Все данные берутся из профиля moodle, статус синхронизации (sync2moodle) равен 1.
используется в cstreams:
+
 
* запланирован
+
== Синхронизация ==
* идет
+
При создании плагина sync следует руководствоваться следующими правилами:
* приостановлен
+
* Функции синхронизации одного объекта FDO (например persons) с двумя разными системами нужно создать два плагина sync для каждой системы.
* отменен
+
* Плагины для разных систем именуются согласно [[Разработка:Принятые соглашения#Правила_именования_плагинов_sync | правилам именования плагинов sync ]].
* завершен
+
* Функции синхронизации следует группировать по принципу принадлежности к объекту FDO. Например функции создания персоны в moodle, получения количества входов на портал и получения информации о персоне из moodle должны находится в плагине sync/personstom
 +
== Комментарии ==
 +
В комментариях при описании параметров, содержащих id записей рекомендуется указывать из каких именно таблиц эти записи были взяты. При этом название таблицы можно писать одним словом, без префиксов.
 +
например:
 +
    $personid - id пользователя в таблице persons
 +
В данном случае имеется в виду таблица mdl_block_dof_s_persons

Текущая версия на 10:46, 29 мая 2017

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

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

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

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

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

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

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

  • future => предстоящий; - (от Алексея: нужно уточнить, для чего нужен этот статус)
  • new => новый/заявка; - актуальный статус, он уже существут для системы (не мусорный), но еще не перешел в активный статус.
  • deleted => удаленный; - мусорный статус, объекта "не существует" для системы, он не показывается даже в архиве. В него, например, могут быть переведены черновики. Обычные пользователи могут перевести в этот статус только объекты, которые еще не успели побывать в активном статусе.
  • active => идет/действует; - активный статус
  • completed => завершен; - реальный конечный статус, аналогичный архивному, но обозначает успех в изучения дисциплины, программы.
  • failed => неуспешно завершен; - реальный конечный статус, аналогичный архивному, но обозначает неудачу в изучении дисциплины, программы по вине слушателя (двойка, отчислен).
  • canceled => отменен; - реальный конечный статус. Аналогичен архивному, но обозначает неудачу по объективным причинам (обучение отменено, студент переведен в середине семестра).
  • plan => запланирован; - для запланированных событий и объектов, в отличие от черновиков, их предварительное редактирование уже закончено и мы используем объекты для моделирования будущей ситуации. Пример: изменения расписания, которые вступят в силу с определенной даты.
  • archive => помещен в архив; - конечный статус, объект остается только для архива.
  • suspend => приостановлен; - это не конечный статус, объект временно исключен из бизнес-процессов, но может быть возвращен.
  • approved => подтвержден; - это не конечный статус, актуальный статус. Аналогичен запланированному, но для приказов, договоров, заявок.
  • notapproved => не подтвержден; - это не конечный статус объекта, ожидающиего подтверждения.
  • returned => возвращен; - это не конечный, актуальный статус, обозначающий, что объект возвращен на доработку, но еще не потерявший шанса стать активным.
  • rejected => отклонён; - это конечный, реальный статус. Объект отклонён навсегда, вместо подтверждения, но должен остаться для архива рассмотренных заявок.
  • available => доступен; - вариация активного статуса обозначающая, что с объектом можно выполнять определенные действия (подписываться на программу).
  • notavailable => недоступен; - вариация активного статуса, например, для программы: подписки на программу активны, но новых временно создать нельзя.
  • draft => черновик; - это не конечный статус, объект пока еще не существует для системы, но пользователь может сменить статус, когда объект будет "готов".

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

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

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

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

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

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

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

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

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

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

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

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

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

Права

Набор стандартных прав

  • view - Право видеть полную информацию по объекту.
  • viewdesk - Право видеть интерфейсы объекта
  • create - Право создавать новый объект
  • edit - Право редактировать существующий объект
  • use - Право ссылаться на объект в других объектах

Общие положения

  • Основной набор прав доступа к объектам Деканата хранится в плагине STORAGE соответствующего объекта.
  • Право 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