==== Как от Open перейти к собственному сервису? ====

Проект Sharix Open - идет в основу каждого нового разворачиваемого сервиса, который предполагается, что будет функционировать на основе платформы ShariX.

Тестирование последней версии ShariX Open происходит на виртуальной машине Test (dev-сервер) - https://testopen.sharix.org. Доступ к ней и к процессу тестирования могут получить разработчики команды ShariX Open и практиканты компании ООО "ШЭРИКС".

Разворачивание сервиса выглядит как клонирование репозитория в отдельную виртуальную машину (или набор виртуальных машин - решение о конкретной инфраструктуре принимают создатели) сервиса.

Каждый сервис должен разворачиваться по аналогии с Open методом первоначального клонирования open-webapp-base (AGPL), но не-AGPL-репозитории берутся из группы репозиториев сервиса (в рамках компании ООО "ШЭРИКС" - на собственном git в организации по названию сервиса).

В конфигурации внутри webapp-base прописываются пути для клонирования для конкретного сервиса, конфигурация создается на основе черновика, в котором прописаны пути для клонирования Open. Первоначально группа репозиториев по названию сервиса создается методом полного клонирования Open, а затем форком (замена имен и файлов в некоторых репозиториях). Далее обновление виртуальной машины происходит методом обновления группы репозиториев сервиса.

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

В нормальном (стандартном) сценарии развертывания сервиса - эти репозитория остаются от Open как есть и даже не требуется переименование. Идеально, если в скрипте они будут в целом устанавливаться из последней версии Open, если это точно не будет ломать в текущем состоянии виртуалки (правильно вести разработку так, чтобы не ломало).

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

В частности, *-backend (AGPL) содержит модели и шаблоны обработчиков событий. Его видоизменять не нужно для функционирования нового сервиса.

Так как у каждого сервиса свои обработчики - они копируются из open-backend в репозиторий *-webservice-running с соответствующим переименованием. Внутри разворачиваемого проекта оно должно в итоге оказаться там же. Вопрос лишь в том, в репозитории с каким смыслом и лицензией он выкладывается в гит.

Таким образом, в каждом сервисе, создаваемом на основе Open - остаются обработчики от Open - как пример, и есть свои обработчики сервиса, в webservice-running.
Также в репозитория webservice-running (GPL) добавляется вся специфика сервиса, какая только может понадобиться ему - backend.
Содержимое иных репозиториев с точки зрения разворачивания сервиса и ведения разработки:
  * В webadmin (GPL) - внешний вид админ-панели.
  * Landing (GPL) - посадочная страница сервиса
  * Design-template (GPL) - шаблон дизайна
  * User-model (AGPL) - базовая модель пользователя
  * Tickets (AGPL) - интерфейс отображения заявок и управления ими
  * Payments (GPL) - модуль для базовой обработки платежей с помощью платформы ShariX

==== ЧЕРНОВИК/старое Как написать новый вызов API для ShariX Open ====

Ниже представлены основные тезисы в виде заметок на ходу.

  * Репозиторий sharix-open-backend
  * Папка metaservicesynced
  * Берем urls.py и по аналогии описываете или группу ссылок (router) - или отдельную (urlpatterns)
  * Далее надо пойти в apiviews и создать файл по аналогии с имеющимися с MVS, добавленной действием ранее в urls.py
  * queryset - таблица, к которой обращаемся
  * SerializerClass - далее надо будет создать такой файл в папке serializer
  * permission_classes - для ограничения доступа
  * потом в __init__.py класс импортировать (по сути указать связь ссылки и MVS), чтобы он заработал (в той же папке, где view создавали)
  * далее идем в папку serializer и создаем там файл с классом, о котором говорилось выше
  * и в __init__.py по аналогии для serializer тоже
  * Обработка происходит в serializer
  * После дописывания перезапустить сервер


Чтобы искать по полям, отличным от id - надо в view вставить:

lookup_field = "status" (вместо status - nо поле, по которому получать ответ)