Stvad
Incorrect mapping of Fields
Say I have A,B,C,D,E,F,G,H,I,J as fields. When I import from CrowdAnki, the suggested/default values of the field are: A,B,C,E,F,D,H,I,G,J. If I go and change the order to: A,B,C,D,E,F,G,H,I,J; there is no change executed after import. Once I check, it turns out that the fields that they initially were mapped to are retained and what I marked were not retained. Am I missing some import option or is this a bug?
Thanks for reporting and sorry about the bug!
Do you mean that in the "Change note type" import dialog (when you change the note type), in the "Fields" section, changing the mapping ("Change {X} to: {Y}") has no effect?
This does appear to be a bug! Yikes! (I don't think I've ever used/tested the Fields section, so I'm not sure when this regression occurred!)
Indeed, that's exactly what I mean. It seems to be the case for the card templates as well.
On Sun, 6 Apr, 2025, 23:58 aplaice, @.***> wrote:
Thanks for reporting and sorry about the bug!
Do you mean that in the "Change note type" import dialog (when you change the note type), in the "Fields" section, changing the mapping ("Change {X} to: {Y}") has no effect?
This does appear to be a bug! Yikes! (I don't think I've ever used/tested the Fields section, so I'm not sure when this regression occurred!)
— Reply to this email directly, view it on GitHub https://github.com/Stvad/CrowdAnki/issues/223#issuecomment-2781548000, or unsubscribe https://github.com/notifications/unsubscribe-auth/BN7EIUPMWV4F7ARIZRHYHED2YFW53AVCNFSM6AAAAAB2JMLH52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGU2DQMBQGA . You are receiving this because you authored the thread.Message ID: @.***> [image: aplaice]aplaice left a comment (Stvad/CrowdAnki#223) https://github.com/Stvad/CrowdAnki/issues/223#issuecomment-2781548000
Thanks for reporting and sorry about the bug!
Do you mean that in the "Change note type" import dialog (when you change the note type), in the "Fields" section, changing the mapping ("Change {X} to: {Y}") has no effect?
This does appear to be a bug! Yikes! (I don't think I've ever used/tested the Fields section, so I'm not sure when this regression occurred!)
— Reply to this email directly, view it on GitHub https://github.com/Stvad/CrowdAnki/issues/223#issuecomment-2781548000, or unsubscribe https://github.com/notifications/unsubscribe-auth/BN7EIUPMWV4F7ARIZRHYHED2YFW53AVCNFSM6AAAAAB2JMLH52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGU2DQMBQGA . You are receiving this because you authored the thread.Message ID: @.***>
AFAICT the cards mapping (top section) does still have an effect (testing with the latest Anki). If you remap card type X to card type Y, then your review history and scheduling for X will be transferred to Y.
If that's not the case for you, could you please provide more details (Anki version/OS etc.)?
Edit: The rest of my comment is wrong (or rather the analysis of the mechanistic behaviour is generally correct, but it's mostly working as it should be).
https://github.com/Stvad/CrowdAnki/blob/master/crowd_anki/representation/note.py#L123
self.anki_object.__dict__.update(self.anki_object_dict)
This causes self.anki_object.fields to be reset back to the (more-or-less) values it had before the field remapping. "More-or-less" because it's used in order to enforce the personal fields determined in the import config window (i.e. if a given field is marked as personal, then its value is not changed on import).
Unfortunately, it's not clear what's the right thing to do when one has both personal fields and a remapping of the fields. Which fields are the personal ones — the original ones or the new ones? Probably the correct approach would be to combine the two windows (import config and cards/fields remapping), which would make it clearer what's happening to the user, but that won't happen in the immediate future.
As a quick hack, I could check if there are any personal fields, and if there are none, then the fields won't be reset. (If this is something that is significantly bothering you.)
AFAICT the cards mapping (top section) does still have an effect (testing with the latest Anki). If you remap card type X to card type Y, then your review history and scheduling for X will be transferred to Y.
If that's not the case for you, could you please provide more details (Anki version/OS etc.)?
I'll try to replicate this, but it'll be a little while until I can do that (probably within a week though)
As a quick hack, I could check if there are any personal fields, and if there are none, then the fields won't be reset. (If this is something that is significantly bothering you.)
Yeah, that seems good. Is it also possible to add an outline to the checkbox for personal fields? I didn't know that checkboxes are used for this because that checkbox perfectly melds with the rest of the window (in night mode)
On further though, I've realised that I was confused about the field mapping.
The mappings are intended to apply to the existing cards/notes/fields.
For the card mapping, this means that the review history of the old cards is transferred to the new cards, according to the mapping. The actual contents of the cards (determined by the templates of the front/back side and the CSS) is, however, determined from the imported deck.
For the field mapping, OTOH, there is no attached review history etc., and (except for personal fields), the actual contents is overwritten by the imported deck.
This means that the field mapping is meaningless except possibly in the case when somebody uses personal fields. (It should also apply in the case when we're changing the definition of the note model, rather than the note model that applies to a given note, but AFAICT this does work correctly.)
The current card/field mapping UI is rather confusing and should be improved (probably as part of a unification with the import config window (the main advantages are a. a more consistent UI, b. allowing aborting a note model change, since the user would be deciding what to do before starting the import rather than this being done "on-the-go" (doing this in an efficient way might be tricky, though)).
It should also be decided what's the actual correct approach for personal fields when the note model is changed. (Currently they're completely ignored when changing the note type.)
I won't get around to either of these soon, though :(.
In terms of changing the order of fields, I'd recommend just using the standard Anki mechanisms (Tools > Manage Note Types > [Select note type] > Fields > [Select field] > Reposition).
Is it also possible to add an outline to the checkbox for personal fields? I didn't know that checkboxes are used for this because that checkbox perfectly melds with the rest of the window (in night mode)
You're right, this isn't discoverable in night mode! Thanks for bring this up! (Technically, there is an outline, but it's still black (like in light mode). On my system, Anki's night mode is dark grey, so the check box is just-about-visible, but probably only because I already know it's there!)
About the field mapping, something is amiss because I had issues when updating a note. Context: I have a field for details of Inorganic compounds with information about the compound such as name, formula, colour, structure, allotropes, etc. Initially, I had 15 fields and 62 cards. I created some more cards via CrowdAnki, giving a total of 92 with field replacements in them referencing the relevant field (they're of the sort "Answer 'Field1' knowing 'Field2'"). I also reordered the fields, thinking that it should all be merged anyways. When I go to import via disk, I get the menu showing the fields, but sets of fields were mismatched (they were all cyclic shifts because I moved one to a higher position in different sets). #222 is related to me being frustrated at not being able to shift all of them easily enough. When I finally finish that import, I check the card templates within Anki to come to know that the entire ordeal I went through was a wasted effort. All cards templates which had {{Structure}} in them were replaced with {{Allotropes}} (and what do you know, the default mapping of Allotropes was Structure, i.e. Allotropes occupied the same position as Structure did in an earlier version of the same notetype). It took me an entire afternoon and almost evening to reach to the correct method with all the imports being done properly (I had to resort to creating a new card type (clone of original), moving all cards to that notetype, reverting original to Basic and then importing via disk and then moving back to the original notetype (all done to maintain the guid)). To be precise, one of the most problematic mappings was {{Structure}}, {{Colour and State}}, {{Allotropes}} to {{Allotropes}}, {{Structure}}, {{Colour and State}} (I reference {{Structure}} in about 1/5th of the card templates, and using Find and Replace is not a simple option directly). Hence, this issue was created.
In terms of changing the order of fields, I'd recommend just using the standard Anki mechanisms
(Tools > Manage Note Types > [Select note type] > Fields > [Select field] > Reposition).
Yeah, this is what I had to end up doing for other notetypes.