Is there a way to permanently change the underlying data of a flashcard without using the "edit" functionality?

[Eltaurus]

@ankipan

can you think of any way that users on e.g. ankidroid would be able to persistently modify the card content directly via the flashcard javascript?

AnkiDroid has its own JS API that provides some functionality unavailable on other platforms. I don’t think it has the capability to modify card data though, but I don’t follow its development closely, so you might want to take a look in case I’m missing something or the doc is incomplete.
AnkiMobile, on the other hand, is likely to be completely out of the question in this regard.

@ankipan

do you think it would be meaningful to propose or submit a PR for this kind of change to the Anki/Ankidroid repository, or is there maybe an aspect that has not been mentioned yet as to why this might not be such a good idea?

As far as I’m aware, API PRs are not very likely to get accepted at this point^[1][2][3]. Especially the functionality that involves access to the database for the security risks involved^[4].

---

1. Plan for JS API similar to AnkiDroid for Anki and AnkiMobile?

   I don’t feel like I can give this the attention it deserves at the moment, so I’d prefer to keep this on the backburner for a bit longer I’m afraid. I’d like for us to make a bit more progress on porting our screens to Svelte first, as that may also influence the API (for example, we may want to move the card area into an iframe to better isolate it, which may require message passing from the rest of the interface).

   ↩︎

2. Selective autoplay of audio for certain notes

   pycmd() is not public API, so I’m afraid this is not a change I’d like to accept at this time.

   ↩︎

3. API to show answer

   I’m afraid I’m not sure exposing such an API publicly is a good idea, as it has the potential to cause confusion if shared decks use it.

   ↩︎

4. Cross-platform JS addons for the reviewer

   One of the concerns I mentioned in the past is that there are security implications with exposing more functionality to JavaScript. It is still a problem - any endpoint we expose to the review screen will also be accessible by e.g. shared decks. We may be able to better isolate things by moving the card content into an iframe - it’s something to explore when more of the review screen gets moved into Svelte.

   ↩︎