Change Details

Be on the latest diff if this stack to ensure there is no mechanism from the keyserver that would aid entry persistence. After testing each actions kill the app and reopen it to ensure that changes are correctly persisted. 1. To test `fetchEntriesActionTypes.success`: click history on calendar entry in Web 2. To test `updateCalendarQueryActionTypes.success`: create entry on web in a distant month in the past and then scrolling calendar in native to that date. Ensure that new entry appeared in the DB after scrolling close to the date. 3. To test `createLocalEntryActionType`: create entry and ensuring that it appears in the DB immediately and has local id. 4. To test `saveEntryActionTypes.success`: edit and save entry on web. 5. To test `deleteEntryActionTypes`: delete entry and check in SQLite that deleted property is marked as true and entry is not visible across app restarts. 6. To test `restoreEntryActionTypes.success`: Delete and restore on web. Reopen the app between steps, and ensure that changes are persisted. 7. To test `legacyLogInActionTypes.success`, `legacySiweAuthActionTypes.success`, `keyserverAuthActionTypes.success`: log in and log out and seeing that entries are in db after logging in back. 8. To test `incrementalStateSyncActionType`: background mobile app, do something in calendar on web and foreground the app again. 9. To test `processUpdatesActionType`, `joinThreadActionTypes.success`, `newThreadActionTypes.success`: modify entry on web and see immediate update (UI and DB) on native. 10. To test `fullStateSyncActionType` by a hack: Go to `socket.js`  in `keyserver`, change condition in line 515 to be true, kill the native app, modify calendar on web an open the native app. 11. To test `changeThreadSettingsActionTypes.success`, `removeUsersFromThreadActionTypes.success`, `changeThreadMemberRolesActionTypes.success`: Create community as user A, add user B, create entry and delete user B. Check that entry disappears from B database. 12. To test `processServerRequestsActionType`: This actions is dispatched a short while after creating entry when it transitions from local to remote. 13. To test `setClientDBStoreActionType`: restart the app and see that entries are in calendar

Be on the latest diff if this stack to ensure there is no mechanism from the keyserver that would aid entry persistence. After testing each actions kill the app and reopen it to ensure that changes are correctly persisted. 1. To test `fetchEntriesActionTypes.success`: click history on calendar entry in Web 2. To test `updateCalendarQueryActionTypes.success`: create entry on web in a distant month in the past and then scrolling calendar in native to that date. Ensure that new entry appeared in the DB after scrolling close to the date. 3. To test `saveEntryActionTypes.success`: edit and save entry on web. 4. To test `deleteEntryActionTypes`: delete entry and check in SQLite that deleted property is marked as true and entry is not visible across app restarts. 5. To test `restoreEntryActionTypes.success`: Delete and restore on web. Reopen the app between steps, and ensure that changes are persisted. 6. To test `legacyLogInActionTypes.success`, `legacySiweAuthActionTypes.success`, `keyserverAuthActionTypes.success`: log in and log out and seeing that entries are in db after logging in back. 7. To test `incrementalStateSyncActionType`: background mobile app, do something in calendar on web and foreground the app again. 8. To test `processUpdatesActionType`, `joinThreadActionTypes.success`, `newThreadActionTypes.success`: modify entry on web and see immediate update (UI and DB) on native. 9. To test `fullStateSyncActionType` by a hack: Go to `socket.js`  in `keyserver`, change condition in line 515 to be true, kill the native app, modify calendar on web an open the native app. 10. To test `changeThreadSettingsActionTypes.success`, `removeUsersFromThreadActionTypes.success`, `changeThreadMemberRolesActionTypes.success`: Create community as user A, add user B, create entry and delete user B. Check that entry disappears from B database. 11. To test `processServerRequestsActionType`: This actions is dispatched a short while after creating entry when it transitions from local to remote. 12. To test `setClientDBStoreActionType`: restart the app and see that entries are in calendar

Be on the latest diff if this stack to ensure there is no mechanism from the keyserver that would aid entry persistence. After testing each actions kill the app and reopen it to ensure that changes are correctly persisted. 1. To test `fetchEntriesActionTypes.success`: click history on calendar entry in Web 2. To test `updateCalendarQueryActionTypes.success`: create entry on web in a distant month in the past and then scrolling calendar in native to that date. Ensure that new entry appeared in the DB after scrolling close to the date. 3. To test `createLocalsaveEntryActionType`: create entrys.success`: edit and ensuring that it appears in the DB immediately and has local idsave entry on web. 4. To test `saveEntryActionTypes.success`: edit and save entry on webdeleteEntryActionTypes`: delete entry and check in SQLite that deleted property is marked as true and entry is not visible across app restarts. 5. To test `deleteEntryActionTypes`: delete entry and check in SQLite that deleted property is marked as true and entry is not visible across app restartsrestoreEntryActionTypes.success`: Delete and restore on web. Reopen the app between steps, and ensure that changes are persisted. 6. To test `restoreEntrylegacyLogInActionTypes.success`: Delete and restore on web., Reopen the app between steps`legacySiweAuthActionTypes.success`, and ensure`keyserverAuthActionTypes.success`: log in and log out and seeing that changentries are persistedin db after logging in back. 7. To test `legacyLogInincrementalStateSyncActionTypes.success`, `legacySiweAuthActionTypes.success`e`: background mobile app, `keyserverAuthActionTypes.success`: lodo something in and log out and seeing that entries are in db after logging in backcalendar on web and foreground the app again. 8. To test `incrementalStateSyncprocessUpdatesActionType`: background mobile app, `joinThreadActionTypes.success`, do something in calendar`newThreadActionTypes.success`: modify entry on web and foreground the app againsee immediate update (UI and DB) on native. 9. To test `processUpdatesActionType`fullStateSyncActionType` by a hack: Go to `socket.js`  in `keyserver`, `joinThreadActionTypes.success`, `newThreadActionTypes.success`: modify entry on web and see immediate update (UI and DB) on nativechange condition in line 515 to be true, kill the native app, modify calendar on web an open the native app. 10. To test `fullStateSyncActionType` by a hack: Go to `socket.js`  in `keyserver`changeThreadSettingsActionTypes.success`, `removeUsersFromThreadActionTypes.success`, `changeThreadMemberRolesActionTypes.success`: Create community as user A, change condition in line 515 to be trueadd user B, kill the native app,create entry and delete user B. modify calendar on web an open the native appCheck that entry disappears from B database. 11. To test `changeThreadSettingsActionTypes.success`, `removeUsersFromThreadActionTypes.success`, `changeThreadMemberRolesActionTypes.success`: Create community as user A, add user B, create entry and delete user B. Check that entry disappears from B databasprocessServerRequestsActionType`: This actions is dispatched a short while after creating entry when it transitions from local to remote. 12. To test `processServerRequestsActionType`: This actions is dispatched a short while after creating entry when it transitions from local to remote. 13. To test `setClientDBStoreActionType`: restart the app and see that entries are in calendar