El listado de etiquetas era una lista sin mas, sin forma de saber cuales
estaban en uso. Pasa a tabla, en linea con el resto de listados, y anade
una columna con el numero de gastos que usa cada etiqueta.
El contador se calcula con annotate(Count("expenses")) en la vista, en vez
de contar desde la plantilla, para no provocar una query por fila.
Incluye tambien el estado vacio, que la lista no tenia.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Saca de home() dos ayudantes reutilizables:
- _account_balances(): calcula el saldo de cada cuenta con dos queries
agregadas en lugar de llamar a account.current_balance() en bucle,
que disparaba un N+1.
- _category_tree(): aplana las categorias en preorden con su profundidad,
para poder indentarlas en la plantilla.
Con ellos, account_list pasa a mostrar el saldo calculado de cada cuenta
(antes usaba current_balance() desde la plantilla) y category_list muestra
un arbol indentado en vez de una columna "Categoria padre" que obligaba a
reconstruir la jerarquia mentalmente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
home() (views.py) y expenses/home.html pasan de mostrar tres numeros
sueltos y un listado plano de ultimos gastos a un panel mas completo:
- Saldo total y desglose por cuenta (account_balances/total_balance),
calculado con dos queries agregadas (values().annotate(Sum(...)))
en vez de N+1 llamadas a account.current_balance() en un bucle.
- Comparativa del gasto del mes en curso contra el mes anterior
(prev_total/diff_amount/diff_pct), con aviso de que el mes en curso
esta incompleto y la comparacion no es equivalente.
- Avisos (has_alerts) cuando hay objetivos excedidos o cuentas en
negativo, con enlace directo a objetivos/cuentas.
- "Ultimos movimientos" mezcla gastos e ingresos (antes solo se veian
los ultimos gastos) ordenados por fecha, con icono/color segun tipo.
- Se reutiliza una unica query de Goal tanto para el widget de
objetivos (show_on_home) como para las alertas de excedidos
(is_exceeded()), en vez de dos queries separadas.
base.css: nuevo bloque "/* Home widgets */" con las clases que usa la
plantilla (.home-section, .kpi-grid/.kpi-card, .balance-*,
.movements-list/.movement-*, .amount-positive/.amount-negative,
.comparison), incluyendo un ajuste responsive que oculta la cuenta en
movil (<480px).
No relacionado con los formularios de los commits anteriores; se
incluye aqui porque estaba pendiente de subir en la misma rama.
Sintoma: /accounts/password_change/ renderizaba la pantalla del admin
de Django (cabecera "Administracion de Django", breadcrumb "Inicio >
Cambio de contrasena") en vez de la plantilla de la app.
Causa: con APP_DIRS=True (settings.py) y sin DIRS explicito, Django
busca plantillas recorriendo INSTALLED_APPS en orden y usa la PRIMERA
coincidencia por ruta relativa. django.contrib.admin trae sus propias
registration/password_change_form.html y
registration/password_change_done.html. Como 'django.contrib.admin'
aparecia antes que 'expenses' en la lista, sus plantillas ganaban
siempre a las de nuestra app, que ni siquiera llegaban a evaluarse.
Verificado con el shell de Django (get_template(...).origin.name):
Antes del cambio:
registration/password_change_form.html -> .../django/contrib/admin/templates/registration/password_change_form.html
registration/password_change_done.html -> .../django/contrib/admin/templates/registration/password_change_done.html
Despues del cambio:
registration/password_change_form.html -> .../expenses/templates/registration/password_change_form.html
registration/password_change_done.html -> .../expenses/templates/registration/password_change_done.html
Esto tambien explica por que el bug de las plantillas rotas (extendian
"base.html", que no existe; ver commit anterior) llevaba tanto tiempo
sin dar error: al estar sombreadas, esas plantillas nunca se
renderizaban, asi que su TemplateDoesNotExist nunca saltaba. Y explica
por que el login SI funcionaba pese a la colision de app: el admin
publica su login en "admin/login.html", no en "registration/login.html",
asi que ahi no habia conflicto.
Efecto secundario esperado y comprobado (no es una regresion, pero hay
que saberlo): /admin/password_change/, que Django resuelve tambien por
la ruta "registration/password_change_form.html" cuando un admin
cambia su propia contrasena, ahora renderiza con el layout completo de
la app (menu de navegacion, etc.) en vez del look propio del admin.
Probado con un superusuario contra /admin/, /admin/login/,
/admin/password_change/ y /admin/password_change/done/: los cuatro
responden 200 y el formulario funciona (AdminPasswordChangeForm hereda
los mismos campos old_password/new_password1/new_password2 de
PasswordChangeForm, asi que el parcial generico de campos los pinta
sin problema). El resto del admin (listados, cambio de contrasena de
otros usuarios, etc.) no usa ninguna plantilla bajo registration/ ni
admin/ que la app sobrescriba, asi que no le afecta.
No se reordena alfabeticamente esta lista en el futuro sin tener en
cuenta esto: hay un comentario en el propio settings.py explicandolo.
Ambas plantillas hacian {% extends "base.html" %}, pero en este
proyecto no existe ninguna plantilla llamada asi a nivel raiz: el
layout de la app se llama "expenses/base.html" (esta dentro de
expenses/templates/expenses/, no de expenses/templates/). Con
APP_DIRS=True y DIRS=[] en settings.py, Django busca "base.html" tal
cual en la carpeta templates/ de cada app instalada y no lo encuentra
en ninguna, asi que un {% extends %} a esa ruta lanza
TemplateDoesNotExist en cuanto se intenta renderizar la plantilla.
Esto llevaba tiempo sin detectarse porque, hasta el commit de
INSTALLED_APPS de esta misma tanda, django.contrib.admin sombreaba
estas dos plantillas con las suyas propias (ver ese commit): la
plantilla rota de la app nunca llegaba a cargarse, asi que el error
nunca saltaba. Al arreglar el orden de INSTALLED_APPS estas plantillas
pasan a usarse de verdad, así que había que arreglarlas ahora sí en el
mismo movimiento.
Cambios:
- Ambas extienden "expenses/base.html".
- Se migran al parcial expenses/_form_fields.html y a class="app-form",
igual que el resto de formularios (ver commit anterior).
- Se anade un enlace de "Volver" a {% url 'home' %} en las dos, y un
{% block title %} (heredaban el titulo generico "Expenses manager").
Sustituye {{ form.as_p }} (o el bucle for field in form repetido a
mano en expense_form.html) por {% include "expenses/_form_fields.html" %}
y anade class="app-form" al <form> en:
- categories/form.html, categories/list.html (alta de categoria)
- expenses/account_form.html
- expenses/expense_form.html
- expenses/income_form.html
- expenses/tag_form.html
- fuel/create.html
- goals/form.html
- registration/login.html
De paso:
- categories/list.html: se corrige indentacion de la tabla y las
etiquetas <a> de "Editar"/"Eliminar" (estaban dentro de una celda
sin problema funcional, solo desalineadas) y se anade una <th> vacia
para la columna de acciones.
- goals/form.html: el bloque title y el <h1> tenian "Nuevo objetivo"
fijo aunque la vista goal_edit ya pasa title="Editar objetivo" en el
contexto; ahora la plantilla usa {{ title }}, asi que el formulario
de edicion deja de decir "Nuevo objetivo" por error.
No se toca la logica de las vistas ni los formularios en forms.py.
Los formularios usaban form.as_p (salida generica de Django) o bucles
manuales for field in form repetidos en cada plantilla, sin estilos
propios: inputs/selects/textareas sin padding, borde ni foco visibles,
y cada plantilla resolvia los errores/ayuda de campo a su manera.
Cambios:
- base.css: nuevas clases .app-form, .form-field (label + control en
columna), estilos de input/select/textarea (incluye estado :focus
con el color de foco del tema), .form-field-checkbox para campos
booleanos y .form-help para el help_text de los campos.
- Nuevo parcial expenses/_form_fields.html: itera los campos del
formulario y renderiza label, control, help_text y errores de forma
consistente. Incluye un caso especial para el campo "tags" de gastos
(CheckboxSelectMultiple), que se pinta como lista de chips en vez de
checkboxes sueltos.
Este commit solo anade el estilo y el parcial; las plantillas que lo
adoptan van en el siguiente commit.
Mueve el enlace de Cuentas junto al de Repostajes y elimina los
enlaces comentados a Etiquetas y Categorias del menu principal (ya
estan accesibles desde el desplegable de Configuraciones).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Anade la utilidad .sr-only en base.css para labels ocultos
visualmente pero accesibles a lectores de pantalla.
- dashboard.html: labels sr-only en los selects de cuenta/ano/mes del
formulario de filtros; ARIA completo (role=progressbar,
aria-valuemin/max/now/label/valuetext) en la barra de progreso del
widget de objetivos; corrige el bug real de esa barra, que usaba
goal.percentage en vez de goal.bar_width y podia desbordar el 100%;
corrige colspan="7" a colspan="5" en la fila vacia de gastos
recientes (la tabla tiene 5 columnas).
- expense_list.html: id + label sr-only en los selects de ano/mes/
cuenta; label explicito para el select de categoria; role="group"
y aria-label en el bloque de filtros por etiquetas (con
aria-hidden en el texto "Tags:" para evitar doble lectura);
paginacion pasada de <div> a <nav aria-label="Paginacion de
gastos">; corrige colspan="4" a colspan="6" en el estado vacio de
la tabla (6 columnas).
- goals/list.html: mismo ARIA de progreso que en dashboard.html;
<h2>Objetivos</h2> a <h1>, para que la pagina empiece en h1 como
el resto.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Anade charts.js con getChartColors, applyCartesianColors y
registerThemedChart para centralizar los colores de los graficos segun
el tema activo y refrescarlos en vivo al cambiar de tema (via
MutationObserver sobre data-theme).
- Corrige el bug de renderizado en graficos de tipo 'line'
(TypeError: t.startsWith is not a function): los colores de tema ahora
se fijan en las opciones al crear cada grafico en lugar de mutarlas
despues de new Chart(...).
- Anade variables --chart-grid-color y --chart-fill-color en base.css
(light/dark) e incluye charts.js en base.html.
- Aplica el theming a categoryChart, mainChart y accountChart{id}
(dashboard.html), miniChart (home.html) y monthlyChart/kmChart
(fuel/list.html).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
