Quote:
Originally Posted by JimmXinu
I take it back.
The add_marked_ids() method only supports marked:true. It discards both pre-existing and new mark names and calls them all 'true'. Marks used to be only on/off--named Marks where a later add-on.
So the only option I see is to use the db.data.marked_ids dict directly to see what marks already exist and set them again as well.
Looking directly at the data structures instead of using an API is sketchy, even if that's how actions/mark_books.py does it.
Further thought then raises the question: What should happen when a new FFF mark would go on the same book as a pre-existing mark? Which should take priority? The whole point was to preserve pre-existing marks and now we can't guarantee it?
This is the point where I'm thinking it's not worth the effort. Marks are intentionally transient in nature. Use a column value or a Reading List if you want something that is more durable.
|
I agree that it's not worth the effort. Thought you were deliberately calling a clear function so it would be easy to disable