- cancelar somente esta
- cancelar todas
fora do MVP cancelar a partir desta. Se usuário quiser este comportamento ele deve editar a repetição
[ | |
{ | |
titulo: 'Receitas', codigo: '1', tipo: 3, | |
lista: [ | |
{ titulo: 'Cotas condominiais', codigo: '1.1', tipo: 3, lista: [ | |
{ titulo: 'Taxas de Condomínio', codigo: '1.1.1', plano_conta_automatico: { cobrancas: :debitos }, tipo: 3, lista: [] }, | |
{ titulo: 'Taxas de utilização de Área comum', codigo: '1.1.2', tipo: 3, lista: [] }, | |
] }, | |
{ titulo: 'Juros e Multas', codigo: '1.2', tipo: 3, lista: [ |
http://redmine.seucondominio.com.br/issues/4695
Inicialmente Grooming somente do registro de boletos (boleto ficar verde)
Analisar Protótipo e Github Diego F.
Cobranca.do_cliente(1).simular_repeticoes
O chamado acima irá buscar todas cobranças do cliente 1 e quando chamar simular repetições , o postgres irá simular cobranças de TODOS OS CLIENTES. Portanto Teremos um problema muito sério de performance em um futuro muito próximo
https://github.com/denoww/seucondominio/commit/41b1f94cfad3a29e1d0ca4af91dff75cd683de6a
79 additions and 115 deletions.
Ficou um pouco mais organizado e com 36 linhas de código a menos
Observação: Mesmo que tenha ficado bugs eles serão corrigidos em cima de um padrão sustentável
O código nas cobranças fantasmas, só é viavel caso não cause muito trabalho para implementar, pois tem função de busca. Ficou definido que vai ter código!
Agir como o Google Agenda: Que quando usuário modifica a repetição o sistema deve refletir a repetição somente nos seus irmãos, dali pra frente.