feat(categories)!: Ability to delete Categories and consequences on transactions and recurring transactions

[napitek]

Description

In reference to the issue #177
with this PR there is the possibility of deleting categories while retaining transactions and recurring transactions.
There are two ways:

• Mark a category as deleted: all old transactions will still be displayed everywhere, but it will not be possible to create new ones with the category marked
• Delete the category definitively: this converts all transactions and recurring transactions by changing the category to Uncategorized.

Technical details

For IN and OUT, there are now two reserved “Uncategorized” system categories, with respective gray color, inserted within the color list.
These categories are not editable, but can be used, if there is a need to enter transactions without a specific category.

When trying to delete a category from the settings, a Dialog appears that looks like this:

For @federicopozzato and the design team, I tried to keep the style already used on other occasions. Free to come up with something more appealing (e.g., some loaders while the reassignment process proceeds), as well as the gray and the icon for the category “Uncategorized”

In the planning section, you cannot choose the “Uncategorized” category, since I think it is useless in this case. If there is a need for a separate category, you create it custom

[federicopozzato]

Thanks @napitek. We will review this issue in our meeting and we will add it to our task list.

Regarding the type of behaviour you suggest to adapt, I prefer the first one (Mark a category as deleted: all old transactions will still be displayed everywhere, but it will not be possible to create new ones with the category marked). I also suggest that in the future, when you add a transaction and you select a category, the deleted one will not be present on the list anymore.

[mikev-cw]

Ok the overall approach seems good to me!

A few things on edge cases.

1. Should we let the user intentionally add an “uncategorized” transaction? Or should we keep them as system reserved? Just asking, I’m not sure. Also I don’t like all that grey when i add a new transaction. Since the uncategorized ones are lowest IDs, the’ll be always on top.

3. If i mark a category as deleted, then I create a new category with same name, color, type, and icon, i will see no differences between transactions with old and new category, because they are visually the same, but on statistics i will see a double stats for apparently the same category. Again not sure on how we can handle this.

4. There’s something wrong with transfers, not sure if is related to this PR. While the icon is correct, I see them as “uncategorized” (I think it should say “transfer” somehow)

5. When a category is marked for deletion, i can create a transaction with that category (I see them all basically, also dupes).

6. Notices some weird behaviors on iOS, but I’m not sure it was my sim, or what. I’ll just retry next days, or when we fix prev points.

7. There's no point 2 in this list 😎

[napitek]

1. Should we let the user intentionally add an “uncategorized” transaction? Or should we keep them as system reserved? Just asking, I’m not sure. Also I don’t like all that grey when i add a new transaction. Since the uncategorized ones are lowest IDs, the’ll be always on top.

Not really. My initial idea was to totally hide the ability to create a transaction or edit it with “uncategorized.” Then I thought of the case where a person enters transactions so as not to forget them, and if he arranges them with categories when he has more time.
Of course... the problem can be solved by putting a “limbo” category if it is of interest.

3. If i mark a category as deleted, then I create a new category with same name, color, type, and icon, i will see no differences between transactions with old and new category, because they are visually the same, but on statistics i will see a double stats for apparently the same category. Again not sure on how we can handle this.

I noticed this myself, but I honestly see two paths:

• we cannot create a category if there is another category with the same name. However, this creates several problems, including the management of categories marked as deleted and the fact that many people, including me, are very indecisive in life and will probably want to enter another one with the same name with a longer or shorter time delay. This could all be solved, however, e.g. with the introduction of subcategories.
• markedAsDeleted categories receive a new name and, if desired, even a defined color or tag. This way they can be displayed in the charts without any problems.

4. There’s something wrong with transfers, not sure if is related to this PR. While the icon is correct, I see them as “uncategorized” (I think it should say “transfer” somehow)

I hadn't noticed. I'll look at it

5. When a category is marked for deletion, i can create a transaction with that category (I see them all basically, also dupes).

not true! check more closely 😜

I refreshed the page 3 times because I couldn't find point 2

[federicopozzato]

