Problem

Before developing we should design what features we are going to include in our first 0.1 release.

Solution

For that, we design a list of features as MVP Requirements. With them, we will design all the issues and tasks for each development step. In this thread, we are going to discuss it and finally write it in the documentation.

First of all, we need to think about what artists really need and how we can provide them the most significant features.

Keep in mind that this is also going to be our development tool

Problem

Before starting development we should carefully analyze our project & find out how we can make it a perfect solution for the problem we are trying to solve.

Some initial thought about it can be found in README.md on title page of repository.

Plan

• Analyze use cases:
  • Use case for professional teams that develop visual content
    We got managers who are not artists, but they state problems that artists should solve & check their results, ask them to make some changes, etc. Also we have artists that wish to have well structured project folder on local machine & easy VCS that allows them quickly switch between different versions of project. It's also important to provide extensible privacy settings (as some arts should be closed & accessible only for some users & develop user roles in projects).
    So there we should design UX for managers & artists
  • Use case for education studios & projects (for managing groups of students)
    There we have teachers that are professional artists, that want to check works of their students & state tasks for them & students that send solutions for tasks from teachers & teachers comment them & explain their mistakes
  • Use case for individual artists (freelance mainly)
    This is really optional use case which suggests that artists can store their personal/freelance works & easily structure them for better & quicker results
• Design UI for web client that is mainly oriented on managers, but supports some feature for artists (@SixDevelop @mohorka)
• Design UI for desktop client (@SixDevelop @mohorka)
• Design domain model (which should map on our db structure to utilize all our needs in storing information & managing user roles) (@AndyS1mpson)

Notes

Last 3 tasks should be done simultaneously, first on in group

When developing UI I suggest finding references in other services & it will be good if someone will study some UX/UI course if there is time.

Our UX design (as text & schemes) should be written in Wiki section of repository, database scheme as a result of domain analize should be saved in documentation folder in our repository

Developer discussion of this issue should be done in gitter dev room

Проблема

Архитектурно контроллеры должны содержать только логику связанную с обработкой запроса и отправкой ответа, непосредственно логика получения и обработки данных должна реализовываться соответствующим сервисом.

Решение

