Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Options group created from another options group inherits its uuid (minor issue) #118

Closed
aplaice opened this issue Feb 5, 2021 · 0 comments

Comments

@aplaice
Copy link
Collaborator

aplaice commented Feb 5, 2021

If you use Anki's interface for creating new options groups (or "deck configs" in CrowdAnki terms), by clicking on the cog next to a deck, selecting "Options" > "Options group" > "Manage" > "Add"*, then the newly created options group will be a "clone" of the previously selected options group.

* I think that this is the only way to create an additional options group, in Anki, without add-ons.

In particular, this means that the newly created "deck config" will inherit/share the crowdanki_uuid of its "parent" "deck config".

To reproduce

  1. Create and open a new Anki profile.
  2. Create a snapshot. ("File" > "CrowdAnki: Snapshot"). (Alternatively, you can use a CrowdAnki export of the Default deck, but snapshots are less clicks :)). (If you wish, you can create some notes first, but it's not necessary.)
  3. Inspect the deck_config_uuid (or alternatively the crowdanki_uuid in deck_configurations) of the snapshotted deck.
  4. Create a new options group (via clicking on the cog next to the Default deck > "Options" > "Options group" > "Manage" > "Add") and set it as the options group for the Default deck.
  5. Create a snapshot.
  6. Inspect the deck_config_uuid of the snapshotted deck.

(Tested with Anki 2.1.39, on Linux.)

Expected behaviour

The two deck_config_uuids are different.

Actual behaviour

The two deck_config_uuids are the same.

Further information

Alternative order

If you perform the actions in a different order — i.e. create a second options group and switch back to the first options group before the first snapshot, and switch to the already created second options group after the first snapshot, then the deck_config_uuids will be different.

(Full alternative order:

  1. Create and open a new Anki profile.
  2. Create a new options group (via clicking on the cog next to the Default deck > "Options" > "Options group" > "Manage" > "Add"), but switch back to the original ("Default") options group.
  3. Create a snapshot. ("File" > "CrowdAnki: Snapshot"). (Alternatively, you can use a CrowdAnki export of the Default deck, but snapshots are less clicks :)). (If you wish, you can create some notes first, but it's not necessary.)
  4. Inspect the deck_config_uuid (or alternatively the crowdanki_uuid in deck_configurations) of the snapshotted deck.
  5. Switch to the options group created in step 2.
  6. Create a snapshot.
  7. Inspect the deck_config_uuid of the snapshotted deck.

)

The deck_config_uuids are different, because the second options group was created before a UUID was assigned to the first options group, so the UUID was not copied over when "cloning".

(This suggests that this isn't an issue with the retrieving of assigned UUIDs, just a natural consequence of the way Anki creates new options groups.)

Anki source code context

The code for adding a new options group is here, and as one can see, the new group is cloned from the old one.

Severity

This is obviously a rather minor issue. It may often result in duplicate deck_config_uuids. This in turn might cause the wrong deck configuration to be selected when importing a deck whose subdeck is supposed to have a different options group than the parent.

(Note that the exported deck config "contents" (intervals etc.) is that of the correct options group — it's just that UUIDs are the same...)

Usually, however, I expect it to be harmless. I'm mainly reporting it because I noticed this while debugging #116 and started worrying whether it (this issue) is caused by a flaw in CrowdAnki's "logic" (as noted, it isn't, it's just that we don't work around the way Anki creates new options groups). Hopefully, I'll save other people this investigation. :)

Solutions

I think that using the deck_conf_did_add_config hook (and automatically changing the uuid, if needed) could solve the problem. However, due to the low severity, I'll first try to deal with more urgent issues.


Edit: The same issue holds for note models — when you clone a note model, the clone inherits the crowdanki_uuid of the original.

aplaice added a commit to aplaice/CrowdAnki that referenced this issue Jul 3, 2021
Fix Stvad#118.

Testing, it seems that I somehow haven't broken the tests despite
fiddling with anki/hook_vendor without adding to the overrides.

Note that disambiguate_crowdanki_uuid is not available as a "legacy"
hook, so the new hook mechanism has to be used.  It might (or might
not) be worth converting the existing hooks to the new mechanism.
aplaice added a commit to aplaice/CrowdAnki that referenced this issue Jul 3, 2021
Fix Stvad#118.

Testing, it seems that I somehow haven't broken the tests despite
fiddling with anki/hook_vendor without adding to the overrides.

Note that deck_conf_did_add_config is not available as a "legacy"
hook, so the new hook mechanism has to be used.  It might (or might
not) be worth converting the existing hooks to the new mechanism.
aplaice added a commit to aplaice/CrowdAnki that referenced this issue Aug 22, 2021
Fix Stvad#118.

Testing, it seems that I somehow haven't broken the tests despite
fiddling with anki/hook_vendor without adding to the overrides.

Note that deck_conf_did_add_config is not available as a "legacy"
hook, so the new hook mechanism has to be used.  It might (or might
not) be worth converting the existing hooks to the new mechanism.
aplaice added a commit to aplaice/CrowdAnki that referenced this issue Aug 22, 2021
Fix Stvad#118.

Testing, it seems that I somehow haven't broken the tests despite
fiddling with anki/hook_vendor without adding to the overrides.

Note that deck_conf_did_add_config is not available as a "legacy"
hook, so the new hook mechanism has to be used.  It might (or might
not) be worth converting the existing hooks to the new mechanism.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant