Faça outro link do discord

Apos conversa com TucanoWeb e Larissapissurno, no SOS-RS/frontend#254

Descrição

Possívelmente pode acarretar na parte de cadastro de itens de aparecer duplicado, conforme imagem abaixo:

Não me deixa cadastrar água, mas aparecem água, agua, água sanitária 2x...

Possivel Solução

Localizar os registros duplicados, considerando os items registrados, não as necessidades registradas. Acredito que a normalização do retorno da consulta utilizando lower e translate resolva a questão;
Alterar, em massa, o ID do supply que está sendo referenciado na tabela de supplies (itens necessários), considerando o registro que será persistido ;
Deletar os registros dos supplies registrados em duplicidade.

Objetivo:

Implementar uma funcionalidade que permita o cadastro de pontos de coleta de doações utilizando geolocalização, facilitando o acesso e a organização das doações.

Descrição:

A nova funcionalidade visa adicionar a capacidade de registrar pontos de coleta de doações no sistema, utilizando a geolocalização para fornecer informações precisas sobre a localização desses pontos. Isso permitirá aos usuários encontrar pontos de coleta próximos de forma eficiente, utilizando mapas interativos.

Requisitos:

Cadastro de Pontos de Coleta:

• Permitir aos usuários cadastrar novos pontos de coleta.
• Campos obrigatórios: Nome do Ponto de Coleta, Endereço, Itens Aceitos, Horário de Funcionamento.
• Campo de geolocalização (latitude e longitude) que pode ser preenchido automaticamente ao selecionar um ponto no mapa ou manualmente.

Mapeamento Interativo:

• Integrar um mapa interativo na interface de usuário para exibir os pontos de coleta cadastrados.
• Permitir aos usuários visualizar detalhes dos pontos de coleta ao clicar nos ícones no mapa.

Pesquisa e Filtro:

• Implementar uma funcionalidade de pesquisa para encontrar pontos de coleta por proximidade, tipo de item aceito, ou horário de funcionamento.
• Filtros para refinar a busca com base em critérios específicos (tipos de itens aceitos, distância).

Integração com Serviços de Geolocalização:

• Utilizar APIs de geolocalização (Google Maps API, OpenStreetMap, nodeGeocoder) para converter endereços em coordenadas geográficas e vice-versa.

Notificações e Atualizações:

• Notificar os administradores quando novos pontos de coleta forem cadastrados ou quando houver atualizações nos pontos existentes.
• Permitir que os usuários reportem problemas ou alterações necessárias nos pontos de coleta cadastrados.

PS: É importante uma discussão sobre níveis de acesso e permissões, afim de aumentar assertividade e precisão das informações informadas.

É um erro de escrita, ou no deploy é usado Mongo de fato?

Resumo
Remover referências a "abrigos para mulheres e crianças" nos títulos dos abrigos por motivos de privacidade e conformidade com a LGPD (Lei Geral de Proteção de Dados).

Descrição
Devido a preocupações com a privacidade e para atender à LGPD e a segurança dessas pessoas, é essencial que não especifiquemos ou impliquemos que determinados abrigos sejam exclusivamente para mulheres e/ou crianças. Isso deve ser refletido nos títulos e descrições dos abrigos listados em todas as interfaces públicas.

Critérios de Aceitação

• Modificação de Títulos: Garantir que o título de nenhum abrigo contenha a frase "abrigo exclusivo para mulheres e crianças" ou quaisquer frases semelhantes que possam indicar que o abrigo é especificamente para mulheres e crianças.
• Privacidade de Dados: Nenhum dado público (incluindo listas, descrições ou metadados) deve indicar explicitamente ou implicar que os abrigos são especificamente para mulheres e crianças.
• Funcionalidade de Pesquisa: Modificar a funcionalidade de pesquisa para que não permita que os usuários procurem por abrigos especificamente para mulheres e crianças.
• Verificação: Implementar um script ou processo de verificação manual para verificar regularmente que nenhuma descrição de abrigo viole esses critérios.

Impacto no Usuário
Esta mudança visa proteger a privacidade dos indivíduos que utilizam nossos serviços e garantir nossa conformidade com as leis de privacidade.

