[Bug]: Toggling overspending rollover only propagates forward #2647

Closed
opened 2026-02-28 20:22:57 -06:00 by GiteaMirror · 5 comments
Owner

Originally created by @Daedalus359 on GitHub (Nov 21, 2025).

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

Image

It looks like toggling the "Rollover overspending" / "Remove overspending rollover" setting by clicking the balance entry for a particular (category, month) does not change the setting for that category in months before the one selected. See the attached screenshot. In the yellow box, this occurs once with the setting turned on in column 2. In the red box, this occurs twice: the setting is turned on in column 2 and off in column 4, creating a small pocket where the rollover occurs.

Granted, this gives users arbitrary control over exactly which months get rollover. I can't think of a use case for this, but maybe there is one. However, it also allows for situations where accidental button presses or experimentation with this feature by users who don't understand its full behavior (my current problem) cause a budget's present balance to be affected by settings changes in areas which may be off screen and potentially pretty difficult to locate (yellow can be found by a manual binary search, but not red). That's why I consider this a bug.

I would prefer if the app simply had an all or nothing approach to whether a category has rollover turned on, as this would meet my needs best. If that's not desirable for some reason, it might be worth adjusting the text on the buttons that toggle this setting on and off.

As far as I know, the only way to eliminate all unlocated rollover setting changes via the UI would be to go all the way back in the budget history and toggle this setting in the first month of every category. If anyone has a better approach, it might be helpful to note that in this thread as well.

How can we reproduce the issue?

To recreate the situations in my screenshot above, take four months of budget data over at least two categories. Turn rollover off in month 1 for both categories, turn it back on in month 2 for both categories, and turn it off again in month 4 for one category (corresponding to the red box).

Note that the first step is just to confirm a blank slate for experimenting with this bug, so it could actually take as little as one unintended button press to create this issue in a typical budget.

Where are you hosting Actual?

Desktop App (Electron)

What browsers are you seeing the problem on?

No response

Operating System

Windows 10

Originally created by @Daedalus359 on GitHub (Nov 21, 2025). ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? <img width="1098" height="296" alt="Image" src="https://github.com/user-attachments/assets/afebee12-b7f6-4c18-b413-a49d4d12e1f6" /> It looks like toggling the "Rollover overspending" / "Remove overspending rollover" setting by clicking the balance entry for a particular (category, month) does not change the setting for that category in months before the one selected. See the attached screenshot. In the yellow box, this occurs once with the setting turned on in column 2. In the red box, this occurs twice: the setting is turned on in column 2 and off in column 4, creating a small pocket where the rollover occurs. Granted, this gives users arbitrary control over exactly which months get rollover. I can't think of a use case for this, but maybe there is one. However, it also allows for situations where accidental button presses or experimentation with this feature by users who don't understand its full behavior (my current problem) cause a budget's present balance to be affected by settings changes in areas which may be off screen and potentially pretty difficult to locate (yellow can be found by a manual binary search, but not red). That's why I consider this a bug. I would prefer if the app simply had an all or nothing approach to whether a category has rollover turned on, as this would meet my needs best. If that's not desirable for some reason, it might be worth adjusting the text on the buttons that toggle this setting on and off. As far as I know, the only way to eliminate all unlocated rollover setting changes via the UI would be to go all the way back in the budget history and toggle this setting in the first month of every category. If anyone has a better approach, it might be helpful to note that in this thread as well. ### How can we reproduce the issue? To recreate the situations in my screenshot above, take four months of budget data over at least two categories. Turn rollover off in month 1 for both categories, turn it back on in month 2 for both categories, and turn it off again in month 4 for one category (corresponding to the red box). Note that the first step is just to confirm a blank slate for experimenting with this bug, so it could actually take as little as one unintended button press to create this issue in a typical budget. ### Where are you hosting Actual? Desktop App (Electron) ### What browsers are you seeing the problem on? _No response_ ### Operating System Windows 10
GiteaMirror added the bug label 2026-02-28 20:22:57 -06:00
Author
Owner

@youngcw commented on GitHub (Nov 21, 2025):

This is by design. If the rollover is enabled for a specific month, or range of months, in order to handle the overspending it needs to stay that way or the budget history is lost.

@youngcw commented on GitHub (Nov 21, 2025): This is by design. If the rollover is enabled for a specific month, or range of months, in order to handle the overspending it needs to stay that way or the budget history is lost.
Author
Owner

@Daedalus359 commented on GitHub (Nov 21, 2025):

I'm new to using this feature, so I apologize if I'm missing something basic. I don't understand your explanation. Are you saying that disabling the rollover after enabling it causes some information to be lost? That doesn't sound right, but it's the only interpretation of your response I can think of.

If my understanding of your comment is correct, then I don't think it addresses why forward propagation of the setting change is desirable vs applying the new setting uniformly to all months.

@Daedalus359 commented on GitHub (Nov 21, 2025): I'm new to using this feature, so I apologize if I'm missing something basic. I don't understand your explanation. Are you saying that disabling the rollover after enabling it causes some information to be lost? That doesn't sound right, but it's the only interpretation of your response I can think of. If my understanding of your comment is correct, then I don't think it addresses why forward propagation of the setting change is desirable vs applying the new setting uniformly to all months.
Author
Owner

@youngcw commented on GitHub (Nov 21, 2025):

Changing a rollover state changes the budget, that changes the balances, to budget numbers, etc. If you remove the rollover in a past month, then budget then is different and the history of what happened back then is lost (it has changed and cannot be deterministically recovered unless you remember which categories and which months had the carryover enabled.)

@youngcw commented on GitHub (Nov 21, 2025): Changing a rollover state changes the budget, that changes the balances, to budget numbers, etc. If you remove the rollover in a past month, then budget then is different and the history of what happened back then is lost (it has changed and cannot be deterministically recovered unless you remember which categories and which months had the carryover enabled.)
Author
Owner

@youngcw commented on GitHub (Nov 21, 2025):

The reason that the carryover is enabled for many months at a time is if you have a CC category that is holding debt, and are likely going to be rolling forward the balance for many months, or are using the auto hold feature for income

@youngcw commented on GitHub (Nov 21, 2025): The reason that the carryover is enabled for many months at a time is if you have a CC category that is holding debt, and are likely going to be rolling forward the balance for many months, or are using the auto hold feature for income
Author
Owner

@Daedalus359 commented on GitHub (Nov 21, 2025):

Thanks, I see what you're saying. If this toggle is intended to be used primarily on the present month and there are use cases for having it turned on and then back off over a large but limited span of months, then that behavior makes sense.

@Daedalus359 commented on GitHub (Nov 21, 2025): Thanks, I see what you're saying. If this toggle is intended to be used primarily on the present month and there are use cases for having it turned on and then back off over a large but limited span of months, then that behavior makes sense.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#2647