Change Details

It is difficult to debug some of our more common OTRS complaints (such as losing saved articles) without more information. Can we add an option that allows the user (if they choose) to zip up their app container folder and Core Data database details and attach? We also discussed leaning on our event logging - every time we log via that system, we should also log to the file that is attached to a bug report. This will give us some breadcrumb details so we can see what path the user was on. **Update**: Decided not to mess with event logging at this point, and those tables are getting stripped out before the user shares for privacy purposes. I am exporting their synced reading lists and reading list entries as returned by the server, so we can compare both local and server-side data and see if anything is getting dropped between them.

It is difficult to debug some of our more common OTRS complaints (such as losing saved articles) without more information. Can we add an option that allows the user (if they choose) to zip up their app container folder and Core Data database details and attach? We also discussed leaning on our event logging - every time we log via that system, we should also log to the file that is attached to a bug report. This will give us some breadcrumb details so we can see what path the user was on. **Update**: Decided not to mess with event logging at this point, and those tables are getting stripped out before the user shares for privacy purposes. I am exporting their synced reading lists and reading list entries as returned by the server, so we can compare both local and server-side data and see if anything is getting dropped between them. === QA Steps === 1. Fresh install, log in. 2. Enable syncing via app Settings > Article storage and syncing. 2. Create some reading lists and save some articles. 3. Go to App Settings > Help and feedback. 4. Tap "Export User Data" button at the bottom 5. After a while, you should see a share activity sheet pop up. Airdrop the zip file to your machine. 6. Open the zip file, confirm you see data (console.log, Permanent Cache directory, User Data Export Sync Info json file, and some Wikipedia.sqlite database files). 7. Repeat steps 1-6 without being logged in, or without the toggle selected in step 2. You should still be able to export, but the User DataExport Sync Info json file will be more sparse since there's no remote server data to pull from. 8. Stress test some of these if you can - try a user with +500 saved articles and many reading lists.

It is difficult to debug some of our more common OTRS complaints (such as losing saved articles) without more information. Can we add an option that allows the user (if they choose) to zip up their app container folder and Core Data database details and attach? We also discussed leaning on our event logging - every time we log via that system, we should also log to the file that is attached to a bug report. This will give us some breadcrumb details so we can see what path the user was on. **Update**: Decided not to mess with event logging at this point, and those tables are getting stripped out before the user shares for privacy purposes. I am exporting their synced reading lists and reading list entries as returned by the server, so we can compare both local and server-side data and see if anything is getting dropped between them. === QA Steps === 1. Fresh install, log in. 2. Enable syncing via app Settings > Article storage and syncing. 2. Create some reading lists and save some articles. 3. Go to App Settings > Help and feedback. 4. Tap "Export User Data" button at the bottom 5. After a while, you should see a share activity sheet pop up. Airdrop the zip file to your machine. 6. Open the zip file, confirm you see data (console.log, Permanent Cache directory, User Data Export Sync Info json file, and some Wikipedia.sqlite database files). 7. Repeat steps 1-6 without being logged in, or without the toggle selected in step 2. You should still be able to export, but the User DataExport Sync Info json file will be more sparse since there's no remote server data to pull from. 8. Stress test some of these if you can - try a user with +500 saved articles and many reading lists.