Summary
Remove references to "shelters for women and children" in shelter titles for privacy and compliance with LGPD (General Data Protection Law).

Description
For privacy concerns and to adhere to the LGPD, it is essential that we no longer specify or imply that certain shelters are exclusively for women and children. This must be reflected in the titles and descriptions of the shelters listed on all public-facing interfaces.

Acceptance Criteria

• Title Modification: Ensure that no shelter's title contains the phrase "shelter exclusively for women and children" or any similar phrases that could indicate the shelter is specifically for women and children.
• Data Privacy: No public data (including lists, descriptions, or metadata) should explicitly state or imply that shelters are specifically for women and children.
• Search Functionality: Modify the search functionality so that it does not allow users to search for shelters specifically for women and children.
• Verification: Implement a script or manual verification process to regularly check that no shelter descriptions violate these criteria.

User Impact
This change is intended to protect the privacy of the individuals using our services and ensure our compliance with privacy laws.

Precisamos garantir que itens com mais de 48 horas em "precisa - não urgente" ou "disponível para doação" sejam apagados automaticamente para manter a base de dados limpa e atualizada.

Problema

User story: Eu sou um administrador. Eu estou tentando manter a lista de necessidades atualizada. Mas muitos itens permanecem na lista sem necessidade após 48 horas, o que polui a base de dados e dificulta a visualização das necessidades reais.

É crucial que o sistema automaticamente apague itens desnecessários após 48 horas, garantindo que a base de dados seja limpa e precisa.

Critérios para aceitação

• Itens em "precisa - não urgente" ou "disponível para doação" por mais de 48 horas devem ser automaticamente apagados.
• Um hook no Node.js deve ser implementado para validar o estado dos itens a cada consulta.
• O sistema deve registrar a remoção no histórico do sistema para fins de auditoria.

Salve meu querido! Existe alguma possibilidade de você abrir uma API pra consultar os abrigos pra que outras aplicações consumam?

Vejo que está tendo multiplas fontes de dados e esse projeto poderia ser a principal entre todas. Facilitaria muito...

De acordo com os benchmarks do pnpm o build da aplicação seria mais rápido se o usássemos. Acredito que com isso o deploy da aplicação seria mais rápido.

Opa,
Pessoal quero começar ajudar, mas acho uma boa nos criar um canal no discord para trocar ideias, e organizar de uma melhor forma

Fala, pessoal.

Sou do front, e fui rodar o back localmente com Docker.

Toda a parte de subir o container deu certo, mas as atuais instruções pra carregar o dump do database não funcionam.

Notei que tem alguns PRs abertos que tratam do assunto: #91, #84, #75, #66, #64

Pra mim, os comandos do #84 funcionaram de primeira.

PS.: abri issue pois não vi nenhuma issue aberta ou fechada em relação a isso

SOS-RS/frontend#315

Amigos de minas gerais que estão mandando mantimentos tem a necessidade de saber a necessidade geral de itens mais necessários.

Por exemplo

1 Fralda tamanho M
2 Água galão 5 litros
3 chinelos tamanho 37/38

Mas isso em endpoint publico e de forma direta para que eles saiba direcionar a coleta!

TL;DR

Na edição do abrigo, atualmente é possível atualizar o número de pessoas abrigadas e se o abrigo aceita pets, porém não é possível cadastrar quantas vagas para pets existem.

Issue no frontend: SOS-RS/frontend#259

Problema

Requisitos

Tela de edição completa para usuário autenticado

Esta implementação não deve ser feita na tela de edição disponível para qualquer usuário. Apenas na tela de edição para usuário autenticado.

• Mostrar switch para “Aceita pets”
• Ao ligar o switch mostrar os campos:
  • Capacidade de pets do abrigo
  • Quantidade de pets abrigados
• Ao tocar em “Atualizar” salvar no BD os dados inputados pele pessoa usuária.

Página de detalhe

É possível fazer a paginação da listagem de abrigos?

Hoje temos um botão ao final da página para carregar mais abrigos

Seria bem útil ter à mão alguns dados de teste para popular a banco de dados.

Alguém que tenha poderia compartilhar?

Problema

