Na visualização da usuária na área administrativa, a imagem do usuário está quebrada, e o Laravel está inserindo um valor 1 ao invés da URL da imagem do usuário.

Exemplo: http://localhost:8000/admin/users/1

Essa view é montada aqui - https://github.com/caronae/caronae-backend/blob/master/resources/views/users/user.blade.php#L3 - com uma imagem padrão caso não exista, mas por algum motivo essa lógica não funciona mais.

Um chute é que algum update do Laravel quebrou essa sintaxe (ou ela sempre esteve errada).

Atualmente a pesquisa por usuários pelo nome na área administrativa - http://localhost:8000/admin/users - funciona fazendo um ILIKE (case-insensitive LIKE) no banco de dados. No entanto, isso não funciona bem quando queremos pesquisar por uma composição do nome da pessoa - por exemplo, pesquisando pelo primeiro e último nome, como Bruno Neto, não encontraria um usuário Bruno Mateus Quintana Neto, pois o último termo não aparece junto com o primeiro.

Isso é um problema porque às vezes os usuários mandam mensagens de suporte só usando o primeiro e último nome, e aí essa busca pela equipe acaba sendo manual :(

No controller, essa query é montada aqui - https://github.com/caronae/caronae-backend/blob/master/app/Http/Controllers/Admin/UserController.php#L39-L41. Esse controller usa a biblioteca Laravel Backpack CRUD, mas isso não deve importar muito, porque essa query já está sendo personalizada por nós.

Uma possível solução seria substituir os espaços da pesquisa por um %, mas não testei e não sei se existe uma solução melhor.

Bônus: conseguir pesquisar ignorando acentos - por exemplo, a pesquisa por 'antonio' encontraria um usuário chamado 'Antônio'. Isso atualmente não funciona. Não sei sei o banco de dados (PostgreSQL 9.6) já possui alguma função pra considerar isso na pesquisa.

Atualizações feitas diretamente na branch master deveriam propagar automaticamente para a branch de develop.

Contexto

A branch develop representa o estado do ambiente de desenvolvimento, enquanto a branch master representa o ambiente de produção.

Normalmente os cards são feitos primeiros no develop e depois mergeados para master, mas às vezes são feitos commits diretamente na master (no caso de hotfixes, por exemplo) e o ambiente de desenvolvimento só é atualizado fazendo manualmente um merge do master no develop. Isso poderia ser automatizado no CI.

Na área administrativa existe uma view que mostra o perfil da usuária, como na imagem abaixo. Essa tela é usada pela equipe do Caronaê principalmente quando alguma pessoa tem algum problema e entra em contato com a gente, e precisamos encontrar os dados da pessoa:

No entanto, essa view atualmente não traz mais informações além do próprio perfil da usuária.

A ideia é acrescentar informações das caronas da usuária - como as caronas ofertadas e as caronas que ela participou. O próprio model User já retorna as caronas pelo método $user->rides(), que inclui um campo status que indica qual o relacionamento dele com a carona - driver, accepted, pending e refused.

A minha ideia era ter um bloco similar ao de 'Detalhes do usuário', só que de 'Caronas do usuário'. As caronas listadas podem exibir algumas informações, como:

• título da carona ($ride->title, que retorna algo como Japeri → Praia Vermelha | 21/03)
• motorista da carona (pq pode ser a própria usuária ou outra motorista)
• qual o status da usuária na carona (se é motorista, se já foi aceita ou ainda está pendente etc)
• qual o status da carona ($ride->done, se já foi finalizada ou não)
• número de caronistas na carona ($ride->riders->count())
• um link para a página da carona na área administrativa (/admin/rides/12345)
  (se achar relevante, veja a página da carona e quais são as informações disponíveis)

Código do controller: https://github.com/caronae/caronae-backend/blob/master/app/Http/Controllers/Admin/UserController.php (usamos a biblioteca Laravel Backpack CRUD, mas essa view é feita na mão, então não faz tanta diferença).
Código da view: https://github.com/caronae/caronae-backend/blob/master/resources/views/users/show.blade.php

O projeto conta com alguns seeders, que geram dados aleatórios no banco de dados, que estão desatualizados e, portanto, não funcionam. 😢

O que são seeders?

Os seeders permitem que qualquer pessoa desenvolvedora possa criar um banco de dados com algumas caronas e usuários de exemplo para poder testar as coisas e observar como funciona o sistema, sem precisar criar dados iniciais ou depender de um dump com dados reais de usuários.

Por exemplo, se acabei de baixar o projeto e criar o banco de dados, posso executar o comando abaixo e em seguida já teria dados de exemplo para visualizar como o sistema funciona:

php artisan db:seed

Detalhes

Os arquivos ficam na pasta https://github.com/caronae/caronae-backend/tree/master/database/seeds.

Os seeds utilizam factories, que são funções que criam caronas, usuários etc usando dados aleatórios. No entanto, devido a refatorações e mudanças nos Models, alguns desses seeders (ex: NeighborhoodSeeder) precisam ser reescritos usando os novos formatos e outros precisam ser criados (ex: InstitutionSeeder).

Na visualização da usuária na área administrativa, existe um campo 'Usuário desde' que não está aparecendo o valor.

Esse campo deveria mostrar o ano e mês que o usuário foi criado (usando o campo created_at).
Por exemplo: Usuário desde: outubro de 2018

Bônus: mostrar uma data relativa de criação do usuário. Exemplo: agosto de 2017 (há 1 ano e 2 meses) (dica: $date->diffForHumans())

Esta é a view onde isso é montado:
https://github.com/caronae/caronae-backend/blob/master/resources/views/users/user.blade.php

Eu chutaria que falta dizer que created_at é um campo date no model User e que faltou um format do Carbon pra exibir no formato certo.

Atualmente estamos usando a versão 5.5 do Laravel. No entanto, o Laravel já tem a versão 5.7 disponível.

Pra atualizar, precisamos seguir os passos do Upgrade Guide abaixo:

• Atualizando da 5.5 pra 5.6: https://laravel.com/docs/5.6/upgrade#upgrade-5.6.0
• Atualizando da 5.6 pra 5.7: https://laravel.com/docs/5.7/upgrade

Atualmente, enviamos uma notificação para as caronistas avisando caso uma carona que elas foram aceitas é cancelada.

No entanto, caso a usuária ainda esteja aguardando aceitação e a motorista cancela a carona, não enviamos nenhuma notificação, e a carona simplesmente some para a usuária.

A notificação é enviada no RideController, no método leaveRide, que é chamado quando a motorista cancela a carona.

$riders = $ride->riders()->get();
$riders->each->notify($rideCanceledNotification);

O problema é que $ride->riders() só retorna as caronistas que já foram aceitas, com status accepted:

https://github.com/caronae/caronae-backend/blob/master/app/Models/Ride.php

public function riders()
{
    return $this->belongsToMany(User::class)->wherePivot('status', 'accepted');
}

Precisaríamos mandar as notificações também para usuárias com o status pending. Isso poderia ser feito através de outro método ou adicionando uma flag nesse método existente para incluir ou não o status pending.

Outro problema é a mensagem da notificação. Na notificação RideCanceled, a mensagem precisa ser diferente caso a usuária ainda tenha status pending.

Ao invés de dizer Um motorista cancelou uma carona ativa sua, podemos verificar o status do relacionamento e, caso seja pending, dizer Um motorista cancelou uma carona que você havia solicitado.

O usuário do Caronaê deve poder visualizar apenas as caronas oferecidas na sua própria instituição.

Exemplo: se sou aluno da UFRJ, não posso visualizar caronas ofertadas por alunos da UNIRIO.

Para isso, a listagem de caronas que vem da API deve levar em consideração a instituição do usuário que fez a requisição e retornar apenas as caronas da instituição a que pertence.

Detalhes

Cada usuário já é associado a uma instituição e cada carona também. É necessário adaptar a rota de listar/pesquisar caronas (RideController::index) para filtrar apenas as caronas que pertencem a motoristas da mesma instituição do usuário atual.

Extras

A rota de requestJoin (por onde pode solicitar participar numa carona) também deve impedir que um usuário de uma instituição solicite participar de uma carona de outra instituição.

Criar uma rota única na API (ex: /user/{id}/rides) para carregar as caronas do usuário, separando por pendentes, ativas e ofertadas.

Já é possível obter as caronas de cada uma dessas categorias utilizando métodos do próprio User (activeRides, offeredRides, pendingRides), bastando apenas consolidar uma rota que retorna todas elas.

Como as caronas dessa tela serão exibidas em uma única tela "Minhas" no aplicativo, as caronas que pertencem a mais de uma dessas categorias não deve vir mais de uma vez, aparecendo apenas na categoria mais prioritária.

Prioridade das categorias:
Pendente > Ativa > Ofertada

Atualmente utilizamos o framework Laravel na versão 5.4. A versão 5.5, que foi lançada este ano, traz diversas melhorias e correções.

O próprio site oficial do Laravel possui um guia de atualização, e estima que o trabalho é de aproximadamente 1 hora.

https://laravel.com/docs/5.5/upgrade

Are there plans to introduce other languages?
many thanks

Atualmente temos um único arquivo ModelFactory que possui as factories pra todos os modelos do app:

https://github.com/caronae/caronae-backend/blob/master/database/factories/ModelFactory.php

O padrão do Laravel sugere que deveríamos ter um arquivo pra cada factory, então deveríamos criar novos arquivos como UserFactory, RideFactory etc. ao invés de um só com todos.

https://github.com/laravel/laravel/blob/master/database/factories/UserFactory.php

Atualmente estamos na versão 5.7 do Laravel, mas podemos atualizar pra versão 5.8 seguindo o guia de upgrade.

Dando uma breve olhada, o ponto de maior atenção no upgrade seria o Cache TTL In Seconds nas classes onde usamos cache.

Também seria bom ver os diffs dessa versão no próprio GitHub pra manter arquivos de configuração e outras coisas nos padrões mais recentes.

A API deve impedir que o usuário ofereça mais de uma carona na mesma data.

Foi implementada uma rota (em RideController::validateDuplicate) para a verificação prévia se uma carona é duplicada ou muito parecida com outra já criada.

No entanto, a API não está verificando esse estado no momento da criação, o que torna possível para os clientes ainda criarem caronas duplicadas e não seguir a verificação prévia.

A API deveria retornar um estado de erro para o caso em que a nova carona é considerada duplicada (duplicated).

No caso de a carona ser considerada apenas possible_duplicate, o servidor deverá permitir que seja criada mesmo assim.