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

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

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

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

==Коды и названия статусов.==
* 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 | правилам именования плагинов sync ]].
* Функции синхронизации следует группировать по принципу принадлежности к объекту FDO. Например функции создания персоны в moodle, получения количества входов на портал и получения информации о персоне из moodle должны находится в плагине sync/personstom
== Комментарии ==
В комментариях при описании параметров, содержащих id записей рекомендуется указывать из каких именно таблиц эти записи были взяты. При этом название таблицы можно писать одним словом, без префиксов.
например: 
    $personid - id пользователя в таблице persons
В данном случае имеется в виду таблица mdl_block_dof_s_persons