Quando ocorre um erro de validação do Zod, a API está retornando uma mensagem ZodError sem detalhes do erro que aconteceu.

Por exemplo, o schema ShelterSchema tem restrição para que o nome do abrigo seja string

Porém quando tento fazer uma requisição para editar o abrigo, por exemplo, me retorna apenas a mensagem ZodError

Proposta de solução

Elaborar uma estrutura para retornar os errors de validação na API para que ao tentar fazer uma requisição inválida, seja retornada os erros de validação.

Acredito que também seja interessante retornar essas validação com o protocolo 422 (Unprocessable Entity)

Oi pessoal

Vi o repositorio com a seguinte mensagem

"Auxílio RS: Projetos de Resposta a Emergências por Chuvas e Alagamentos"

Tem como terem uma api que retorna o número de doações e afins?

O motivo é simples: estava pensando em gerar um gráfico em chart-js sobre isso. Isso é interessante para quem está ajudando direcionar melhor a ajuda.

olha esse site: https://stokebreakup.github.io/dashboard.github.io/

obs: não estou criticando ninguém, apenas estou propondo que tenhamos dados sobre tudo o que é possível, e então direcionar nossa ajuda.

exemplo:

select count(nome) from Doacoes 

-> isso vai retornar a quantidade de doações, não sei muito de sql para fazer as queries, mas se souberem vai ajudar.

Precisamos permitir que o usuário selecione simultaneamente os filtros "Precisa" e "Necessita Urgente" ao buscar itens, para que possam visualizar todas as necessidades de forma combinada.

Problema

User story: Eu sou um voluntário. Eu estou tentando encontrar rapidamente itens que são necessários e urgentes. Mas o sistema atual não permite filtrar ambos simultaneamente, o que dificulta minha capacidade de identificar e priorizar os itens mais críticos.

É essencial que o sistema permita a seleção de múltiplos filtros para fornecer uma visão mais completa das necessidades, melhorando a eficiência do processo de identificação e priorização dos itens necessários.

Critérios para aceitação

• O sistema deve permitir a seleção simultânea dos filtros "Precisa" e "Necessita Urgente".
• A interface de usuário deve oferecer multi seleção ou opções que possibilitem a combinação desses filtros.
• O sistema deve manter a capacidade de filtrar por cada critério individualmente, além da combinação dos dois.
• O sistema deve fornecer uma indicação visual clara de quais filtros estão atualmente aplicados.

História de Usuário: Como administrador do sistema, quero que cada atualização em um item seja registrada em uma tabela específica de logs, contendo detalhes como item, abrigo, prioridade anterior e atual, data e hora da atualização, IP do solicitante, e se autenticado, o id do usuário para manter um histórico detalhado das mudanças para auditoria e monitoramento.

Critérios de Aceitação:

• Criar uma nova tabela chamada item_updates_log.
• Sempre que um item for atualizado, inserir um novo registro nesta tabela contendo: nome do item, nome do abrigo, prioridade anterior, prioridade atual, data e hora da atualização, IP do usuário e ID de usuário que fez a atualização.
• Assegurar que cada log capture todas as informações necessárias sem falhas.
• Os registros na tabela de logs devem ser imutáveis para manter a integridade dos dados de auditoria.

Definition of Done (DoD):

• Código desenvolvido seguindo as melhores práticas de segurança e desempenho conforme os padrões da equipe.
• Funcionalidade completamente testada em todos os ambientes aplicáveis, assegurando que os logs são gerados e armazenados corretamente.
• Revisão e aprovação.

Precisamos garantir que itens de necessidade marcados como "precisa - urgente" sejam rebaixados para "precisa - não urgente" após 4 horas, para que a urgência dos itens seja atualizada automaticamente.

Problema

User story: Eu sou um administrador. Eu estou tentando manter a prioridade correta dos itens de necessidade. Mas itens que são adicionados como "precisa - urgente" permanecem assim por muito tempo, mesmo quando sua urgência já passou, o que dificulta a gestão correta das prioridades.

É essencial que o sistema automaticamente atualize a urgência dos itens, garantindo que os administradores possam ver uma lista precisa e atualizada das necessidades mais urgentes.

Critérios para aceitação

