[Bug]: un-hide categories - feature unavailable #1228

Closed
opened 2026-02-28 19:36:41 -06:00 by GiteaMirror · 9 comments
Owner

Originally created by @MatissJanis on GitHub (Jul 13, 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?

Funny, but there is no way to un-hide a category. It's only possible to un-hide a category group.

Where are you hosting Actual?

None

What browsers are you seeing the problem on?

No response

Operating System

None

Originally created by @MatissJanis on GitHub (Jul 13, 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? Funny, but there is no way to un-hide a category. It's only possible to un-hide a category group. ### Where are you hosting Actual? None ### What browsers are you seeing the problem on? _No response_ ### Operating System None
GiteaMirror added the user interfacegood first issuebug labels 2026-02-28 19:36:41 -06:00
Author
Owner

@shall0pass commented on GitHub (Jul 13, 2024):

Interested to know what you're seeing. I have options to show/hide groups and categories both. And I have options on both the desktop and Mobile views.

@shall0pass commented on GitHub (Jul 13, 2024): Interested to know what you're seeing. I have options to show/hide groups and categories both. And I have options on both the desktop and Mobile views.
Author
Owner

@MatissJanis commented on GitHub (Jul 13, 2024):

This is what I have:
Screenshot 2024-07-13 at 21 27 54

But now that I think about it more.. it doesn't have a "show" option because it's inside a group that's totally hidden. I wonder if we should still have a "show" option there and then make it show both the category and it's group.

WDYT?

@MatissJanis commented on GitHub (Jul 13, 2024): This is what I have: <img width="323" alt="Screenshot 2024-07-13 at 21 27 54" src="https://github.com/user-attachments/assets/812e4e7f-f7b1-45ef-8e99-2691c11a0b60"> But now that I think about it more.. it doesn't have a "show" option because it's inside a group that's totally hidden. I wonder if we should still have a "show" option there and then make it show both the category and it's group. WDYT?
Author
Owner

@shall0pass commented on GitHub (Jul 13, 2024):

That could make sense. It's definitely only not shown in hidden groups, like you noticed. No strong opinions either way from me.

@shall0pass commented on GitHub (Jul 13, 2024): That could make sense. It's definitely only not shown in hidden groups, like you noticed. No strong opinions either way from me.
Author
Owner

@youngcw commented on GitHub (Jul 17, 2024):

Unhiding the one category should probably unhide the group, then hide all the other categories if just one category is requested to be shown.

@youngcw commented on GitHub (Jul 17, 2024): Unhiding the one category should probably unhide the group, then hide all the other categories if just one category is requested to be shown.
Author
Owner

@eduarbo commented on GitHub (Aug 13, 2024):

Category and Category Group are managed independently, so when a Category Group is hidden and then shown again, the states of its Categories remain as they were before hiding the Group. Changing the functionality to reveal the Category Group along with the Category itself (if it’s not already marked as visible internally) could lead to confusion, as this would display not only the selected Category but also any other Categories that are internally marked as visible. E.g.

https://github.com/user-attachments/assets/c0c46d6f-4970-4066-9fcb-b2cf09d429ac

This might not be the expected behavior for some users. Alternatively, if we chose to only display the selected Category, we would need to override the state of all other Categories to mark them as hidden, which could lead to unexpected and potentially destructive effects.

The current solution might not be perfect, but it’s not bad either. Considering that it only requires two actions (showing the Category Group and then the Category) once per hidden Category Group, the inconvenience is minimal compared to the complications that could arise from overwriting all states.

@eduarbo commented on GitHub (Aug 13, 2024): Category and Category Group are managed independently, so when a Category Group is hidden and then shown again, the states of its Categories remain as they were before hiding the Group. Changing the functionality to reveal the Category Group along with the Category itself (if it’s not already marked as visible internally) could lead to confusion, as this would display not only the selected Category but also any other Categories that are internally marked as visible. E.g. https://github.com/user-attachments/assets/c0c46d6f-4970-4066-9fcb-b2cf09d429ac This might not be the expected behavior for some users. Alternatively, if we chose to only display the selected Category, we would need to override the state of all other Categories to mark them as hidden, which could lead to unexpected and potentially destructive effects. The current solution might not be perfect, but it’s not bad either. Considering that it only requires two actions (showing the Category Group and then the Category) once per hidden Category Group, the inconvenience is minimal compared to the complications that could arise from overwriting all states.
Author
Owner

@matt-fidd commented on GitHub (Feb 13, 2026):

@MatissJanis WDYT to moving this to a feature request?

Something like "Add ability to unhide categories from within hidden category groups"

@matt-fidd commented on GitHub (Feb 13, 2026): @MatissJanis WDYT to moving this to a feature request? Something like "Add ability to unhide categories from within hidden category groups"
Author
Owner

@MatissJanis commented on GitHub (Feb 15, 2026):

Thanks for bumping this up @matt-fidd .

I actually agree with @eduarbo. Especially on "The current solution might not be perfect, but it’s not bad either. [..] the inconvenience is minimal compared to the complications that could arise from overwriting all states.".

Which makes me think we can just close this one off.

What do the others think?

@MatissJanis commented on GitHub (Feb 15, 2026): Thanks for bumping this up @matt-fidd . I actually agree with @eduarbo. Especially on "The current solution might not be perfect, but it’s not bad either. [..] the inconvenience is minimal compared to the complications that could arise from overwriting all states.". Which makes me think we can just close this one off. What do the others think?
Author
Owner

@matt-fidd commented on GitHub (Feb 15, 2026):

Thanks for bumping this up @matt-fidd .

I actually agree with @eduarbo. Especially on "The current solution might not be perfect, but it’s not bad either. [..] the inconvenience is minimal compared to the complications that could arise from overwriting all states.".

Which makes me think we can just close this one off.

What do the others think?

I'd be happy to close it off, I've not heard it as a common complaint (at least that I can remember!)

@matt-fidd commented on GitHub (Feb 15, 2026): > Thanks for bumping this up @matt-fidd . > > I actually agree with @eduarbo. Especially on "The current solution might not be perfect, but it’s not bad either. [..] the inconvenience is minimal compared to the complications that could arise from overwriting all states.". > > Which makes me think we can just close this one off. > > What do the others think? I'd be happy to close it off, I've not heard it as a common complaint (at least that I can remember!)
Author
Owner

@youngcw commented on GitHub (Feb 15, 2026):

I don't recall any complaints on this since the feature was new.

@youngcw commented on GitHub (Feb 15, 2026): I don't recall any complaints on this since the feature was new.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#1228