Nós implementamos uma melhoria de performance no fluxo de pagamento de projetos de assinatura para resolver um problema que estava afetando um número grande de assinantes, que reclamavam que suas recompensas selecionadas não eram registradas. Além de resolver o problema, nós também fizemos uma limpeza retro-ativa em nossa base de dados para atribuir recompensas à assinaturas que estavam sem recompensa selecionada.
Projetos com o prazo de captação encerrado, mas que ainda se encontram no estado 'Aguardando boletos', agora voltaram a ser exibidos na busca do Catarse, com o filtro 'Finalizados' selecionado.
Agora é possível encontrar projetos no Catarse buscando pela sua localização. Tem duas formas de fazer isso:
Você pode clicar na cidade do projeto, que aparece nos detalhes do card do projeto e também na página da campanha:
Ou você pode também procurar por qualquer cidade (ou estado) que você queira direto pela página de busca de projetos do Catarse:
Como o Brasil é muito grande e não existem projetos em cada uma das mais de 5000 cidades brasileira, os resultados da busca mostram não só os projetos encontrados especificamente na cidade que você procurou, como também em outras cidades do mesmo Estado:
Agora os Projetos que Amamos tem um selinho na página da campanha. Ao clicar ali, você é direcionada diretamente para a área de busca do Catarse com o filtro 'Projetos que Amamos'. Se quiser saber mais, dá uma lida nesse post do Blog.
Agora os relatórios para download contendo dados de pagamentos (tanto projetos de Assinatura quanto projetos Pontuais) informam o custo do serviço de anti-fraude. Esse é um serviço de terceiros que utilizamos para garantir que as transações feitas no Catarse são seguras, protegendo a todos contra fraudes de pagamentos.
Esse custo antigamente estava incluído no pacote de serviços prestados pelo meio de pagamento que utilizamos (logo o custo de anti-fraude vinha incluído no 'Serviço do Meio de Pagamento' nos relatórios para download). Porém recentemente fizemos algumas alterações na forma como fazemos as análises de anti-fraude, passando a usar um outro serviço independente do meio de pagamento. Portanto, optamos por refletir nossa nova estrutura de custos também nos relatórios para download (sempre com a premissa básica de sermos transparente com os realizadores de projetos).
Nós estávamos com um problema no envio desses emails. Era um problema que não afetava a todos os usuários e sua ocorrência era um pouco aleatória (às vezes funcionava, às vezes deixava de funcionar, independente do projeto relacionado). Pedimos desculpas pelo problema, mas ele já foi resolvido, os emails estão sendo enviados regularmente (e estamos atentos para evitar que ocorra novamente).
Quando um projeto opta por não oferecer recompensas, a coluna que geralmente mostra as recompensas disponíveis é trocada por uma coluna com valores de apoios sugeridos. Fizemos uma pequena mudança no tamanho do texto (tanto em desktop quanto em mobile) para dar mais destaque à essa coluna.
A aba com valores de apoio sugeridos (em projetos que optaram por não oferecer recompensas) não estava sendo exibida quando a página de campanha era visualizada em celulares. Agora está tudo certinho.
Agora, ao criar um projeto na Catarse Solidária, não só enviamos um email confirmando a participação no nosso programa especial para o combate ao Covid-19 - onde as pessoas podem escolher quanto querem pagar pelos serviços do Catarse - como também indicamos no painel de controle do rascunho algumas informações essenciais sobre a Catarse Solidária.
Uma imagem vale mais que mil palavras. Pensando nisso que hoje anunciamos uma funcionalidade leve, mas que já é uma das mais pedidas pela nossa comunidade há um tempão: a possibilidade de atribuir uma imagem à uma recompensa no Catarse.
Você pode ver pela imagem acima que é super simples adicionar imagens às suas recompensas a partir do painel de controle do projeto. É possível pode adicionar, deletar e trocar as imagens a qualquer momento de sua campanha.
✨ Deixa de exibir email do destinatário em mensagens enviadas pela plataforma. Para preservar a privacidade de nossos usuários, a partir de agora as mensagens enviadas pela plataforma não exibem mais o email do destinatário. Com isso, a pessoa que enviar uma mensagem pela plataforma receberá somente um recibo do envio, onde constará o conteúdo da mensagem enviada e o nome público do destinatário, porém não terá mais o email do destinatário (considerado informação confidencial). Exemplo de um recibo de mensagem abaixo:
✨ Remove o nome do realizador na aba pública de Novidades, quando não existe novidade ainda enviada.
✨ Exibe uma saudação genérica (Olá!) no email enviado à pessoas que não possuem um nome público registrado no Catarse
✨ [Trabalho em progresso - não foi publicado no changelog] Altera os dados da nova estrutura de dados fiscais, Cria integração com o Enotas para geração de notas fiscais, Cria rotina para gerar os dados fiscais de pagamentos feitos após a geração dos dados fiscais. São tarefas implementadas no back-end do Catarse, mas que ainda não estão funcionando (ou seja, nossas Notas Fiscais ainda estão sendo emitidas da forma que sempre foram emitidas). Próximo passo será validar o funcionamento real dessas tarefas e partir para a última fase do projeto, que será "virar a chave" para que a gente possa começar a usar o Enotas para emissão de Notas Fiscais.
🐞 Remove validação de prazo para projetos Flex. Os projetos Flex no Catarse já não precisam se limitar a estarem no ar por um período máximo de 365 dias. Porém, caso um realizador com projeto FLEX há mais de 365 dias no ar tentasse definir um prazo para sua campanha, nós ainda estávamos exibindo uma mensagem de erro no momento da definição do prazo (considerando ainda a regra antiga). O que essa correção fez foi remover essa validação no momento da definição do prazo e também ajustar o texto que informa sobre o limite de prazo do Flex nesse, nesse e nesse artigo da base de conhecimento. Além também de corrigir essa informação sobre prazo ilimitado em Flex na aba Financiamento no painel de controle de projetos:
🔧 Coloca idempotencia no repasse realizado através do Pagarme para evitar erros de transferências duplicadas
💎 Atualiza as dependências do back-end e o Ruby para a versão 3.0.1
Temos alguns casos em que um boleto é pago após o vencimento, e temos casos em que as pessoas pagam um boleto parcialmente (não pagam todo o valor dele). Essas coisas, apesar de não serem frequentes, quando acontecem necessitam de um esforço do time do Catarse pra resolver. Ainda não está claro se essa configuração que adicionamos (oferecida pelo meio de pagamento que utilizamos para processar os boletos) impede os apps e atendentes de efetuarem o pagamento desses boletos nas situações indesejadas ou apenas adiciona instruções na folha do boleto. Entretanto, como o esforço para adicionar essa configuração era mínimo, estamos entregando essa atividade hoje e iremos monitorar se esse problema irá persistir.
O Ruby on Rails (tecnologia utilizada no desenvolvimento do site do Catarse) que estávamos usando ainda estava na versão 4.2. Era uma versão lançada em 2016, que já não recebia nenhuma atualização (a não ser quando eram encontradas falhas de segurança).
As gems (bibliotecas) que utilizávamos, muitas já haviam sido abandonadas há alguns anos, algumas outras só poderiam ser atualizadas se tivéssemos uma versão do Rails mais atual, e algumas gems novas só poderiam ser adicionadas ao projeto se estivéssemos com uma versão recente do Rails.
Ou seja, estávamos rodando o Catarse num motor antigo, quando deveríamos estar rodando em um motor atual, novinho em folha. A nova versão do Rails que estamos agora utilizando trouxe algumas melhorias e facilidades no uso do framework.
Com isso, estamos prontos para seguir em uma série de melhorias e refatorações em 2021, com a garantia que estamos evoluindo o código do Catarse em uma máquina atualizada, sem códigos obsoletos.
Entregamos duas funcionalidades que buscam melhorar a experiência e a segurança do Catarse:
* ✨ Bloquear cadastro de email com referencia a catarse
* Corrigir regex de validação do e-mail
Essa é uma entrega bem técnica, de bastidores, mas que tem como objetivo dar mais agilidade para o nosso time de produto na hora de entregar soluções, melhorias e novas funcionalidades para a comunidade de usuárias e usuários do Catarse. A explicação técnica é que estamos movendo o catarse.js para dentro do catarse, simplificado o processo de deploy, pois não será mais necessário fazer commits do build para o repositório do catarse.js. Ao realizar um npm install no Catarse, o build do catarse.js será realizado.
Segundo a legislação, quando o tomador do serviço (no caso, o Realizador de Projeto no Catarse) for Pessoa Jurídica e o valor devido de Imposto de Renda for superior a R$10,00, o Realizador é responsável por recolher o Imposto de Renda. Para que isso ocorra, o Catarse precisa transferir para o saldo do Realizador, além do montante arrecadado no projeto, o valor referente ao Imposto de Renda.
Com a melhoria que implementamos, esse processo agora é feito automaticamente para projetos pontuais (a solução para projetos de Assinatura virá em breve), e sempre que um realizador que tenha um perfil de Pessoa Jurídica no Catarse receber recursos em seu saldo, será também transferido um valor do Imposto de Renda. Para isso, criamos um evento no Saldo deixando claro do que se trata o valor e também incluímos uma mensagem na aba Saldo explicando a questão. Além disso, essa informação também constará nos Documentos Fiscais, disponíveis aos realizadores em seu painel de controle de projetos.
Existia uma falha na edição de projetos do Catarse que permitia que usuários alterassem atributos na página de projeto que deveriam ser restritos à edição de administradores da plataforma. Kudos (mais uma vez!) para o Paulo, estudante de TI e usuário do Catarse que identificou esse problema e nos avisou de prontidão 💜
Estávamos com umas inconsistências nos parâmetros ?ref e UTM dos links das páginas de projeto gerados pelos botões de compartilhar (na página de projeto e na página de agradecimento). Essa inconsistência levava aos realizadores a terem informações incorretas sobre a origem de seus apoios.
• Tínhamos um problema bem raro onde os pagamentos feitos a projetos de Assinaturas cujos realizadores tinham nomes com mais de 100 caracteres falhavam. Já tínhamos consertado esse problema em projetos pontuais e agora consertamos também para projetos de Assinatura.
Os custos de anti-fraude agora, além de serem informados nos relatórios para download, também são informados nos documentos fiscais distribuídos aos realizadores. Portanto, o Informe de Rendimento e as Notas de Débito passam a ter uma linha a mais na descrição de custos, referente ao anti-fraude (um sistema de terceiros que utilizamos para garantir que os pagamentos em nossa plataforma são seguros).
• Alguns projetos estavam com um problema onde as quantidades de recompensas disponíveis e a quantidade de apoios feitosem determinadas recompensas, informada na página da campanha estavam desatualizadas. Fizemos um ajuste para que a informação exibida no cards de recompensa condiza com o número correto de recompensas disponíveis.
• Alguns cards de projetos de Assinatura estavam exibindo valores diferentes dos valores informados no placar do projeto, dentro da página de campanha. Fizemos um ajuste para reduzir esse problema.
• Alguns realizadores inserem imagens nas suas descrições de projetos com o formato base64, que é muito pesado e pode comprometer a performance do carregamento da página. Fizemos um ajuste para evitar alguns casos em que isso aconteça.
• Ao criar projetos, não estava sendo possível pesquisar por algumas cidades no campo de busca de cidades, dentro do painel de controle do projeto. Fizemos um ajuste para remover esse problema.
Quando uma recompensa não possui nenhum apoio ou assinatura feita, os realizadores deveriam poder deletá-la. Porém estávamos com um problema que estava impedindo esse processo de ser feito. Agora já está corrigido.
O placar que mostra as metas de projetos de assinatura estava com um problema e tinha deixado de funcionar por alguns dias. Fizemos uma correção e está tudo normal novamente (como você pode ver abaixo, no placar de metas do projeto O Nosso Verão:
Semana passada recebemos uma mensagem de um apoiador dizendo que tinha recebido um email com um boleto de um projeto que tinha finalizado em 2015 (!) Nós investigamos e tinha um problema bem raro que fazia com que poucas pessoas recebessem emails com boletos de projetos já finalizados (os boletos eram inválidos e não tinha como pagá-los). Fizemos uma correção e esse problema agora foi resolvido.