• Itens marcados como "precisa - urgente" por mais de 4 horas devem ser automaticamente rebaixados para "precisa - não urgente".
• Um hook no Node.js deve ser implementado para validar o estado dos itens a cada consulta.
• O sistema deve registrar uma atualização no histórico do item indicando a mudança de estado.

Os organizadores do repositório poderiam criar um server do Discord para melhorar a comunicação do projeto como um todo. Somente pelas issues/ pull request é ineficiente

Precisamos implementar uma funcionalidade que crie uma senha aleatória e envie para o celular do usuário (via SMS ou WhatsApp) no momento em que o usuário é criado, garantindo uma forma segura e conveniente de acessar o sistema.

Problema

User story: Eu sou um administrador. Eu estou criando novos usuários no sistema. Mas atualmente, não há uma forma automatizada de fornecer as credenciais iniciais de login, o que complica a comunicação e a segurança no momento da criação de novos usuários.

É essencial que o sistema crie uma senha aleatória no momento da criação do usuário e envie essa senha para o celular do usuário, garantindo segurança e conveniência no acesso inicial ao sistema.

Critérios para aceitação

• O sistema deve gerar uma senha aleatória no momento da criação do usuário.
• A senha deve ser enviada para o celular do usuário via SMS ou WhatsApp.
• O sistema deve utilizar um serviço de envio de mensagens confiável (por exemplo, Twilio, Nexmo, etc).
• A senha gerada deve ser segura, seguindo padrões de complexidade (letras maiúsculas e minúsculas, números e caracteres especiais).
• Usar funções de geração de números aleatórios seguras.

Critério de sucesso
Os novos usuários recebem uma senha aleatória no momento da criação, via SMS ou WhatsApp, garantindo uma forma segura e conveniente de acessar o sistema.

Olá a todos!
Seriam possíveis criarem rotas para consumo de informações para gerar métricas e também monitoramento dos dados dos abrigos e suas necessidades no PowerBI? Tenho mais experiência em C# e Dashboards. Posso publicá-lo e atualizar diaramente ou semanalmente os dados.

Caso também tenha um backup sempre do dia antes (d-1) seria possível gerar e atualizar os dados para que todos possam ver e visualizar as informações. Num aspecto geral, seria legal uma relação entre os abrigos (shelters) e suas necessidades... quantificar em percentis os itens do abrigo... (podemos discutir a escala) bem como também a quantidade de capacidade máxima do abrigo e saber o número de itens ou criarmos uma quantificação... enfim.

TL;DR

Por motivos de segurança (e da LGPD), precisamos retirar a descrição “abrigo para mulheres e crianças” do título dos abrigos listados.

Critérios de aceitação

We will accept when the shelter's list don't have any titles involving women or children. There are no texts public showing women or children.

There will be no public data specifying shelters for women and children.

Users shouldn't be able to search woman and children.

1. Retirar a informação “Abrigo exclusivo mulheres de crianças” do título de qualquer abrigo que tenha essa descrição

Item do frontend: SOS-RS/frontend#255

Gostei muito da iniciativa, estou tentando criar um filtro por "Tem Pix" pois quem é de longe é um filtro interessante.

Ajudei a divulgar o projeto no meu canal

https://www.youtube.com/watch?v=5Et_MhbT86Q

Alguns civis estão recebendo doações via pix e documentando o que estão fazendo nas redes sociais para ajudar os outros desabrigados com o dinheiro arrecadado, o que torna a doação mais direta e confiável, acredito que adicionar esses links na forma de uma lista dentro do projeto seria de grande valor para essas pessoas.

Primeiramente, parabéns pelo projeto!!

Ideia:
Expandir o sistema para o cadastro de transportes, de forma que pessoas com carro, caminhonete, caminhão, etc que queiram coletar itens para doação em uma cidade e levar a um abrigo específico possam ajudar. Creio que isso pode elevar o número de contribuições, já que hoje muitos que estão distantes dos abrigos fisicamente podem ficar um pouco limitados a ajudar.

