Error in card type deletion

In a standard note type, when you ask to delete a card type at position (Card type ord), the confirmation message let you know the number the number of cards at position (Position in the selection menu) instead. This is a bug if you have already deleted card type, as the card type ord and the position in the selection menu differs.

I was going over some complex note type to check whether some card type were actually never used. There was one card type with 0 card, so I deleted it. Then, just to check, I click on delete on the next card type; I was informed that there was 0 card in it, so I deleted it too. And so on. After 4 card types with 0 cards, I started to be suspicious and cancelled everything. But I fear I did lost actual card type in previous instances of note type cleaning because of this.
(At least, I’ve found 25 notes which were lost, and where I had to go to back up to get the data back. It’s okay as I can script easily the resolution problem, but might be a big deal for other user)

Reproduction step:
Create a note type with three cards A B and C. Creates 1 note with card B and no card A nor C.
Delete card type A and validate. Then start deleting card type B. It should warn you that you’ll delete 1 card, actually it shows it will delete 0 card. Cancel. Delete note type C. It should warn you that it’ll delete 0 card, instead it shows that it will delete 1 card.

1 Like

I think the underlying problem is that the clayout dialogue is giving the template use counts as they were when the dialogue was opened. It doesn’t take into account the pending changes.
So when you remove a template that has just been added, the count will always be 0. If you modify a template in a way that the number of cards it creates changes, the deletion warning will not use this new use count.

I wonder what the ideal solution would be here? There could be a backend method to calculate the use count of the new template. However, the original use count could still be interesting to know.
Maybe the warnings should be removed entirely and instead, there should be a confirmation prompt when saving that summarises the numbers of cards that will be created and deleted?

I’m not saying it should be removed. The solution seems relatively easy.
It suffices to keep a map from version of the current model to the version of the previous model. Then, follow this map to find the position of the card type in the old model (or that it is a new card type)

Sure, but that doesn’t solve the shortcomings I’ve described.
The warning is also misleading because cards are actually only created/deleted upon hitting “Save”.

The old ordinals were already available, they just weren’t being used. I’ve pushed a fix to git.

Deleting a template immediately after adding it (before saving) would show 0 cards, not the count that will be added. I don’t think that’s a problem really, since there’s no risk of the user losing study data there, as the cards have yet to be created.

I wonder what the ideal solution would be here? There could be a backend method to calculate the use count of the new template.

I’m not sure this is adding much value? If the card generation changes to decrease the number of cards, they’re not going to get removed until the user uses the Empty Cards routine anyway.

Right, that’s true.

The warning might be confusing in this case, so maybe it should be skipped. But that is just an edge case.

More generally, I think the user shouldn’t be asked for confirmation until the changes are actually about to to applied to the database. Not a major issue, of course.

Thanks for the fix. I appreciate it

We can see in this case that Arthur’s using the confirmations to know how many cards would be removed before deciding to remove the template, so if we deferred the confirmation until saving, it wouldn’t be as easy to selectively make multiple changes.

One alternative would be to show the usage counts next to each template. That would dispense with the extra confirmation steps, but would mean the screen would be slower to load, and I’m not sure it’s worth the speed hit + changing the existing translations/implementation.