Not possible to delete payee or category if present in deleted transactions

[whalley]

Following the implementation of #2963 it is not possible to delete:

• A payee that in use no where but in deleted transactions
• A category that in use no where but in deleted transactions

This may be confusing for users who are unfamiliar with this new feature or who never enable the view of deleted transactions.

Options:

• Live with what we have, and accept the possible confusion.
• Allow deletion of payees/categories that ONLY exist in deleted transactions (i.e. treat them as unused), and permanently delete any associated transactions
• Warn the user that the payees/categories are in use in deleted transactions and ask for confirmation before deleting them (and the associated deleted transactions).

[tactilis]

I think the safest and least surprising thing for the user, is your suggestion:

Warn the user that the payees/categories are in use in deleted transactions and ask for confirmation before deleting them (and the associated deleted transactions).

While on the topic of user confusion arising from the new Deleted Transactions functionality:

This may be confusing for users who are unfamiliar with this new feature or who never enable the view of deleted transactions.

I've raised #5298 , which discusses this.

[n-stein]

Fixed in PR #5307.

Deleting a category or payee used only in deleted transactions will now show a warning confirmation dialog. If the user proceeds both the selected category/payee as well as the associated deleted transactions are removed permanently.

[n-stein]

Do we need to add some kind of "Tip" saying the user can find the deleted transactions in the view found on the Nav Panel or enabled via View -> Show Deleted Transactions?

[vomikan]

Do we need to add some kind of "Tip" saying the user can find the deleted transactions in the view found on the Nav Panel or enabled via View -> Show Deleted Transactions?

Let's wait for a request from users.

[n-stein]

I think this needs to be reopened. On the v16 upgrade the columns are initialized with NULL, but the selection find(DELETEDTIME(wxEmptyString)) does not pick up NULL values, so you are able to delete categories which are used.

[n-stein]

Possible to change the v16 upgrade script to default to empty string?

alter table CHECKINGACCOUNT_V1 add column LASTUPDATEDTIME text default '';
alter table CHECKINGACCOUNT_V1 add column DELETEDTIME text default '';

[whalley]

Will need to create a v17 and upgrade from v16 to v17 as v16 is out in the wild now.

[n-stein]

It can be fixed by code. Instead of pulling using DELETEDTIME(wxEmptyString) we would have to pull all entries then loop through and check DELETEDTIME one at a time and break when it finds a blank/null value. Would this be cleaner than a v17 migration?

[whalley]

That code change should be fine. It's obviously less elegant/efficient but the check is done quite rarely anyway.

[n-stein]

PR #5336

[n-stein]

Shouldn't be much performance hit since all it needs to find is the first non-deleted transaction which is very likely the first in the data set.

[n-stein]

In the v17 upgrade script we can update NULL to '' then go back to the cleaner code in 1.6.2.

update CHECKINGACCOUNT_V1 set DELETEDTIME = '' where DELETEDTIME is null;
update CHECKINGACCOUNT_V1 set LASTUPDATEDTIME = '' where LASTUPDATEDTIME is null;