Prática:
Pensei em criar uma entidade transporte que será linkada a um usuário. Este irá preencher as informações de seu transporte (ex: tipo de veículo, placa) e criar as viagens.
O usuário irá preencher em cada viagem a cidade de partida e linkar ao abrigo de destino, além de inserir data e hora de saída, link para um chat no whatsapp para alinhar detalhes, etc.
Para a pessoa que quiser doar e estiver longe de algum abrigo, terá uma página onde ela poderá ver as viagens agendadas e filtrá-las pela cidade de partida. Em seguida, ao escolher e acessar uma viagem específica, ela poderá ver os dados de contato e também o abrigo de destino. Desta forma, a pessoa poderá ver o que o abrigo precisa e então doar o que for mais urgente.

Espero que a ideia seja útil de alguma forma! Já pretendo ir desenvolvendo, pois, caso achem uma boa, já estará adiantado.
Espero a opinião de vocês!!

Esse problema foi citado em issues no front end, e acredito que parte da solução seja no backend.

Issue frontend #175
Issue frontend #167

O que penso como uma possível solução é usar um semantic search para o cadastro dos itens, ele evitaria o cadastro de Água e Agua, por exemplo. Para os que já estão cadastrados, caberia a criação e execução de um script para varrer o banco, identificar semelhanças e unificar os inputs.

O que conheço de recurso para isso demandaria um serviço a mais na infra, então peço que participem do debate com sugestões para resolver o problema, principalmente se por questões de infra não for viável o uso do Sonic ou Typesense por exemplo.

Obviamente a solução mais simples e sugerida nas outras issues citadas, seria criar uma página para curadoria dos itens, porém demandaria um trabalho manual e atuação constate de alguém, o que talvez não seja eficiente.

Precisamos garantir que a página inicial do site exiba o contato dos abrigos apenas se for autorizado, utilizando uma flag no registro do abrigo para controlar essa exibição.

Problema
User story: Eu sou um usuário do sistema. Eu estou tentando entrar em contato com um abrigo. Mas nem todos os abrigos têm o contato exibido, e não sei quais estão autorizados a mostrar essas informações, o que dificulta minha comunicação.

É essencial que o sistema exiba o contato dos abrigos apenas quando autorizado, garantindo a privacidade das informações e facilitando a comunicação quando permitida.

Critérios para aceitação

• Cada abrigo deve ter uma flag que indica se a exibição do contato é autorizada.
• A interface de usuário deve verificar essa flag antes de exibir o contato do abrigo.
• Apenas os contatos dos abrigos com a flag de autorização ativada devem ser exibidos.
• Garantir que a alteração não afete a exibição de outros detalhes dos abrigos.
• Adicionar o campo no POST da API

Imagem está no PR. Também foi feito a organização das linhas e espaços.

Hoje, no banco, nossas tabelas estão com as colunas created_at e updated_at como varchar.
Seria ideal transformarmos em datetime ou timestamp (a avaliar melhor opcão pro prisma) a fim de poder fazer consultas com lógica em volta desses campos.
É preciso também pensar na conversão desses dados.

Saudações. Primeiramente parabéns pelo trabalho e dedicação. Tive a ideia de implementar uma lista de abrigados em cada abrigo, que facilitaria o reencontro e contato com suas famílias. Vi que criaram alguns canais no instagram, mas não sei se a plataforma facilita a busca.

Então, deixo aqui a sugestão caso queiram incluir no roadmap de vocês.

• Cadastrar abrigado (Nome obrigatório. CPF, Data de Nascimento/Idade opcionais [pra facilitar o cadastro]).
• Editar abrigado.
• Importar lista de abrigados (CSV).

Não encontrei sugestoes proximas, pessoa desculpas se for repetido.

A interface permite que abrigos informem doações faltantes e em alguns casos, por uma questão de logística, abrigos tendem a ter mais itens do que outros. A idéia é criar uma interface de notificação entre abrigos para que estes possam realizar troca de itens faltantes e que sobram, melhorando a logistica interna.

User Story: Como um representante de abrigo, quero receber notificações quando um abrigo tiver em sobra algum item que está em falta em minha representação, podendo entrar em contato e viabilizar a logística do espaço.

Regras:

