[Bug]: Deleting Custom Reports (experimental feature not activated) will result in empty spaces if you create new custom reports #1468

Closed
opened 2026-02-28 19:44:19 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @argeljoseph on GitHub (Oct 4, 2024).

Verified issue does not already exist?

  • I have searched and found no existing issue
  • I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file)

What happened?

Steps to reproduce:

  1. Create multiple custom reports
  2. Delete all the reports from step 1
  3. Create custom reports again, this will result in empty spaces when clicking reports to view all your custom reports

Before, the new reports (after some reports are deleted),go to the "empty space"
Deleted Reports - Empty Space

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Firefox, Chrome, Microsoft Edge

Operating System

Linux

Originally created by @argeljoseph on GitHub (Oct 4, 2024). ### Verified issue does not already exist? - [X] I have searched and found no existing issue - [X] I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file) ### What happened? Steps to reproduce: 1. Create multiple custom reports 2. Delete all the reports from step 1 3. Create custom reports again, this will result in empty spaces when clicking reports to view all your custom reports Before, the new reports (after some reports are deleted),go to the "empty space" ![Deleted Reports - Empty Space](https://github.com/user-attachments/assets/78891c12-9547-477e-b677-7f5057c469a9) ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Firefox, Chrome, Microsoft Edge ### Operating System Linux
GiteaMirror added the bug label 2026-02-28 19:44:19 -06:00
Author
Owner

@andfreund commented on GitHub (Oct 14, 2024):

This bug still persists in my self-hosted Actual Budget instance, using Docker:

Bildschirmfoto 2024-10-14 um 18 39 20

Both client and server versions are v24.10.1, so am I right assuming that this bug should have been fixed?

@andfreund commented on GitHub (Oct 14, 2024): This bug still persists in my self-hosted Actual Budget instance, using Docker: <img width="1384" alt="Bildschirmfoto 2024-10-14 um 18 39 20" src="https://github.com/user-attachments/assets/9ebb4b99-f292-416d-b40e-5d7629b3d592"> Both client and server versions are v24.10.1, so am I right assuming that this bug should have been fixed?
Author
Owner

@youngcw commented on GitHub (Oct 14, 2024):

This bug still persists in my self-hosted Actual Budget instance, using Docker:

Bildschirmfoto 2024-10-14 um 18 39 20 Both client and server versions are v24.10.1, so am I right assuming that this bug should have been fixed?

Try testing on the edge build. edge.actualbudget.org

@youngcw commented on GitHub (Oct 14, 2024): > This bug still persists in my self-hosted Actual Budget instance, using Docker: > > <img alt="Bildschirmfoto 2024-10-14 um 18 39 20" width="1384" src="https://private-user-images.githubusercontent.com/117188892/376324878-9ebb4b99-f292-416d-b40e-5d7629b3d592.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mjg5MjQ0MDcsIm5iZiI6MTcyODkyNDEwNywicGF0aCI6Ii8xMTcxODg4OTIvMzc2MzI0ODc4LTllYmI0Yjk5LWYyOTItNDE2ZC1iNDBlLTVkNzYyOWIzZDU5Mi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQxMDE0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MTAxNFQxNjQxNDdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1jMzljZDljMmNkY2U0ZThhOGRjMzI3ZjZmYzBlMzJiYTVhNWQwNjZhMDZlMmMzYWRiZTJlMTliN2E0NTY4NmUwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.UeqaWB-39Snsf7pC5VasgrpESM7rJ7bpemHsJwdXLB0"> > Both client and server versions are v24.10.1, so am I right assuming that this bug should have been fixed? Try testing on the edge build. edge.actualbudget.org
Author
Owner

@andfreund commented on GitHub (Oct 14, 2024):

Tested it with the edge build and got the same behavior.

@andfreund commented on GitHub (Oct 14, 2024): Tested it with the edge build and got the same behavior.
Author
Owner

@MatissJanis commented on GitHub (Oct 15, 2024):

@andfreund the patch applied here is indeed not perfect. It's only a stop-gap solution until we release the dashboard feature.

Let me explain what happens:

The reports page is now using a dashboard grid (both with & without the feature flag). It renders widgets on this grid. If a new custom report is created - it automatically adds it to the grid with "next" positions.

When three custom reports are added - that covers the first row. The fourth widget goes on a new row.

But now you delete 1st widget.. the grid is configured to collapse vertically, so the 4th widget will now "collapse" into the position of 1st. So you see a full row of 3 widgets. Most users won't notice this and it will feel like things are working as expected.

But then you delete the 2nd widget. Now you have a gap between the two widgets on the first row. And since we collapse vertically - the gap still remains there. We don't update the coordinates of the 3rd widget.

The two solutions I considered were:

  1. do nothing; wait for dashboard feature to be released - which will solve the problem as people can just drag-n-drop the widgets however they want;
  2. implement an algorithm that would re-calculate custom widget positions whenever a widget got deleted (IMO overkill since the problem won't be around for long)

So I went with (1). And if folks encounter issues - direct them to enable the dashboards experimental feature and then just manually drag-n-drop to patch the dashboard.


Ok, that's a long description of the issue, but I hope you now understand it more. TLDR: no plans to fully patch this issue in the short-term because dashboard will be released soon (aiming for v24.12.0).

@MatissJanis commented on GitHub (Oct 15, 2024): @andfreund the patch applied [here](https://github.com/actualbudget/actual/commit/d2f3c519033547f0e94294bd473ec19edc969b55) is indeed not _perfect_. It's only a stop-gap solution until we release the dashboard feature. Let me explain what happens: The reports page is now using a dashboard grid (both with & without the feature flag). It renders widgets on this grid. If a new custom report is created - it automatically adds it to the grid with "next" positions. When three custom reports are added - that covers the first row. The fourth widget goes on a new row. But now you delete 1st widget.. the grid is configured to collapse vertically, so the 4th widget will now "collapse" into the position of 1st. So you see a full row of 3 widgets. Most users won't notice this and it will _feel_ like things are working as expected. But then you delete the 2nd widget. Now you have a gap between the two widgets on the first row. And since we collapse vertically - the gap still remains there. We don't update the coordinates of the 3rd widget. The two solutions I considered were: 1. do nothing; wait for dashboard feature to be released - which will solve the problem as people can just drag-n-drop the widgets however they want; 2. implement an algorithm that would re-calculate custom widget positions whenever a widget got deleted (IMO overkill since the problem won't be around for long) So I went with (1). And if folks encounter issues - direct them to enable the dashboards experimental feature and then just manually drag-n-drop to patch the dashboard. --- Ok, that's a long description of the issue, but I hope you now understand it more. TLDR: no plans to _fully_ patch this issue in the short-term because dashboard will be released soon (aiming for v24.12.0).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#1468