Fix numeric deck and notetype names being treated as ids when importing csv #3748
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reported in https://forums.ankiweb.net/t/import-problem-deck-field-is-ignored-since-version-24-11
Fixes numeric deck and notetype names being treated as ids in
#deck:...
, or in the specified deck/notetype columnDeckIdsByNameOrId::get
,Collection::deck_id_by_name_or_id
andCollection::notetype_by_name_or_id
are modified to fallback to treating ids as names if said deck/notetype id is nonexistentModifying
Collection.deck_id_by_name_or_id
may seem redundant, as the metadata deck goes through DeckIdsByNameOrId::get anyway, but since its used by the import options page, it's kept for consistency when dealing with#deck:<numeric>
The only breakage I can think of is when an exporter exports notes from a deck with a name that's the same as one of the importer's decks' ids, in which case the deck with that id would be used instead of making a new deck with the id as the name. But this seems highly pathological, and is identical to existing behaviour regardless.