• A notificação deverá ser enviada para o abrigo através do email de contato cadastrado (possivel analisar sms o envia de acordo com a disponibilidade técnica da funcionalidade)
• A notificação deverá ser enviada apenas uma vez, alertando sobre a disponibilidade
• Toda notificação deverá informar sobre a alta variabilidade das informações que podem nao estar disponíveis no momento do contato.
• Deve ser uma opção DO ABRIGO COM MATERIAIS DISPONIVEIS informar sobre o excesso de determinados itens.
• A logistica entre abrigos a principio é determinada ente estes. Podendo ser uma doação e/ou troca caso seja viável.
• A notificação deverá ser enviada uma vez apenas por solicitação do abrigo com excesso de itens faltantes, podendo ser repetida a todos os abrigos de acordo com a demanda.

Obs: Requer implementação front-end . Esta issue será replicada em Front-end issues.

Problema

Atualmente qualquer usuário pode editar se um abrigo é ou não PetFriendly.

Solução

Proponho alterar esta informação para que apenas os admins de um abrigo possam editar esta informação.

Olá pessoal, espero que estejam bem e seguros.

Durante a revisão do código, observei que a utilização o Fastify com o protocolo HTTP/1. Dada a natureza da aplicação, que pode ser utilizada em locais com alta concentração de usuários e infraestrutura possivelmente danificada, acredito que migrar para o HTTP/2 traria benefícios significativos.

Justificativa Técnica:
Os benefícios do HTTP/2 são numerosos e poderiam melhorar significativamente o desempenho da aplicação. Primeiramente, a multiplexação de conexões permite que múltiplas requisições sejam enviadas em uma única conexão TCP, o que reduz a latência e melhora a eficiência do uso da rede. Além disso, o HTTP/2 utiliza compressão de cabeçalhos HPACK, reduzindo o overhead das requisições HTTP, especialmente em conexões com muitos cabeçalhos repetitivos. Outra vantagem é a priorização de requisições, que permite otimizar o carregamento de recursos críticos. Por fim, o recurso de push de servidor possibilita que o servidor envie recursos proativamente ao cliente, diminuindo o tempo de carregamento de páginas.

Risco e Mitigação:
A implementação dessa mudança antes de realizar qualquer alteração no código principal é crucial para evitar a interrupção do workflow de outras pessoas. A transição para HTTP/2, se feita sem o devido planejamento, pode introduzir inconsistências temporárias ou até falhas em ambientes onde o protocolo não é totalmente suportado.

Estou à disposição para liderar e implementar essa alteração. Acredito que essa melhoria poderá trazer um desempenho mais robusto e eficiente para a aplicação, beneficiando todos os usuários.

Aguardo o feedback de vocês para podermos avançar com esta proposta.

Obrigado!

Seria uma boa colocar uma licença de software livre. Recomendo MIT, ou Apache2 em segundo lugar.

Problema

Ao instalar os pacotes usando a versão 20.3.1 do node, me deparei com os seguintes erros:

Sugestão de solução

Adicionar ao package.json qual engine está sendo utilizada na aplicação, como ilustrado na imagem abaixo.

Atualmente o package da aplicação não tem essa configuração.

Sugestão adicional

Criar um arquivo .nvmrc contendo a versão utilizada do node no projeto (ex. v18.20.2), assim o seguinte comando pode ser utilizado, caso o dev use o nvm, para garantir que todos estejam usando a mesma versão do nodejs.

nvm use

Ola
Devido à grande quantidade de abrigos humanitários inscritos fica impossível chegar ao fim dos 568 para consulta. E para piorar volta para o começo quando se quer detalhar o abrigo inscrito.

Pessoal, sei que a intenção do app é ser rápido e simples para todos usarem. Mas todos poderem atualizar as infos dos abrigos acredito ser perigoso.

O que acha de fazermos um mini cadastro e a edição e criação de abrigos ser apenas uma solicitação, analisada e armazenada no Postgres e posteriormente aprovada por alguém.

Não da pra confiar em deixar totalmente aberto, infelizmente mesmo nessas horas pessoas agem de má fé.

Galera,
O que acham de ordenar o resultado da pesquisa da página inicial pelos abrigos que possuem os dados mais atualizados? Acredito que assim poderíamos melhorar a assertividade. Faz sentido?