Разработка:Принятые соглашения

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

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

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

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

Правила именования плагинов 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