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

Feature request: Export sort method by card and note creation time #108

Open
sudomain opened this issue Nov 24, 2020 · 3 comments
Open

Feature request: Export sort method by card and note creation time #108

sudomain opened this issue Nov 24, 2020 · 3 comments

Comments

@sudomain
Copy link

Spinning off #107, I think it'd be useful to have an option to export by card and note creation time. There's an add-on that can change the card creation time. Together with a CrowdAnki export sort method via creation time, the two add-ons could work well together for deck collaborators that need to change the order that cards appear in for new users.

The Change Creation Time add-on is a port of this add-on for 2.0 which notes in its 'Caveats' section:

Anki's browser displays cards, but the "created" date comes from the note. This addon affects the notes of the cards you select in the browser. Therefore, if a note has two cards, and you select only one, the note's creation date will be changed and reflected in two cards. Even though you selected one card it will appear that a card you didn't select was changed.

So maybe only sorting by notes.id from the database structure would be needed.

@aplaice
Copy link
Collaborator

aplaice commented Nov 24, 2020

This should be straightforward — just adding:

        NoteSortingMethods.NOTE_ID: lambda i: i.anki_object.id,

in crowd_anki/export/note_sorter.py

and

    NOTE_ID = "note_id"

in crowd_anki/config/config_settings.py, works. (I can create a pull-request for this.)

FWIW it seems that Anki's internal note sort order is by id (currently — AFAIK you shouldn't rely on any sort order, if it's not explicitly specified in the SQL query), even if you manually change the id of a note, so note_id has (currently) exactly the same effect as the none sort method.


However, given that currently CrowdAnki currently does not export the note id, and hence two different users won't have the same note id for the same note, I don't think that specifying the learning order in this way would be robust.

It would work exactly as desired, provided that only one collaborator was working on the deck (or provided that only the initial collaborator was always responsible for creating new notes and exporting the deck for "end users") — they'd edit their note ids and export the notes in the needed order.

However, once more than one person contributes and tries to change the order, this would start breaking down. For example:

  1. Collaborator A creates the deck and exports it (in the desired order).
  2. Collaborator B imports the deck. The notes are imported in the order in deck.json, so even though B's note_ids are all different from A's, they're still in the same order. (So far, so good.)
  3. Collaborator B changes the order, by changing some of the note_ids of existing notes, and exports the deck (in the new order).
  4. Collaborator A imports this deck. They already have the notes, so (irrespective of whether the content of the notes is changed or not), none of their note_ids are changed and they don't get the new order.

I'm not familiar/comfortable enough with CrowdAnki's design to authoritatively say whether allowing export/import of note ids would be a good idea, but it doesn't "feel" good. It would also be finicky to implement in a foolproof way — if the note id of an existing note changed, then on re-import the note id encoded in the associated cards (and possibly also the past reviews) would also have to be modified.

Obviously, as you described and as explored above, sorting by note id might still have some valuable even without exporting the actual note ids, so it might be worth implementing anyway.

@sudomain
Copy link
Author

Collaborator A imports this deck. They already have the notes, so (irrespective of whether the content of the notes is changed or not), none of their note_ids are changed and they don't get the new order.

This is certainly problematic especially when a logical next step is:
5. Collaborator A makes changes and goes to export with the wrong creation times

I think I have a semi-solution (feel free to critique): Any time a deck collaborator alters a creation time to change the order, they notify the other collaborators. The other collaborators would then delete their notes for that shared deck and do a full import of the new json. This has the unfortunate side effect of deleting the scheduling info for cards of collaborators. If the learning material is important enough for these people to collaborate on a deck, I'm willing to bet they would not enjoy regularly deleting any progress they make in their reviews. Therefor these collaborators should utilize a separate Anki profile so that they have a stable profile for reviews and a "dev" profile for collaborating on CrowdAnki decks.

aplaice added a commit to aplaice/CrowdAnki that referenced this issue Nov 26, 2020
@aplaice
Copy link
Collaborator

aplaice commented Nov 26, 2020

I think I have a semi-solution (feel free to critique): Any time a deck collaborator alters a creation time to change the order, they notify the other collaborators. The other collaborators would then delete their notes for that shared deck and do a full import of the new json. This has the unfortunate side effect of deleting the scheduling info for cards of collaborators. If the learning material is important enough for these people to collaborate on a deck, I'm willing to bet they would not enjoy regularly deleting any progress they make in their reviews. Therefor these collaborators should utilize a separate Anki profile so that they have a stable profile for reviews and a "dev" profile for collaborating on CrowdAnki decks.

Yeah, that would work. I think that the drawbacks you listed are sufficiently inconvenient that I personally would strongly prefer using an index/sort field, but I can see that some would still rather use the note id sort.

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

2 participants