Should we let the user intentionally add an “uncategorized” transaction? Or should we keep them as system reserved? Just asking, I’m not sure. Also I don’t like all that grey when i add a new transaction. Since the uncategorized ones are lowest IDs, the’ll be always on top.

I'd keep things simple and not create an "uncatecorized" category.

If i mark a category as deleted, then I create a new category with same name, color, type, and icon, i will see no differences between transactions with old and new category, because they are visually the same, but on statistics i will see a double stats for apparently the same category. Again not sure on how we can handle this.

I agree on what @napitek said: we have to think to a way to differentiate a deleted category that will still be present in the statistics. I suggest a tag/chip to be added alongside the category name, and a kind of visual representation (like a disabled state).

If you guys give us some time we are planning to put this issue at the top of our design todo list.

[mikev-cw]

Not really. My initial idea was to totally hide the ability to create a transaction or edit it with “uncategorized.” Then I thought of the case where a person enters transactions so as not to forget them, and if he arranges them with categories when he has more time.

Since the user is always required to add the category for adding a transaction, i don't see how selecting "uncategorized" instead of something else could speed up the process. It would be different if "uncategorized" was preselected by default, but I think it would encourage users to add too much noise and crap data. Generally i agreed with @federicopozzato

markedAsDeleted categories receive a new name and, if desired, even a defined color or tag. This way they can be displayed in the charts without any problems.

Yes! This would be a simple and brilliant solution! I suggest same icon and name, but grey color and an icon/tag suggesting this is a deleted category. But last word to our designers ofc.

We did something similar with with recurring transactions

(Oh... seems we found our missing point 2! 🤔)

[napitek]

• I will keep the uncategorized category, but without being able to select it when creating a new transaction
• We wait for the graphic part of the tags in categories, and then implement it in the PR

is that okay? @mikev-cw @federicopozzato

[mikev-cw]

@napitek Since I've merged #291 you need to add a migration for changes on db. This also creates a conflict ofc. I can help you with that, reach me if you want

[federicopozzato]

@napitek If you want you can proceed with what we said even if there's no design for it. We will catch up with that in the following weeks, but in the meantime you can go on.

[napitek]

@mikev-cw @federicopozzato
to stall until the graphical handling of deleted categories or tags, I modified RoundedIcon to contain a “markedAsDeleted” flag.
If it is true, a small icon appears at the bottom right of the category icon.
At least you can see whether it has been deleted or not.

[napitek]

@mikev-cw @theperu
there is another problem that we have not discussed. What happens to budgets when I delete a category?
Does it make sense to mark them as Uncategorized? In my opinion, no.
Maybe show another popup that says “Delete corresponding budgets?”

[theperu]

We should delete the budget if the corresponding category is deleted. Showing another pop up is not great but it'll be ok for now

[lucaantonelli]

I have some point for improvements:

• maybe "markedAsDeleted" is too verbose, could just be named "deleted"
• since we implemented the migration system, we should never edit a migration already existing, since it is not going to be executed again for everyone having the app already installed, you must create a new migration

[napitek]

@lucaantonelli "markedAsDelete" just to distinguish from true deletion (with the delete button). it's not a problem to edit it obviously.
Regarding migrations, I changed the current migration, to rearrange the schema, since it is new.
Do you say create a migration specifically to make the changes? A sort of patch the db each time?

[mikev-cw]

There's a problem in migration 5:
Users who don't have the demo data (i.e. they went through onboarding by adding a budget, or started from scratch and added a category afterwards) already have a categoryTransaction with ID 1, so this query fails and the app doesn't open.

There are two ways to fix it:

1. We allow those categories to have any ID (I don't remember if they must be 0 and 1), and let the auto-increment assign them.

2. Before running the query, we check if category ID 1 already exists, and if so, we assign it a different ID and update all associated transactions. Only then we insert the new categories with IDs 0 and 1.

Any other ideas?

[theperu]

Hi @napitek👋
We recently merged a PR that changed the folder structure, which caused some conflicts here. When you get a chance, could you take a look and resolve them?

If there’s no response in the next 15 days, we’ll consider this PR inactive and plan to close it to keep things tidy.

Thanks!