Problem / motivation
Transactions are listed in the order they were entered, not by when they happened. render_transactions does enumerate(month.transactions, start=1) with no sort (monay/tui/screens/transactions.py:28), and the docstring treats the # as an insertion-stable handle (monay/tui/screens/transactions.py:3).
So if you log day 20 and then back-fill day 5, day 5 appears below day 20. The table doesn't read chronologically, which makes it hard to scan a month, and the # ordering has no relation to the dates.
Proposed solution
Sort the displayed transactions by day, then id (Transaction.day, Transaction.id — monay/domain/entities.py:128, :132) before rendering, and number the # column by position in that shown table, so tx edit N / tx del N target the row at visual position N.
- Sort happens at render time; the underlying list order is unchanged.
id is the tiebreaker so same-day transactions keep a stable, deterministic order.- the
# column should also updates when deleting a transaction.
Problem / motivation
Transactions are listed in the order they were entered, not by when they happened.
render_transactionsdoesenumerate(month.transactions, start=1)with no sort (monay/tui/screens/transactions.py:28), and the docstring treats the#as an insertion-stable handle (monay/tui/screens/transactions.py:3).So if you log day 20 and then back-fill day 5, day 5 appears below day 20. The table doesn't read chronologically, which makes it hard to scan a month, and the
#ordering has no relation to the dates.Proposed solution
Sort the displayed transactions by
day, thenid(Transaction.day,Transaction.id—monay/domain/entities.py:128,:132) before rendering, and number the#column by position in that shown table, sotx edit N/tx del Ntarget the row at visual positionN.idis the tiebreaker so same-day transactions keep a stable, deterministic order.#column should also updates when deleting a transaction.