feature: recurring transactions added- migrations, ui, api updated. Closes #5
This Pull requests solves recurring transactions adding feature. Closes #5
If recurring transaction is selected from the drop down menu while adding an expense, that expense id will be inserted in the recurring transaction table once. When listing for the groups, it will check if any pending recursive transaction needed to be added, if yes, then same transaction will be copied.
WIP:
- Need to add same support while editing the expense.
- Delete only latest transaction in the recursive transaction is yet to be supported. This will be done by giving options for archiving the expense/ delete this and all future expenses.
Update the PR. Features:
- Set the recurring expense schedule
- While fetching Group's Expenses, checks if any pending expense exists. If yes, adds into the DB and then lists all the expenses.
- Edit the expense schedule.
- Delete the expense schedule (Deleting the last added expense deletes the future entries.)
- Archive the expense which needs to be shown in history but not needed while calculating.
- Archiving the last expense doesn't add to calculations, but will occur in the next cycle.
what happens if no one opens the group for over a month? will it add two recurring entries? or will it skip one?
I generally think that there should be some sort of scheduler that takes care of adding recurring expenses rather than doing some magic when people are loading the group
what happens if no one opens the group for over a month? will it add two recurring entries? or will it skip one?
It recursively adds all the pending txns, which means it won't skip any.
I generally think that there should be some sort of scheduler that takes care of adding recurring expenses rather than doing some magic when people are loading the group
Agreed. I wanted to make a scheduler only but decided against it for the following reasons:
- Some groups can just a txn scheduler but never open that group. Since it's not requiring even logins, abuse can be high. So I felt if someone is opening the group, they are showing the intent that they want all the "pending expenses". Those who are not opening, can be avoided.
- This is open source + allows redistribution. So, if someone wants to set Spliit up in their own server, they will need to set up crons scheduler separately if they want to use serverless. Having server in EC2 machines would be easier though, but I didn't want to limit serverless possibility becasue of just one small feature.
The approach is appealing because it also works with a scheduler, you can simply have a cron task that polls the transaction list API, right?
Yes. But we will have to build a scheduler also. For example, we wouldn't fetch all the groups all the time. We would rather fetch only the transactions that needs to be copied (Fetch only those groups). But yes, internally, scheduler needs to call only this function.
@rgov Have removed archive feature from this PR and opened another PR for the same. Resolved all the comments also.
@rgov Resolved comments. Please check.
@neonshobhit Can you please resolve conflicts..!?
Would love to see this merged @neonshobhit
@sir-argupta @ankit-kapur Apologies, Completely missed the notifications.
Anyways it's resolved and working now. @scastiel can you please review this PR?
It looked like this PR has been inactive for a bit and has several merge conflicts that I was having issues resolving. I took inspiration from this PR for my take on the feature^.
(Note: This was also the last feature I was really waiting for to be able to switch off of SplitWise, so I have some extra motivation to try to get it through)