Budget split for transactions - Model Refactor

[jantman]

This is part 1 of 2 to add support for allocating a single transaction against multiple budgets. This must maintain the actual transaction amount (for OFX reconcile, etc.) but allow allocating that amount either to one budget, or split across multiple budgets.

Planning:

• Figure out how to handle a Transaction's budgeted_amount if we're now going to allow budget splits.

Implementation:

• Add another model, BudgetTransaction, that builds an association between a transaction, an amount that's part or all of that transaction, and a budget. Fields should probably be ID, trans_id / transaction relationship, budget_id / budget relationship, and amount.
• Transaction model gets a backref to a list of BudgetTransactions.
• Database migration for this. Adds the new table and the relation to the Transaction table, migrates (copies) the data.
• Code updates to make all of that work, including update to Transaction creation and editing.
• Ensure ScheduledTransaction to Transaction conversion works correctly
• Alter the database migration previously created to drop the Transaction.budget_id column.
• Test the database migrations using a small sample database. Maybe try testing them in both directions?

[jantman]

Maybe better than doing all the work it would take to retrofit this, we should add transaction Categories in addition to budgets... where budgets would be for... well... budgeting, and categories would be solely for reporting. That would make implementation easier, and we could setup default categories for each budget, but is this a good idea?

[jantman]

Categories is probably a bad idea. It's a hack-y way around the complexity of the problem, that ends up complicating the UX and not really solving the problem.

I think the logical implementation is a BudgetTransaction model:

• id
• trans_id / transaction
• budget_id / budget
• amount

The Transaction model should get backref relationships to a list of BudgetTransactions.

The UI will handle validation of this, but we should also have some DB-side validation that ensures all BudgetTransaction amount sums equal the Transaction amount.

We'll want to remove the budget field on the Transaction itself, and then update the codebase to work with the new models.

We'll also need a migration for this that adds the new table and the relation to the Transaction table, migrates the data, and then drops the old columns.

[jantman]

Updated the initial comment/description of the issue with the current plan of work.

[jantman]

Updated the checklist again. I started some implementation for this in the noci-issues/105 branch, but forgot about the budgeted_amount field on Transaction and need to figure out how to handle that, and how to handle the budget associated with it. Not sure if that should be part of the Transaction model or the BudgetTransaction model.

[jantman]

So regarding the last comment on budgeted_amount... I think the solution to this is to add a planned_budget field on the Transaction and use that, along with budgeted_amount.

So a Transaction will have values for planned_budget / planned_budget_id and budgeted_amount set by the ScheduledTransaction, and then the related BudgetTransaction instances to describe the actual amount(s).

[jantman]

As of the above commit, this issue should finally be complete aside from testing the DB migrations.

I'll probably just write a one-off script to handle that.

Or, maybe if I really care, I'll combine the auto-migration logic with the DB refreshing test logic, and write a sample class for testing DB forward and reverse migrations.

[jantman]

Released today in 1.0.0