CrowdAnki has been unnecessarily importing the deck_config_uuid into the Deck object (as opposed to the Deck Config object, which should and does have the deck_config_uuid (as its crowdanki_uuid)).
This would have been harmless duplication of information if it weren't the case that changing the deck config of a deck doesn't change the deck's "deck_config_uuid" and that the deck's deck_config_uuid "overrides" the deck config's crowdanki_uuid, resulting in the wrong deck_config_uuid being exported. (See #106, #116.)
Hence, we've decided to remove the deck_config_uuid from user's decks' Anki dicts (see #127). (To reassure any users reading this thread: it's only done during the export of a given deck, to avoid touching other decks unexpectedly.*)
* If you wish to check whether any of your decks have a `deck_config_uuid` and remove the `deck_config_uuid` for all your decks, immediately, just in case, see here.
To check whether any of your decks has a `deck_config_uuid`, paste this into the Anki debug console (accessible with `Ctrl-Shift-;`):
```python3
for x in mw.col.decks.all_names_and_ids():
if "deck_config_uuid" in mw.col.decks.byName(x.name):
print(f"{x.name} has a deck_config_uuid")
```
To remove the `deck_config_uuid` from all your decks:
```python3
for x in mw.col.decks.all_names_and_ids():
d = mw.col.decks.byName(x.name)
if "deck_config_uuid" in d:
del d["deck_config_uuid"]
mw.col.decks.save(d)
```
Actions (2022-06)
The code doing the removal of the deck_config_uuids (in crowd_anki/representation/deck.py) can and probably should be removed once we're confident that the removal has been carried out in most users' collections. I think June 2022 is a reasonable time-frame(?).
The exception handling for incorrect deck config (also in crowd_anki/representation/deck.py) might also be removed at the same time, or at least the error message adjusted, since if the error somehow re-appears it likely will be caused by something else.
Background
CrowdAnki
has been unnecessarily importing thedeck_config_uuid
into the Deck object (as opposed to the Deck Config object, which should and does have thedeck_config_uuid
(as itscrowdanki_uuid
)).This would have been harmless duplication of information if it weren't the case that changing the deck config of a deck doesn't change the deck's "
deck_config_uuid
" and that the deck'sdeck_config_uuid
"overrides" the deck config'scrowdanki_uuid
, resulting in the wrongdeck_config_uuid
being exported. (See #106, #116.)Hence, we've decided to remove the
deck_config_uuid
from user's decks' Anki dicts (see #127). (To reassure any users reading this thread: it's only done during the export of a given deck, to avoid touching other decks unexpectedly.*)* If you wish to check whether any of your decks have a `deck_config_uuid` and remove the `deck_config_uuid` for all your decks, immediately, just in case, see here.
To check whether any of your decks has a `deck_config_uuid`, paste this into the Anki debug console (accessible with `Ctrl-Shift-;`): ```python3 for x in mw.col.decks.all_names_and_ids(): if "deck_config_uuid" in mw.col.decks.byName(x.name): print(f"{x.name} has a deck_config_uuid") ``` To remove the `deck_config_uuid` from all your decks: ```python3 for x in mw.col.decks.all_names_and_ids(): d = mw.col.decks.byName(x.name) if "deck_config_uuid" in d: del d["deck_config_uuid"] mw.col.decks.save(d) ```Actions (2022-06)
The code doing the removal of the
deck_config_uuid
s (incrowd_anki/representation/deck.py
) can and probably should be removed once we're confident that the removal has been carried out in most users' collections. I think June 2022 is a reasonable time-frame(?).The exception handling for incorrect deck config (also in
crowd_anki/representation/deck.py
) might also be removed at the same time, or at least the error message adjusted, since if the error somehow re-appears it likely will be caused by something else.This issue tracks that removal.
Is there a "time-lapse" issue label?