practice-uffs/mural

Sistema para coleta de sugestões, ideias e críticas relacionadas ao projeto.

mural's Issues

Atualizar a estrutura de banco de dados

Depende de: #2

Atualizar a estrutura do banco de dados para refletir o novo caso de uso (coleta de feedback). Preferencialmente gerar um modelo entidade-relacionamento para a equipe entender as dependências.

Implementar o MER utilizando eloquent e orm do Laravel.

[FRONT] Criar estilos globais

Semelhante ao modo como o bootstrap faz, devemos criar cores botões e outros elementos, utilizando sass. Desta forma, não será necessário adicionar estilos a cada novo elemento que precisa ser criado.

Implementar /items/create

Nessa página o usuário poderá criar um novo item. Um item deve, obrigatoriamente, conter as seguintes informações:

• Título
• Descrição
• Categoria (dropdown com um grupo limitado de categorias)
• Local (dropdown com uma lista completa de tuplas Location).
• Visível para todos? (boolean)

Criar estrutura inicial do projeto baseada no tccr

O projeto tccr contém a estrutura básica implementada em Laravel para iniciar o web-feedback. Copiar o conteúdo que existe naquele repositório para esse.

[Feedback] Implementar/modificar tela inicial

Relacionado à discussão em #71.

A tela inicial deve ser modificada, permitindo duas views uma para usuários autenticados (logados) e outra para usuários não autenticados (visitantes). Esta issue automaticamente depende de #49.

Ambas contam com a listagem dos itens criados (e visíveis). Se o usuário estiver logado, um botão "Adicionar Ideia" (mudar nome) estará disponível. A ação ao clicar neste botao está descrita em #77.

• Exemplo de tela para usuário não autenticado:
  

Implementar view /items

Nessa página qualquer usuário (ou visitante) pode visualizar todos os itens cadastrados no banco de dados. O visual dessa página deve ser, obrigatoriamente, uma cópia desse projeto.

Criar página que lista serviços

Página: S001-A

Criar a página que lista os serviços existentes no sistema. Conforme a descrição da tela, um link chamado "Serviços" precisa existir na navbar do site.

A página S001-A pode ser a mesma para todos os usuários, porém com um comportamento diferente para cada um:

• Usuário autenticado (comum): mostra apenas os serviços criados por esse usuário
• Usuário autenticado (admin/equipe): mostra todos os serviços existentes no sistema

No momento não temos informações sobre quais usuários são administradores ou não, porém podemos deixar isso para a próxima sprint. Pode fazer esse controle diretamente no controller da página, marcando um usuário como admin se o idUFFS dele estiver dentro de uma lista de idsUFFS hardcoded no próprio controller.

Deixamos isso como dívida técnica para podermos entregar o site nessa sprint.

[UX/UI] Adicionar "loaders" para melhorar a experiência do usuário