Для уже имеющихся и будущих контроллеров требуется писать сервисы и помещать их в папку Service проекта ArtArea.Web. Так же нужно не забывать прописывать DI (в классе Startup нужно в методе ConfigureServices для каждого сервиса прописывать services.AddTrancient<ClassService>();.

Для сервиса контроллера аутентификации (AuthController, AuthService) нужно:

• получение токена по username JwtSecurityToken GetToken(string username)

• добавление нового пользователя - выкидывает исключение, если нельзя добавить пользователя

• проверка логина пользователя по логину и паролю

• проверка запроса на залогиненного пользователя - если пользователь залогинен, то в заголовке запроса придет jwt токен

Для сервиса к UserController:

• проверка на существование пользователя

• получение данных пользователя (сырой модели)

• получение всех проектов пользователя, учитывая залогиненного пользователя

Для сервиса к ProjectController:

• проверка существования проекта

• получение всех досок проекта

• получение данных проекта (сырой модели)

Заметки

Полезные ссылки по токенам и авторизации

• https://www.jerriepelser.com/blog/aspnetcore-jwt-saving-bearer-token-as-claim/

Ветка: feature/controller-services-integration

Problem caused feature request

Web Client navigation description

Requested Solution

Pages:

Alternatives

Some pages can change, but we will know about that only during hackathon

Additional Info

Possibly we can add more editing options and search engine across other users and repositories
@mohorka, it is worth using this file as a guideline for controller development

После того, как пользователь создал новый проект, доску или пон ему после POST запроса должен вернуться id соответствующей сущности, который должны быть переведен в адрес по которому мы перейдем на страницу нового проекта, доски или пина.

В случае с доской и проектом мы получим почти готовый роут в котором нужно все . заменить на / для навигации, в случае с пином мы сразу получим отстрингованный id, который просто нужно вставить в роут.

@SixDevelop реализовать перенаправление на фронте
@mohorka проверить правильность поведения API (возможно нужно возвращать ObjectResult а не Ok)

Problem caused feature request

Страница проекта предоставляет основную функциональность по работе с проектами: создание новых досок, добавление новых участников, тэгов, навигация к Review Request'ам, переход к существующим доскам

Requested Solution

Страница должна отображать данные по проекту - его название, краткое описание (если есть), список всех досок и кнопку по добавлению новых элементов проекта - пока только досок.

• fetch запрос на данные проекта
• fetch запрос на доски (исходя из данных залогиненного юзера)
  Для пользователю (или отсутствию залогиненного пользователя) мы проверяем какие данные он имеет право просматривать (доски) их мы и вернем как результат этого запроса

Route : ../{username}/{project-name} ❓ Здесь нужно подумать, как удобнее - будем ли мы строго привязывать проект к пользователю (админу) или нет?
Контроллер : ProjectController
Ветка для фронта : feature/project-page-front
Ветка для бэка : feature/project-page-api
Ветка для интеграции : feature/project-page-integration

Blocked #19

Problem caused feature request

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

Requested Solution

Опять же нужно учитывать, что не каждый юзер имеет доступ к любому пину и доске, так что если кто-то хочет через url напрямую получит доступ к скрытым данным, мы должны выдать ему ошибку поиска (404)

• ⚠️ Дизайн для страницы пина
• fetch на короткие данные по пину (название и заголовочное сообщение)
• fetch на изображение заглушку
• fetch на загрузку исходника
• fetch на загрузку комментариев
• fetch на отправку нового комментария

Route : ../{username}/{project-name}/{boardId = int}/pin/{pinId - stringed ObjectId} ❓ Возможно мы можем как-то укоротить длину URL
Контроллер : PinController
Ветка для фронта : feature/pin-page-front
Ветка для бэка : feature/pin-page-api
Ветка для интеграции : feature/pin-page-integration

Blocked #19 #20 #21

Problem caused feature request

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

Requested Solution

JWT, Cookies

Ветка : feature/auth-verification

Problem caused feature request

Стало понятно, что у нас слишком сложная вложенная структура сущностей

Requested Solution

Мы упростим структуру отказавшись от Pin Group и оставим только вложенные в доски Pin'ы.

Branch: reimagine/pin-group-deprecation

Problem caused feature request

We need to store domain specific data for our service

Requested Solution

In order to use Identity we will store auth specific data (usernames & passwords) in MS SQL db & all other data in MongoDB.

User

Repository

Canvas

Message

Pull Request

Edit Request

File

Commit

Alternatives

Possibly we could store all data in MS SQL db except file data, however 1-to-many relationship is much easier in mongo

Additional Info

This data used for storing in db, for views we will have additional view models described in issue for pages

Проблема

Отсутствие UI приводит к тому, что нет четкого понимания, какие компоненты на страницах нам нужны и что в них должно быть (какие данные), поэтому затруднительно писать сервисы и компоненты для front'а и endpoint'ы для back'а

Решение

Требуется разработать дизайн для следующим компонентов:

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

2. Страница регистрации
   
   Здесь нужно так же учесть валидацию модели формы, т.е. как будут высвечиваться ошибки, если данные введены неверно

3. Страница пользователя (концептов нет)
   Страница пользователя должна отображать

   • Аватар пользователя
   • Его данные - юзернейм, реальное имя, почту (опционально)
   • Переход на страницу настроек профиля (изменения данных и настроек приватности)
   • Список проектов пользователя
     Каждый проект отдельно отображает
     • Название проекта
     • Его автора (это не обязательно сам пользователь, речь идет вообще о всех проектах в которых он принимает участие)
     • Уровень приватности (скрытые проекты, которые доступны залогиненному пользователю и тому, на чей странице мы находимся так же отображаются)
     • Описание проекта
       Список проектов мне кажется лучше сделать либо списком из карточек, либо таблицей
   • Кнопка создания нового проекта
   • Форма создания нового проекта - высвечивается поверх страницы в виде окошка, содержит в себе следующие поля:
     • Название проекта
     • Описание проекта
     • Уровень приватности проекта
     • Валидация данных проекта - один пользователь не может иметь 2 проекта с одинаковыми названиями (с точностью до нижнего регистра букв и пробелов)

4. Страница проекта
   Страница проекта должна отображать

   • Список досок в рамках проекта (это что-то типа задач)
     На доске отображается

     • Название
     • Короткое описание
     • Прикрепленные тэги
     • Аватарки участников доски
     • ВОЗМОЖНО значок того, что в рамках доски открыт Review Request (запрос на проверку сделанной работы)

   • Название проекта

   • Краткое описание проекта

   • Кнопка добавления...

     • Новой доски
       Выскакивает формочка которая отображает поля для
       • Названия новой доски
       • Короткого описания
       • Поле для подробного описания задачи - диздока (сюда можно еще дроп-даунов грузить фотки)
       • Настройки приватности (кому виден проект - дроп-даун меню)
       • Дроп-даун список в котором отмечаются те кого мы делаем участниками доски
       • Дроп-даун меню для выбора тэгов которыми мы метим данную доску
     • Нового участника
       • Выскакивает поле поиска, которое асинхронно обновляется показывая наиболее подходящих по запросу пользователей
     • Нового тэга
       • Выскакивает поле в котором нужно ввести название тэга, его описание и выбрать цвет (ввести hex представление) + кнопочка случайно генерации цвета

   • ЕСЛИ ЭТО КРАСИВО то можно так же сразу отображать участников проекта и тэги

   • Список открытых Review Request'ов

     • Название доски в которой сделан ревью реквест
     • Название ревью реквеста
     • Тэги прикрепленные к ревью реквесту

   • Иконка перехода к настройкам проекта (данные и приватность)

Есть следующие наработки (явно плохо, прости @SixDevelop )

5. Страница доски
   Аналогично странице проекта мы отображаем
   • Название доски
   • Короткое описание доски
   • Специальную вкладку в которой отображается сообщение-задание к доске (как и все сообщения оно отображается в виде текста с аватаркой автора и датой публикации)
   • Список исходников разрабатываемых к доске (исходник - файл историю которого составляют Пины, которые создают художники в процессе работы)
   • Грид состоящий из пинов
     На пине (это что-то типа коммита, только прикрепляется изображение) отображается
     • Thumbnail - это небольшое изображение, которое было прикреплено к пину
     • Некоторая начальная часть сообщения к пину
     • Автор пина
       Пины сгруппированы по исходникам (т.к. каждый пин содержит некоторую версию исходника к которому он прикреплен по времени)
   • Тэги прикрепленные к доске + интерфейс по их изменению (через кнопку рядом со всеми тэгами например)
   • Список участников доски + интерфейс по добавлению/удалению

Ожидаются дополнения для прочих страниц и компонентов

Заметки

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

Задача

Требуется разработать базовую версию для десктоп клиента

Чек-лист

• Сетап системы с Caliburn.Micro
• Форма для логина
• Общий сервис инкапсулирующий логику подгрузки данных
• DI
• Отображение проектов пользователя после логина

Branch: feature/desktop-client-groundwork

Problem caused feature request

На странице доски мы отображаем задачу, исходные файлы и ассоциированные с ними пины (коммиты) с превьюшками

Requested Solution

На этой странице нужно грузить много изображений и она самая сложная из всех (примерно). Страница принимает id доски в рамках проекта (т.е. переходя на страницу мы будем отправлять данные по проекту и id (номеру) доски в рамках проекта.
⚠️ Нужен реально очень хороший и функциональный дизайн для этой страницы, который по большей части и повлияет на требуемый ей интерфейс взаимодействия с сервером

• fetch для получения данных о доске (название, описание)
• fetch для загрузки задачи (некоторого текстового фрагмента, пока что неформатированного)
• fetch для загрузки коротких данных об исходниках
• fetch для загрузки списка пинов для конкретного исходника

Route : ../{username}/{projectname}/{boardId = int}
Контроллер : BoardController
Ветка для фронта : feature/board-page-front
Ветка для бэка : feature/board-page-api
Ветка для интеграции feature/board-page-integration

Blocked #19 #20

Проблема

Положим у нас есть два пользователя - user_1 и user_2. Мы залогинились под user_1 и перешли на страницу user_2 (при это исчезла кнопка добавления проекта, т.к. мы не можем создать проект от лица другого пользователя).

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

Правильное поведение: все данные должны обновиться

Describe the bug

На домашней странице неправильно строится ссылка на страницу пользователя
Ссылка должна быть в формате /:username

Так же данная проблема проявляется в одном из подкомпонентов nav

Problem caused feature request

We use ASP.NET Core MVC => we need controllers for this kind of work

Requested Solution

Auth Controller
Used with Identity - @mohorka you know what to do

• login view & form (get/post)
• register view & form (get/post)

Home Controller

• welcome view

User Controller

• user page view
• change user data (name & username, async)
• change user avatar (async)

Repository Controller

• create repository view & form (get/post)
• repository view
• delete repository request
• edit repository data (description - async)
• add/remove collaborators from repository (possible async)

Canvas Controller

• create canvas view & from (get/post)
• delete canvas
• add/delete assinees (possibly async)
• add message (async)
• add review (pull) request (async)
• answer with edit request (async)
• add file (async)
• new commit (load file from PC - async)

Alternatives

No

Additional Info

No

Для страницы пина, как на бэке, так и на фронте нужно произвести ря улучшений

1. Нужно отображать чат. Чат представляет из себя список уже отправленных сообщений +сверху вниз от самого старого к самому новому, в самом верху сообщение, которое было прикреплено к названию пина)

Endpoint: api/pin/messages/{id} возвращает массив из объектов:

{
	username:string;		// author username
	message:string;			// text that should be displayed
	publicationDate:Date;	// when this message was published
}

2. Нам нужна кнопка по загрузке файла, который мы храним в базе по id pin'a

Endpoint: api/pin/file/{id}

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

Endpoints: api/user/avatar/{username}
api/image/{id} id - стрингванное представление ObjectId в базе

Problem caused feature request

Теперь нам нужно разработать реальные репозитории для работы с данными в MongoDb (MongoDb.Driver + GridFS)

Requested Solution

Аналогичным образом #26 на основе уже созданных интерфейсов разрабатываются реальные методы доступа к данным посредством MongoDb (через класс контекста данных)

Нужно реализовать репозитории для:

• Проекты
• Доски
• Пользователи
• Пины исходников (Pin Group)
• Пины

Ветка : feature/data-layer-mongo

Blocked #26

Problem caused feature request

Нам нужно быстрее приступить к тестированию взаимодействия фронта и бэка, но для этого нам нужно брать данные. Поэтому предлагается для начала сделать моки repository pattern'а, для доступа к данных, т.к. это более стабильный и простой способ работы с данными.

Requested Solution

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

• Интерфейсы для доступа к
  • Проектам
  • Доскам
  • Пользователям
  • Пинам исходников (Pin Group)
  • Пинам
• Моки репозиториев (хранят статический список объектов и передают данные через него)
  • Проектам
  • Доскам
  • Пользователям
  • Пинам исходников (Pin Group)
  • Пинам

Ветка : feature/data-layer-mock

Ветку в которой @AndyS1mpson работает сейчас нужно перекинуть в новую, чтобы она соответствовала названию

Before actual development, we need to create optimized find out basic information about

• How .psd file is structured
• How git works (basic git feature of finding file deltas)
• Is there any way to optimize deltas?
• How we can store delta data locally?
• How we can make branching (made in git)?

Useful links were shared but would be duplicated in the thread

All the research results should be posted there, in comments

@mohorka check this out!

Баг

Возникла проблема из-за которой ряд вложенных async/await выражений не успевает заканчивать работу и мы не получаем результат.

Проявления

Проявляется при каскадном удалении данных пользователя для моков (не проходится юнит-тест)

Решение

Мы должны выстроить систему в которой async/await вызывается только один раз - в контроллерах или сервисах, поэтому все методы слоя данных должны просто возвращаться Task и не использовать async/await. К тому же нужно разработать синхронные версии всех методов - пока для моков, а так же прописать их в интерфейсах.

@mohorka - решает задачу на уровне контроллеров/сервисов
@AndyS1mpson - решает задачу на уровне слоя данных

Дополнительно

Branch: bug/data-layer-async-await-hell-fix; bug/web-async-await-hell-fix

Problem caused feature request

We need to analyze & rebuild different file formats including .psd for out Version Control System #1

Requested Solution

Based on official Adobe Photoshop File Formats Specification we can create a special storage data type and examine .psd files creating object of this type, which will store only data needed for building .psd file from it. Then we will find what properties are different in 2 files and create a delta data object which we will store instead of another .psd file in some .json-like manner.

Short list of to-dos

• .psd format storage file
• .psd format parser
• .psd format builder
• Delta type & delta building mechanism (from 2 files)
• Delta serialization & deserialization (setup for commit system)

Alternatives

No. Open for them ✋

Additional Info

This is the foundation for entire system so it should be stable, fast enough & robust

Problem caused feature request

Нам нужен ряд страниц с которых пользователь может создавать новые объекты в нашей системе - проекты, доски, пины и т.д.

Requested Solution

Нужно три страницы с простыми формами и fetch-запросами который будут в случае успеха редиректить на только что созданный объект (т.е. на страницу пина, доски или проекта)

• Create Project Page
• Create Board Page
• Create Pin Page

В идеале на них должна асинхронно проводиться валидация данных

Route :
../{username}/create
../{username}/{projectname}/create
../{username}/{projectname}/{boardId}/create
Контроллеры : ProjectController, BoardController, PinController
Ветка для фронта : feature/creation-pages-front
Ветка для бэка : feature/creation-pages-api
Интеграция : feature/creation-pages-integration

Blocked #19 #20 #21 #22

Problem caused feature request

In order to properly separate MongoDB specific expressions we should develop interfaces for models of out mongodb & database itself

Requested Solution

1. Database should be called artareamongodb
2. For each collection inside database assignees should provide Data Services which are classes & interfaces that encapsulate work with db entities. For example we have a collection of some User objects inside out db class (let's call it ApplicationDbContext) which is defined as

class ApplicationDbContext
{
    // some fields & other properties 
    IMongoCollection<User> Users => db.GetCollection<Users>("users"); 
}

For it we define an interface:

interface IUserDataService // all this kind of interfaces are ended with DataService suffix
{
   void GetUsers();
   void GetUser(string id);
   // ... other methods that implement CRUD interface
}

And a class which implements this interface (where we actually write real code for working with data:

class UserDataService : IUserDataService
{
   // field that stores our most low-level database interface
   private ApplicationDbContext context; 

   // constructor that gets ApplicationDbContext object via DI (configured in Startup)
   public UserDataService(ApplicationDbContext context)
      => this.context = context;
   public void GetUsers() { /* implementation */}
}

Also @SabinaAlieva wishes to test this via Postman and API controllers which sounds like good idea however it's time consuming and can cause some unpredictable problems. Also worth mentioning that this should be tested with unit tests (each method with several tests which test different behaviour). See xUnit which is simple and supported out-of-the-box by VS (and supposed to be used with .NET Core projects)

Alternatives

No

Additional Info

Assignees @SabinaAlieva & @AndyS1mpson! Remember that you should implement methods that controller developers request first of all

Problem caused feature request

Страницы по регистрации и логину пользователя (именно от них мы будем получать данные о залогиненном пользователе и проверять их по ходу работы)

Requested Solution

Пара страниц, пара fetch запросов на регистрацию, в идеале асинхронная валидация данных

Blocked #19 #20 #21 #22 #23 #24

Route :
../join
../signin
Контроллер : AuthController
Ветка для фронта : feature/auth-front
Ветка для бэка : feature/auth-api
Интеграция feature/auth-integration

Problem caused feature request

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

Requested Solution

Страница пользователя должна отображать данные пользователя - его никнейм, имя, почту, аватар. Так же нужно разработать базовый дизайн для это страницы. Также на странице пользователя должна быть кнопка для создания нового проекта и таблица (из карточек) с проектами в которых пользователь является участником (collaborator)

• Дизайн для страницы (Adobe XD wires) @SixDevelop @hypnospinner
• Страница принимает имя пользователя (никнейм) как ключ (т.к. оно уникальное для каждого юзера (в запросе ссылки)
  • fetch запрос на данные (т.е. метод в контроллере и отдельный компонет в анге)
  • fetch запрос на аватар ( -//- )
  • fetch запрос на список проектов ( -//- )

Route : ../{username}
Контроллер : UserController
Ветка для front-end'а : feature/user-page-front
Ветка для бэка : feature/user-page-api
Ветка для слияния и интеграции: feature/user-page-integration (в нее сольются и свяжутся результаты первых двух веток и она потом зальется на мастер)