- Dockerfile copia el proyecto Django, no la raiz del repo, para que
manage.py y wsgi.py queden donde gunicorn los espera
- collectstatic en tiempo de construccion y CMD en la imagen
- .dockerignore: evita que .env, .git y artefactos locales entren en la imagen
- requirements.txt sin BOM
La tabla de gastos mostraba "No hay gastos / Anade el primero" tanto cuando el
usuario no tiene ningun gasto como cuando sus filtros no devuelven nada. En el
segundo caso el mensaje miente y ademas empuja a crear un gasto que no hace
falta.
Ahora, con cualquier filtro puesto (ano, mes, categoria, etiquetas, cuenta o
rango), el mensaje dice que no hay gastos que coincidan y ofrece quitarlos.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El listado de ingresos era el unico que seguia volcando la tabla entera sin
filtros, sin totales y sin paginacion: con unos cuantos anos de datos la
pagina se vuelve inmanejable y no hay forma de responder "cuanto ingrese en
marzo".
Se reutiliza lo que ya existe en el listado de gastos en vez de inventar nada:
los mismos filtros de ano, mes y cuenta, el mismo rango de fechas libre con la
misma precedencia y el mismo aviso, la misma paginacion de diez por pagina y
el mismo query_params para que los enlaces de pagina no pierdan los filtros.
Los ingresos marcados como traspaso se siguen listando, porque son movimientos
reales de la cuenta y hay que poder verlos y corregirlos, pero el total los
excluye: de ahi la etiqueta "Total (sin traspasos)".
El estado vacio distingue entre no tener ingresos y que los filtros no
devuelvan nada, para no invitar a crear un ingreso cuando el problema es el
filtro. El colspan de esa fila es 5, que son las columnas de esta tabla.
select_related("account") mantiene el numero de consultas plano: sin el, cada
fila pedia su cuenta por separado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cubren las reglas que no se ven leyendo la vista: que los extremos son
inclusivos, que cada fecha puede ir sola, que un rango invertido o una fecha
ilegible se ignoran en vez de vaciar el listado, y que el rango tiene
precedencia sobre los selectores de ano y mes.
En el dashboard se comprueba ademas que la comparativa queda desactivada y
avisada cuando hay rango, que el eje del grafico cambia de dia a mes al pasar
el umbral, y que los huecos del eje salen a cero en lugar de desaparecer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un rango que solo funciona en el listado obliga a cambiar de pantalla para
responder "cuanto gaste en ese viaje". El dashboard acepta ahora los mismos
date_from y date_to, con la misma precedencia sobre ano y mes.
Dos decisiones que no son obvias:
La comparativa se desactiva cuando hay rango. Un rango arbitrario no tiene un
"periodo anterior" evidente, y elegir uno por el usuario daria un porcentaje
que parece significativo sin serlo. Se distingue entre pedirla y poder
aplicarla (compare_requested / compare_enabled) para poder avisar de que se
ha ignorado en vez de desmarcar la casilla en silencio.
El eje del grafico lo decide la longitud del rango, no el mes: por debajo de
62 dias se agrupa por dia y por encima por mes, que es donde un grafico
diario deja de leerse. El eje se rellena con ceros en los huecos, igual que
ya hacia el resto, para que un periodo sin gastos no colapse la escala. La
agrupacion diaria usa el propio campo date y no TruncDate, porque date ya es
un DateField y TruncDate le aplicaria una conversion de zona horaria que en
SQLite revienta si no esta instalada la base de datos de husos.
La tarjeta de proyeccion a fin de mes se oculta con rango activo: proyectar a
fin de mes desde un periodo arbitrario no significa nada.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Los selectores de ano y mes solo saben expresar periodos naturales completos.
"Del 15 de marzo al 3 de abril" o "desde que empece el trabajo nuevo" no se
pueden pedir, y son justo las preguntas que uno le hace a un gestor de gastos.
Se anaden dos parametros date_from y date_to, opcionales por separado: "desde
el 1 de marzo" sin fecha final es un filtro perfectamente valido. Si el rango
viene invertido se ignoran las dos fechas, porque devolver una lista vacia sin
explicacion es peor que descartar un filtro mal puesto.
Cuando hay rango, manda el rango y los selectores de ano y mes no se aplican:
combinar ambos criterios da intersecciones que el usuario no ha pedido y no
puede ver. La plantilla lo avisa con un mensaje y un enlace para quitarlo, en
vez de dejar los selectores mostrando un periodo que no es el que se esta
viendo.
Los campos de fecha comparten estilo con el resto de filtros, incluido el
anillo de foco, para que no desentonen con los selectores de al lado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La plantilla cerraba un div que nunca se habia abierto, asi que el
</div> del .table-wrap acababa cerrando el contenedor de la pagina y todo lo
que viniera despues quedaba fuera de su sitio. Ahora las aperturas y los
cierres cuadran.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El campo is_transfer tiene dos comportamientos opuestos y uno de ellos falla
en silencio: si el filtro se cuela en un calculo de saldo, los numeros siguen
apareciendo, solo que mal. Los tests se organizan en dos bloques que cubren
justo esa frontera.
- Analisis: el traspaso no cuenta en los KPIs de home ni del dashboard, ni en
el total del listado, ni en la comparativa de periodos, ni en el progreso de
los objetivos de pago y presupuesto.
- Saldo: el traspaso SI cuenta en current_balance, monthly_balance,
balance_until, monthly_net y en el objetivo de ahorro.
Tambien se cubre que el listado de gastos siga mostrando el traspaso aunque su
total lo descuente, que es la parte que un filtro puesto de mas romperia.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sin esto el campo is_transfer no es alcanzable: no aparece en los formularios
de gasto ni de ingreso, asi que nadie puede marcar un movimiento como
traspaso.
Ademas, un movimiento que no suma al total tiene que verse distinto o el
usuario no entendera por que sus numeros no cuadran con la tabla. Se anade un
distintivo "Traspaso" en el listado de gastos, en los ultimos movimientos de
home y en los gastos recientes del dashboard, que son los tres sitios donde
se listan movimientos sin agregarlos.
El distintivo usa una variante nueva, .badge-neutral, en vez de reutilizar
.badge-inactive: un traspaso es informacion, no un estado degradado, y
pintarlo con el color de error o de cuenta inactiva daria a entender que algo
va mal. Las variables que usa (--color-chip-bg y --color-text-muted) ya
existen en los dos temas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un traspaso mueve dinero entre cuentas propias: suma al saldo de cada cuenta
pero no es gasto ni ingreso real. Las agregaciones de analisis (KPIs, graficos
de home y dashboard, comparativa de periodos, totales del listado y objetivos
de pago y presupuesto) pasan a excluirlo.
Hay dos comportamientos opuestos sobre el mismo campo y conviene no
confundirlos:
- Analisis: excluye los traspasos. De ahi el helper _analysis_expenses, que
documenta en su docstring donde NO debe usarse.
- Saldo: los incluye. _account_balances, current_balance, monthly_balance,
balance_until y monthly_net quedan intactos a proposito; filtrarlos ahi
descuadraria todos los saldos de la aplicacion de forma silenciosa, que es
mucho peor y menos evidente que inflar un KPI.
Por el mismo motivo la rama saving de Goal.progress tampoco filtra: mandar
dinero a la cuenta de ahorro es justo como se progresa en ese objetivo.
Los ultimos movimientos de home dejan de colgar de la consulta de KPIs y usan
la suya propia: son un listado, no un analisis, y un traspaso tiene que poder
verse ahi. Lo mismo en el listado de gastos, donde la tabla los sigue
mostrando y solo los totales los descuentan.
Los managers por defecto de Expense e Income no se tocan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
