Steps to reproduce:
Work around:
The backup system is not designed to open/edit/make changes, and then expect the sync to “notice those changes” - that is not how this works at all I’m afraid.
The backup system is designed to:
So it’s a backup system. Purely for backup/restore (of that same backup).
Downloading the backup zip, extracting it, then modify the XML inside, then restoring it, and expecting the system to notice just those changes: that is just not something we do at all. It is just a flat full import.
I’m not even sure how badly data could get messed up if you sync after that (and to be honest we should just block syncing in this case I think).
If you make a backup, and later restore it, you have to clear your database on all mobile devices and do a fresh down sync. But again: this is definitely not a route we would ever recommend users to do. You could seriously mess up things.
Have you ever found the “Edit Multiple tool”? What is it you’re actually trying to accomplish if I may ask?
Yes, I am aware of and use the multiple edit tool. Unfortunately, this tool is only useful for bulk changes to static values (change all prices to X with no variability of logic).
The problem I needed to address was to copy the index value into a JSON object within the personal notes field. In this case every record was changed to a unique value. This was done to allow searching on the index value (matches barcodes on all my books).
The bug I am reporting is actually mentioned in your reply and does not require modifying the backup file. A simple backup/restore will still trigger a full upload from the mobile device that would then overwrite data restored from the backup. The assumption that the data in the mobile db is the source of truth seems faulty. Extend this to running CLZ on multiple mobile devices (mine and my wife’s) and you can get some interesting results.
I am not sure if your sync algorithm views changes on a field or record level. Overwriting all data in a record when field(s) in a record have changed would make multi-device syncing a challenge IMHO.
I’m sorry but the export to XML/import from XML or even using backup/restore just isn’t meant to do this. Using backup/restore isn’t meant for syncing.
I do agree it is a bit weird that the mobile app thinks it needs to upsync everything after you restored a backup.
I’m happy to write up a feature request for your wishes on how to mass edit fields if you can explain what you need exactly.
Can you elaborate on that?
As far as I know, in that situation, the app detects that your cloud has been RESET and then ASKS you what you want to do.
It ASKS if you want to upload your local app database, which is the most logical situation for most users if they cleared their cloud.
The assumption that the data in the mobile db is the source of truth seems faulty.
The app only sees that the cloud has been cleared at some point, and ASKS you what you want to do. That is the only information the app has, that the cloud has been reset. The app does not know you put new data in the cloud, either by restoring a backup, importing a CVS, etc..
So the most logical suggestion for most users, if they DO have a database on the app and, probably, an EMPTY cloud, is to suggest that they UPLOAD their local app database. For 99% of cases, THAT is the way to go.
But you KNOW that is not a good idea, because you did restore a backup to the cloud, so you can just opt to NOT to follow that suggestion and instead go the other way, that is, CLEAR your app, and then DOWN sync your new cloud database.
Also, about the editing of the XML and then restoring…. That really is a round-about way to make changes to your database.
This is collection database software, completely designed to make managing your collection database as efficient and easy as possible. It would be very sad if one had to export to XML, modify the XML and then re-import for making changes.
The problem I needed to address was to copy the index value into a JSON object within the personal notes field.
I don’t think that is something the average user is doing
First, I will test the behavior with a regular backup. Second, I am not the first person to ask for the ability to search on index. My JSON hack is a work-around for this lack of functionality in the Web UI.
Yes searching for “index” is something that was requested and is on our request list. But you’re now using a JSON hack workaround because you can’t search for index? I thought you were doing a “edit multiple” for modifying notes and adding SKU there etc.?
After we had added hundreds of book to CLZ and then discovered that the index was not searchable, I wrote a script to copy the index to a JSON object in the backup XML file. I did not want to manually edit every record (hundreds).
Now we manually add the JSON to each record when new book are entered. We also add info like COA, limited to, and serial to the JSON object. Tags are great for Boolean info, but some custom fields need strings or integers. So the JSON hack has been expanded to provide dynamic custom, searchable, fields to CLZ.
Search: “sku”:”304423456”
Search: “LTD”:100
etc.
I will try to prioritize the Search by Index feature. We indeed see more requests for that from other. users.
Thx. I also have a write up for some suggestions to improve the awesome cover scan feature, but that requires a real keyboard not an iPhone. I will open a different chat,
Just wanted to let you know searching on the index field is now possible in CLZ Comics Web (just use the regular search box top right, type in an index number, hit enter and it should find any comic that has this number in it (including the index field).