Os comentários e reações são feitos utilizando requisições assíncronas que em alguns casos podem demorar um pouco (esta demora pode ser mitigada resolvendo #61, porém não totalmente resolvida). Portanto seria interessante adicionar alguma resposta visual durante este tempo de espera.

Atualizar README do projeto com informações relevantes

Atualmente o conteúdo é aquele gerado pelo template. É necessário atualizar as seguintes informações:

• Informações sobre o projeto (descrição, funcionalidades, logo, etc);
• Instruções de como executar o projeto;

Atualizar o design para cores claras e material design

No estilo do que foi feito no site do PRACTICE (ver esse PR), precisamos alterar o layout do web-feedback para ser claro e seguir o material design.

Subtarefas desta issue:

• Adicionar MDBootstrap à base;
• Mudar o layout de /items/ (e todos os endpoints associados);

[Dúvida, UI/UX] Troca entre visualizar Ideias e Serviços

Nas issues #49 e #76 a "home" foi refeita. Restou apenas uma questão que eu comentei no documento com as telas, mas acabei esquecendo de retomar mais à fundo no desolvimento das issues citadas. Haverão duas "views" para a home, uma mostrando ideias e outra mostrando apenas serviços. A minha dúvida é se a aba de serviços deverá estar visível apenas para usuários que sejam membros do PRACTICE ou que tenham criado um serviço, já que serviços ficam visíveis apenas à estes membros. Assim, apenas os serviços que podem ser visualizados pelo usuário logado estariam visíveis nesta aba (membros do PRACTICE veriam todos, e demais usuários veriam apenas serviços criados).

Caso um usuário não tenha criado nenhum serviço, a aba "serviços" ficará vazia, e isto não me parece muito bom. Poderíamos mostrar uma mensagem como "Você ainda não criou nenhum serviço" quando for o caso, mas do ponto de vista de UI/UX acredito que seria melhor remover esta aba quando não houver conteúdo a ser mostrado. Claro esta é apenas minha opinião e eu não tenho experiência nem conhecimento algum em UI/UX, apenas prefiro a ideia de adicionar este dinamismo.

Há um botão para criar serviços na home, que estará visivel à todos os usuários.

Em relação à complexidade, não acho que será adicionada muita, e como vou desenvolver esta parte, já adianto que está ok assim, o prazo não será afetado.

[Dúvida] Dúvidas em relação à issue 41 do programa

Tenho algumas dúvidas sobre o comentário do @lcaimi nesta issue. Algumas dúvidas são em relação á compreensão outras são em relação à implementação, por isso vou marcar o @Dovyski aqui tbm:

1. Este formulário apareceria depois que um Serviço fosse requisitado, ou este form diz respeito a um Serviço?
2. Não compreendi o significado dos campos Tipo, Público-alvo e Roteiro resumido, alguem poderia, por gentileza esclarecer isto?
3. Esses campos compreenderiam uma nova entidade (distinta de Item) certo? Neste caso qual nome deveríamos "adotar" para ela?
4. Caso este formulário deva ser mostrado quando o usuário for requisitar um serviço, devemos alterar a forma como fazemos agora, utilizando um objeto Item para tudo, ou a requisição de um feedback seria semelhante?

(PS: desculpas por estar buscando sanar as dúvidas apenas agora, depois de tanto tempo com a issue aberta).

Implementar /items/{id}/edit

Depende de #18

Criar a página que permite que um usuário edite o conteúdo de um item. Apenas o usuário que criou o item pode fazer isso, os demais usuário não tem autorização.

[FRONT] Aperfeiçoar o header/navbar

Há um header/navbar nas views envolvendo items. Ele deve ser melhorado, mostrando a logo do practice e dados do usuário logado.

O design do header pode ser semelhante ao site do practice, com as adaptações necessárias.

[Engenharia] Definir requisitos de forma mais concreta

Como já mencionado, o web-feedback é um sistema que está ainda em desenvolvimento, ele nasceu como uma ideia que ainda está em evolução. Esta característica aprensenta a vantagem de podermos moldar algo de acordo com as necessidades emergentes, atendendendo-as de forma mais completa. Todavia, esta maleabilidade torna o desenvolvimento em partes turvo, gerando certa lentidão e retrocesso. Em vista disso, crio esta issue para que centralizemos/definamos algumas ideias no intuito de modelar algumas funcionalidades de forma mais concreta.

Qualquer ideia e necessidade deve ser relatada aqui. Quando uma quantidade suficiente for coletada, o @arufonsekun e eu iremos criar as issues e desenvolvê-las.

Não há nenhum problema em alterar o software, como ocorreu com o Item/Service - #70 - e com o Homer - #49, apenas acreditamos que centralizando as necessidades e gerando uma espécie de "requisitos funcionais" (de forma nada criteriosa) podemos entregar um produto com maior qualidade e que melhor atenda aos objetivos pelos quais foi concebido.

Para este fim, irei marcar o @Dovyski e o @lcaimi, para que qualquer modificação seja relatada aqui. @arufonsekun e eu também iremos reportar aqui possíveis modificações relevantes que observarmos.

Commits em inglês?

Vamos fazer os commits em ingles como fizemos com o app-covid, @jeanchilger @arufonsekun ?

Criar página /items/{id}/comment

Depende de #13

A página /item/{id}/comment permite que um usuário comente um item. Na modelagem do banco de dados, o modelo Item representa tanto ideias/feedbac/críticas/etc quando comentários (todos são modelados para a mesma tabela). A diferença está no campo parent_id. Se ele for nulo, significa que o item é uma ideia/sugestão/etc. Se o parent_id for um inteiro (que é o id do item a qual ele se refere), significa que esse item é um comentário do item com id == parent_id.

Mostrar nome, idUFFS e pequeno avatar de usuários autenticados

Conforme as descrições do sistema, usuários autenticados em informação do nome, idUFFS e um pequeno avatar no canto superior direito da tela. Isso precisa ser implementado. O avatar pode ser um placeholder qualquer no momento, porque não temos a API para isso.

Usuário postar um feedback/pedido

Depende de: #2

Implementar a página básica onde usuários possam interagir com um formulário que tenha os seguintes campos:

• Tipo (dropdown com: Sugestão, Crítica, Ideia, Reclamação, Medos e comentários
• Visibilidade: pública (todos que visitem o site podem ver) ou privada (não listada, somente a equipe PRACTICE pode ver).
• Descrição (texto com no máximo 800 caracteres)
• Nome
• Função (Docente, Discente, TAE, comunidade externa)
• E-mail do usuário

O elemento Project (controller e modelo de banco de dados) do projeto tccr já tem isso implementado. Precisa apenas alterar os campos e os formulários.

Dúvida em relação à estrutura do repositório

Atualmente há uma pasta src e uma pasta docs. A pasta docs será utilizada para algo (como integração com o github pages) ou podemos removê-la e deixar o conteúdo de src direto na raiz?

[FRONT] Substituir view items/

Substituir a dashboard HOMER por uma feita manualmente (ou outra mais modificável). A nova dashboard deve disponibilizar as mesmas funcionalidades da HOMER.

Não foi possível personalizar a dashboard, de modo que esteja de acordo com as demais seções, bem como satisfazer à issue #16.

Implementar /service/create

A página /service/create tem a mesma funcionalidade que a página de criar um item. A diferença é que um serviço está vinculado obrigatoriamente a uma categoria (category) e, internamente, ele é usado pela equipe para saber que um membro da comunidade acadêmica precisa de algo.

[FRONT: comentário] Bug ao adicionar um novo comentário

Quando um novo comentário é adicionado, o espaçamento fica muito elevado.

Uma possível seria alterar o formato como a timeline está sendo criada, utilizando este formato no lugar.

[FRONT: reação] Resolver bugs na interface

Algums bugs visuais estão ocorrendo:

• Ao criar uma reação e em seguida excluí-la, o botão de nova reação para de funcionar (o dropdown não aparece);
• Com uma reação já criada, ao clicar em Editar e em seguida voltar, clicar na reação irá deletá-la mas a interface não é atualizada;
• Quando nenhuma reação existe, o botão para nova reação fica mal posicionado.

Erro ao rodar npm run dev

Erro ao rodar npm run dev - o erro não afeta a geração de arquivos (build), mas ainda assim é um erro.

Reproduzir
Etapas para reproduzir o problema:

1. Entre na pasta src/
2. Execute npm run dev
3. Ver erro

Comportamento esperado
O erro não deveria ocorrer, aperence apenas a mensagem Compiled successfully.

Captura de tela mostrando o erro

Notas adicionais
De acordo com pesquisas efetuadas, este erro é decorrente de incompatibilidades entre versões do node, laravel-mix e @babel/compat-data.

[BACK: Item] Alterar modelo Category

O modelo Category deve ser alterado, adicionando um campo item_type (ou algo do tipo, este é apenas um exemplo), permitindo que hajam categorias distintas para Feedback e Serviço.

O seed CategorySeeder precisa ser modificado de acordo. Por enquanto vamos utilizar os seguintes valores:

• Para Feedback: Sugestão, Crítica, Ideia e Reclamação;
• Para Serviço: Modificação, Nova Funcionalidade; (como comentado pelo @Dovyski, futuramente poderá haver integração com o sistema de issues do github, e portanto acho que seria interessante que as catogorias de Serviço fossem semelhantes às labels das issues).

Após isso basta alterar o método items.create para filtrar a categoria.

Alterar branch dev para default

@Dovyski, por gentileza, alterar a branch default para a dev (atualmente a master é a default), pois eu não tenho permissão para tal.

P.S.: Caso vamos manter a master como default, esta issue pode ser fechada e ignorada.

Ajustar Github Action relacionada à ci.uffs.cc

Alguma coisa não está certa nessa action, o que impede que a equipe usufrua do ci.uffs.cc. Verificar e corrigir esses problemas.

Criar view /items/{id}

Nessa página, o usuário poderá visualizar em mais detalhes um item em específico. Ao contrário da view /items, que mostra todos os itens em retangulos em um formato de mural, a view /item/{id} é mais específica e mostra o seguinte, em uma página cheia:

• Títlo e descrição (conteúdo) do item
• Autor do item
• Lista de reações feitas no item (estilo reações em uma issue no github)
• Lista de comentários (e as reações em cada um, estilo reações em uma issue do github)

As informações de comentário são mostradas em uma linha do tempo, exatamente no mesmo estilo das discussões em uma issue do github.

[FRONT: reação] Adicionar sistema de reações nos demais itens

Assim como feito para itens (items.show), adicionar reações para comentários, pedidos e serviços.

Depende de #5 e #17.

[REFACTOR: reações] Mudar a estratégia de criação de reações

Atualmente, sempre que uma nova reação é criada, é realizada uma nova requisição, e toda vez todas as reações são iteradas para saber se o usuário criou alguma delas. Esta estratégia foi adotada devido à falta de conhecimentos, todavia ela é muito custosa e há diversas outras abordagens que podem ser adotadas no lugar, aumento a velocidade de criação/exclusão de reações.

Disponibilizar todos os pontos de API através de /api/

O sistema terá interação com o aplicativo móvel do practice, então todos os dados precisam estar disponíveis para leitura através do endpoint /api/. Essa tarefa está relacionada à criação da base para que essa API comece a funcionar.

Depende de #5, #14 e #17.

[Arquitetura] Refatorar Models, Views e Controllers

O intuito desta issue é elevar a semântica no backend. Itens com um * ao lado representam itens cuja proposta será estudada com mais calma, para averiguar se a mudança a que se refere irá contribuir sem adicionar muita complexidade.

Modificações

1. • Deverão ser criados resources para Service e para Feedback. Como feito com Comment, permitindo utilizar todo o backend de Item, modificando apenas alguns campos para uma melhor semântica;
2. • *Deverão ser criados controllers dinstintos para Service e para Feedback. Estes controllers não precisam implementar tudo do zero, verificaremos uma possível herança de ItemController, reescrevendo apenas o necessário;
3. • *Deverão ser criadas views específicas para Service e para Feedback. Dado que possuem muitos aspectos semelhantes muitas views serão mantidas as mesmas para ambos, no entanto, caso seja possível criar algumas views distintas sem agregar muita complexidade e trabalho, seria uma prática interessante.

Esclarecimentos

• Optaremos por chamar (pelo menos internamente) o atual Item como Feedback, pode ser?;
• A implatanção do item 1. pode eliminar a necessidade do item 2..

Ajustar Github Action relacionada ao deploy

Alguma coisa não está certa na action que faz deploy automático no servidor de produção mural.practice.uffs.cc. Verificar e corrigir esses problemas. Minha análise inicial é que a versão PHP do servidor não bate com os requisitos de algum pacote, o que ocasiona o erro.

[Discussão] Usar a mesma view para serviço e para feedback

As issues descrevendo as funcionalidades de feedback (#5) e de serviço (#17) são muito semellhantes, e a view items.create já está criada, atendendo a maioria delas. A ideia é utilizar a mesma view (e consequantemente controller) para ambas as funcionalidades, e como eu farei a #5 e o @arufonsekun está fazendo a #17, acho interessante levantar uma discussão sobre como poderíamos aproveitar os recursos.

[Feedback] Desenvolver/refatorar formulário de criação de feedbacks

O formulário de criação de um novo Feedback, já existente, deve ser feito no formato de modal.

[Docs] Mockup do sistema e modelagem do banco de dados

• Criarei essa issue pra facilitar a referência ao mockup e schema do banco de dados;
• Essa issue também serve para documentar o fuxo do sistema e suas funcionalidades;
• Link para o documento caso seja necessário;

1. Schema do banco de Dados:
   

2. Tela inicial com a listagem dos itens, usuário não está autenticado, nesse estado ele poderá somente visualizar itens (Ideias e Serviços);
   

3. Tela inicial com a listagem das ideias, usuário está autenticado, nesse estado deve ser possível que ele crie novos itens (Ideias, Serviços, Comentários, etc);
   

4. Modal onde deve possível criar uma nova Ideia;
   

5. Tela onde é listado os Serviços, nessa tela deve ser possível filtrar pelos campos Somente os meus e Categoria;
   

6. Modal onde deve ser possível criar um novo Serviço;
   

7. Tela onde será possível apenas visualizar uma Ideia e seus comentários. Uma vez que o usuário não está autenticado ele não poderá criar comentários;
   

8. Tela onde será possível visualizar uma Ideia e seus comentários e reagir a eles (curtir, comentar, dar amei, etc), estes somente se o usuário estiver autenticado;
   

9. Tela onde será possível visualizar um Serviço e seus comentários e reagir a eles (curtir, comentar, dar grr, amei, etc???), tudo isso somente se o usuário estiver autenticado;
   

[Discussão] O que fazer quando um item é criado

Quando um Serviço e um Feedback são criados, ocorrem comportamentos distintos: para serviço uma mensagem é mostrada, e para feedback nada ocorre (:sob:). Poderíamos ajustar isto, por isso criei esta issue, no intuito de agruparmos algumas sugestões.

A minha sugestão (até então) é fechar o modal de criação e mostrar um popup com a mensagem de item criado. Neste caso o loader poderia aparecer antes do popup ou no próprio popup.

Implementar /api/items

Esse endpoint deve imprimir um json com um array itens existentes no banco de dados.

[BACK] Criar seeders para Categoria e para Local

Criar seeders para a Categoria e para o Local (ambos utilizados na criação/edição de um item).

[BUG: Item] Variável hidden não mantém valor

Dois bugs foram identificados em relação ao campo hidden (switch "Este item ficará visível para todos?"):

• Ao clicar em editar um item, no formulário de edição, o campo hidden não mantém o valor vindo do banco.
• Ao modificar o valor de hidden, o mesmo não responde como esperado (parece estar "negado").

Ajustar token do login

Caso esteja rodando o projeto pela primeira vez, deverá ajustar o token do login uffs, para que funcione de forma esperada. Siga as instruções abaixo para efetuar a alteração corretamente (é necessário ter executado de antemão os passos descritos no README).

1. Abra o arquivo vendor\ccuffs\auth-iduffs\src\AuthIdUFFS.php;
2. Vá para a linha 48, no método getServiceToken();
3. Aletere o valor do retorno da função para eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogIjRrZ2N0dHZ2OWk5OWN0cWx2MHJqc3VkY2Y2IiwgInJlYWxtIjogImRjPW9wZW5hbSxkYz1mb3JnZXJvY2ssZGM9b3JnIiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3k1RVlrTHcwMnk5U1M1akVTZ0tyaFpnQXF5T0NxVUkzVS4qQUFKVFNRQUNNREVBQWxOTEFCTTNPREkxTURRME9ERTJNRE15TXpreE16VTVBQUpUTVFBQSoiIH0.JQsjq26NVT5iKWG5ZvOKqy3m_x8XtxN0PvkPAEtix4g;
4. Pronto!

[FRONT] Adicionar dashboard à base

Adicionar a dashboard homer à base.

Apenas os arquivos estáticos são necessários, a princípio.

Adicionar botões para criar nova "Ideia" e "Serviço" na página inicial

Depende de #7

Depois que #7 for implementada, haverá um painel mostrado lodo abaixo do header e antes da lista de itens (na figura do dashboard o título desse painel é 👋 Demo !). Ao implementar essa issue, o conteúdo desse painel deve ser trocado para um texto mais amigável, tipo:

Essa página contém todas as ideias, críticas e afins que os membros da comunidade acadêmica tem e gostariam de socializar com todos, inclusive a equipe PRACTICE.

Além disso, o painel também precisa ter dois botões (de cores diferentes):

• Criar nova sugestão/crítica/etc (redireciona para /item/create)
• Solicitar um serviço (redireciona para /service/create).

[Back] Criar entidade specifications

Para implementar essa issue será preciso criar o model Specifications contendo os seguintes campos:

• id : bigIncrements
• item_id: foreignId
• content: text
• created_at: timestamp
• deleted_at: timestamp
• Também deverá ser implementado o relacionamento 1:1 com o model Items;
• Para mais detalhes verificar schema do banco de dados na issue #78;

Mudar controllers para resource controllers, e adequar rotas

Exemplo de mudança

Atualmente está assim:

Route::get('/item/create', 'ItemController@create')->name('item.create');
Route::post('/item', 'ItemController@store')->name('item.store');

Deve ser modificado para:

Route::resource('/items', 'ItemController');

• Ver resource controllers na documentação do Laravel;

Erro ao executar migrations

Descrição do bug/problema
Ao executar o comando php artisan migrate um erro ocorre (ver screenshot). O banco deve estar totalmente vazio para exeutar.

Acredito que o problema seja decorrente de algum conflito nas relações definidas entre as tabelas items e users (isto é descrito no erro que ocorre).

Reproduzir
Etapas para reproduzir o problema:

1. Certificar-se de que o banco de dados utilizado está vazio (sem nenhuma tabela);
2. Executar php artisan migrate;
3. Ver erro.

Comportamento esperado
As tabelas deveriam ser criadas, conforme especificado nas migrations.

Capturas de tela

Trying to get property 'reactions' of non-object

Depois de fazer um checkout do código, e init do banco, incluindo os seeders, ao acessar items/create o seguinte erro acontece:

[Service] Desenvolver/refatorar formulário de criação de serviços

• Adequar o formulário de criação de Serviços para que ele passe a ser estruturado no formato de modal.
• Seguir o mockup abaixo;

Implementar reações em um item

Ao visualizar qualquer item (seja ele uma ideia/sugestão/etc) ou um comentário, o usuário pode reagir a ele (da mesma forma que usuários do Github podem reagir a comentários em issues). A reação é basicamente o usuário colocar o mouse sobre uma área do conteúdo, uma lista de emojis é mostrada, o usuário clica em uma delas e a reação fica atrelada ao item. Se o usuário clicar sobre o emoji de reação depois de ele ter sido escolhido, a reação é removida.