- СтатусЗадачаДата созданияПланируемая дата началаПланируемая дата выполненияДата началаДата выполненияПостановщикКто работает
- Завершена25 дек. 2018 г., 1:20
- Завершена
Задача: Убрать свойство User::sudo
Проект: @prisma-cms/user-module
Так как в процессоре добавляется по умолчанию разрешение всех действий для пользователей sudo,по умолчанию это свойство надо удалить в целях секурности. Если на каких проектах это поле понадобится, добавят сами в схему и будут контролировать обновление.25 дек. 2018 г., 0:28 - Завершена
Задача: Добавить разрешение на обновление для sudo-пользователей
Проект: @prisma-cms/prisma-processor
25 дек. 2018 г., 0:25 - Завершена
Задача: Добавить контексты UserLink и Avatar
Проект: @prisma-cms/front
24 дек. 2018 г., 21:40 - Завершена
Задача: Обновить @prisma-cms/server
Проект: @prisma-cms/module-boilerplate
24 дек. 2018 г., 0:42 - Завершена
Задача: Обновить log-module
Проект: @prisma-cms/module-boilerplate
24 дек. 2018 г., 0:41 - Завершена
Задача: Обновить mail-module
Проект: @prisma-cms/module-boilerplate
24 дек. 2018 г., 0:41 - Завершена
Задача: Обновить user-module
Проект: @prisma-cms/module-boilerplate
24 дек. 2018 г., 0:41 - Новая
Задача: Переписать методы сборки схемы
Проект: @prisma-cms/module-boilerplate
24 дек. 2018 г., 0:23 - Завершена24 дек. 2018 г., 0:23
- Выполняется
Задача: Переосмыслить сборку API-схемы
Проект: @prisma-cms/module-boilerplate
Предполагалось, что каждый модуль в отдельности сможет влиять на получаемую API-схему путем изменения готовой схемы на уровне метода getApiSchema().Но проблема в том, что сейчас в модуле прописана генерация API на основе получаемой базовой схемы призмы. Здесь используется относительный путь для файла схемы. То есть если на конечном проекте будет использоваться более одного призма-модуля, каждый из них будет в отдельности получать такую базовую схему и перетирать имеющуюся схему.Но если просто сделать путь абсолютный, то проблема недостаточно решается, потому что на конечном проекте без получения базовой призма-схемы не будут сгенерированы все основные API-методы. Вручную их переписывать тоже не круто.Придется делать в два этапа:1. Сейчас сделать все-таки относительные пути, чтобы на конечном проекте не перетирались схемы. На конечном проекте все равно придется получить базовую схему и донастроить все необходимые чистки схемы, но плюс в том, что можно будет сделать один базовый компонент для сборки и чистки частоиспользуемой схемы, а поверх уже лепить свое. Это будет довольно полезно для проектов, создаваемых на базе других крупных проектов, чтобы не приходилось вновь чистить все схемы.2. Все-таки переписать класс модуля так, чтобы методы компонентов суммировались и в итоге выполнялись общим потоком, а не как сейчас, что каждый модуль выполняется самостоятельно, и только суммируются результирующие схемы, полученные от каждого из этих модулей.24 дек. 2018 г., 0:13 - Новая23 дек. 2018 г., 10:58
