fix paid schedules showing as upcoming in the account #4188
Conversation
actual-github-bot
bot
changed the title
✅ Deploy Preview for actualbudget ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
matt-fidd
changed the title
Bundle Stats — desktop-clientHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset
View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger
Smaller No assets were smaller Unchanged
|
Bundle Stats — loot-coreHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset
View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger No assets were bigger Smaller No assets were smaller Unchanged
|
WalkthroughThe pull request introduces a new function The changes enhance the logic for handling scheduled transactions by clearly differentiating between recurring and non-recurring schedules. For recurring schedules, the code now generates multiple upcoming dates up to a specified period end. For non-recurring schedules, it directly adds the next date to the array. Additionally, there's a modification to handle the 'paid' schedule status by potentially removing the first date from the array. Possibly related PRs
Suggested labels
Suggested reviewers
Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
upcoming-release-notes/4188.mdis excluded by!**/*.md
📒 Files selected for processing (2)
packages/loot-core/src/client/data-hooks/transactions.ts(2 hunks)packages/loot-core/src/shared/schedules.ts(1 hunks)
🧰 Additional context used
📓 Learnings (1)
packages/loot-core/src/client/data-hooks/transactions.ts (1)
Learnt from: matt-fidd
PR: actualbudget/actual#4166
File: packages/loot-core/src/client/data-hooks/transactions.ts:200-200
Timestamp: 2025-01-16T14:29:13.188Z
Learning: In the scheduled transactions implementation within `packages/loot-core/src/client/data-hooks/transactions.ts`, the `upcoming` flag is set based on `schedules.length > 0` to act as an override, where the first occurrence gets `false` and subsequent occurrences get `true`. This is intentional and should not be changed to date-based comparison.
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: Functional
- GitHub Check: Visual regression
- GitHub Check: build (macos-latest)
- GitHub Check: build (windows-latest)
- GitHub Check: build (ubuntu-latest)
🔇 Additional comments (3)
packages/loot-core/src/client/data-hooks/transactions.ts (3)
15-15: LGTM!Clean import of the new helper function.
192-193: LGTM! Clean fix for paid schedules.This change correctly prevents paid schedules from showing as upcoming by removing the first date when the schedule is marked as paid.
175-190: LGTM! Verify edge cases for date generation.The logic correctly differentiates between recurring and non-recurring schedules, generating dates appropriately in each case.
Let's verify there are no edge cases where this change might affect other schedule types:
✅ Verification successful
✓ Schedule date generation logic is robust and well-tested
The implementation correctly handles both recurring and non-recurring schedules with proper date validation, parsing, and edge case handling. The code is supported by comprehensive tests covering both scenarios.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for all schedule-related test files to check edge cases fd -e ts -e js test.*schedule # Search for any existing schedule type checks rg -A 3 "schedule.*type|type.*schedule"Length of output: 10067
Script:
#!/bin/bash # Find schedule type definitions and date handling ast-grep --pattern 'interface $_Schedule { $$$ }' # Look for date handling in schedules rg -A 5 "next_date|date.*condition" --type ts # Search for recurring patterns rg -A 3 "recurring|repeat" --type tsLength of output: 45442
| export function scheduleIsRecurring(dateCond) { | ||
| const cond = new Condition(dateCond.op, 'date', dateCond.value, null); | ||
| const value = cond.getValue(); | ||
|
|
||
| return value.type === 'recur'; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add null safety checks to prevent runtime errors.
The function should handle cases where dateCond or its properties are undefined/null.
export function scheduleIsRecurring(dateCond) {
+ if (!dateCond?.op || !dateCond?.value) {
+ return false;
+ }
const cond = new Condition(dateCond.op, 'date', dateCond.value, null);
const value = cond.getValue();
return value.type === 'recur';
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export function scheduleIsRecurring(dateCond) { | |
| const cond = new Condition(dateCond.op, 'date', dateCond.value, null); | |
| const value = cond.getValue(); | |
| return value.type === 'recur'; | |
| } | |
| export function scheduleIsRecurring(dateCond) { | |
| if (!dateCond?.op || !dateCond?.value) { | |
| return false; | |
| } | |
| const cond = new Condition(dateCond.op, 'date', dateCond.value, null); | |
| const value = cond.getValue(); | |
| return value.type === 'recur'; | |
| } |
I found an issue where if a schedule posts early the upcoming one will still show even if the schedule is "paid".
This adds the same helper function as #4180 whichever is merged first will probably cause a conflict with the other, I'll fix it.