Hello DONATION beta testers and advisors. This post is following up the post at https://donationusers.wordpress.com/2014/09/26/web-proposal/ that gave a basic concept for a “Cloud Storage” feature. We have now largely designed it (but not yet programmed most of it!) and would invite any of you who feel so inclined to comment on the following technical description of the design.
The feature will also show up (later) in our bookkeeping program ACCOUNTS, but for now we are just talking about DONATION.
Just to summarize the idea, the Cloud Storage Feature is an optional feature, that is an extension of using Internet Backups to “Transfer your Data between Computers” (as explained in the Help topic with that title). The extension is that you could get a “reservation” of the database when you start DONATION, and then download the latest Internet backup (if you weren’t the previous user, which would indicate you already have the latest copy of the database). When you exited DONATION, you would upload your database to become the new latest Internet backup, and release the reservation. Under normal circumstances, only one user would be able to use the program at a time, because you could only get a reservation if nobody else currently had one. That would prevent the current potential problem of multiple people making changes on different copies of the database, that then cannot be merged.
The Cloud Storage Feature (also called Cloud Storage Solution) is only for users who use DONATION on multiple computers, and do not need simultaneous access. It would be a safer alternative to the current “Transfer your Data between Computers” methods, and also an alternative to using the Network version.
User Interface Changes
There would either be a new checkbox on the Backup/Restore -> Backup Frequency and Options window, or the Internet backups stuff on that window would be moved to a new Cloud Storage window, with a new checkbox. The new checkbox would be something like “Use Cloud Storage Feature”.
New Transactions on our Web Server
There would be new transactions that DONATION could invisibly call on the web server to do each of the following, as part of its procedures explained in more details below:
– Request Reservation (returns whether they got the reservation, whether they were the last one with a reservation, or whether someone else has the reservation). Also has option to break someone else’s reservation (details below).
– Check Reservation (checks that you still have your reservation that you made with Request Reservation)
– Release Reservation (releases a reservation that you make with Request Reservation)
Cases of Situations that we Need to Carefully Program
I should first note that we have introduced the concept of running the program read-only, where no changes can be made to any data, and the only menu options that can be used are ones that view data (like reports) but do not change it (like real receipts). There is also a new password you can set up for intentional entry to the program as a read-only user.
First Startup of Application (after installation on a new computer)
- Add option to Startup window to start by specifying Unique ID for Internet backups (ACCOUNTS already has that) and provide encryption password to immediately Request Reservation and restore latest Internet backup.
First Initial Setup of Cloud Storage Feature
- User chooses option in our user interface to turn on cloud storage feature.
- Tries to Request Reservation, response indicates that there’s no previous reservation file.
- Should they immediately send up a backup to match their starting point, or wait until they exit to do that? Wait until they exit – otherwise takes up unnecessary time.
Initial Setup when someone else has set up Cloud Storage Feature
- User chooses option in our user interface to turn on cloud storage feature.
- Tries to get a reservation, response indicates there’s a previous reservation file, they got the reservation.
- Prompt to confirm, then restore the last Internet backup and go on from there. (What if they say no? Give warning, can only work read only, unless change mind.)
- What if there is no last backup? (Another user set it up, but no successful upload yet.) Then behaves like when they are the first user to set it up.
Restore Backup with Cloud Storage Turned On
- User who doesn’t have cloud storage turned on restores a backup (whether from Internet, email, or on a USB etc.) which has it turned on.
- Immediately go back to as if just starting the program (try to get reservation etc.)
- Restore latest Internet backup if that isn’t the same filename as the Internet Backup they just restored (or if they just restored any other type of backup).
Normal Program Startup when Cloud Storage Turned On
- Enter program entry password if there is one.
- Unless they entered the program with a read only password, get reservation.
- If the response from Request Reservation indicated that they need to download the latest Internet backup (i.e. if they weren’t the last user who used it), prompt to enter the encryption password (if it is different from any program entry password). After that, download and restore latest Internet backup.
- Don’t prompt for program entry password again when open backup, unless the previously-entered one doesn’t match.
- This case assumes success!
Normal Startup when downloaded Backup is older than your data
- As usual, it will compare, and give you warnings about this.
- Option is to take it or not. If you don’t take it, and keep your newer database, yours will become the new official version once you upload it on exit.
Program Startup when no Internet or Problems
- Starts like normal startup with prompt for passwords
- No response to Request Reservation (Internet down etc.), or response is “BAD” (which should really only be in the case of a programming error)
- Offer options what to do – try again after fix Internet, or run read only.
- Should there be an option to run not read-only? NO.
Program Startup when Database in Use
- Starts like normal startup with prompt for program entry password.
- Response to Request Reservation indicates that someone else is using it.
- If last reservation is more than 12 hours ago, offer option to break reservation, explaining the implications (other user’s work is lost). If you break their reservation, the system will send them an email explaining that has been done.
- If last reservation is less than 12 hours ago, options are like when there’s no Internet.
- Give option in that case to bring down the latest backup first, if you are going to run read only. As usual, you will be prompted about whether to restore it if it is older than your data.
Program Startup when Encryption Password fails
- Start normally, get reservation successfully
- Download latest backup, decryption using entered encryption password fails, so can’t restore it!
- Prompt for additional tries at entering password.
- If give up on that (or after max 3 unsuccessful tries), release reservation, and go to options like when fail to get reservation.
Normal Program Exit when Have Reservation
- Don’t prompt again for encryption password, if you already provided it as part of the program entry.
- Check reservation to make sure we still have the reservation. (If not, tell user their work is lost! Should be very unusual, only if using DONATION for over 12 hours and someone else breaks their reservation.)
- Upload encrypted backup.
- If that was successful, release reservation.
- Options to retry unsuccessful parts on problems.
- If they exit without releasing the reservation and try again before anyone else tries, and Internet is now up, they won’t re-download the file (because they had the last reservation) so everything is OK.
Program Exit when running read only
- Don’t do anything special (don’t upload backup, don’t check or release non-existent reservation).
- Also applies if they entered the program initially with a read only password!
Change Encryption Password
- Since the program usually doesn’t prompt again for it on exit, and can’t change it on startup (won’t be able to restore!), need a way to change it.
- Add Maintenance -> Change Password -> Backup Encryption Password. (Can also change on program exit, if it prompts for the password at that time.)
- If change, big warning to inform all other users!
- Do like normal program exit before switch (upload database, release reservation).
- New switched-to database behaves as in normal program startup.
Restore a Backup
- Do like normal program exit before do that (upload backup, release reservation).
- If backup being restored is latest Internet backup (from before one was made as a result of the “normal program exit” steps) get the reservation after doing so.
- If backup being restored is anything else, ask what to do. Options are get reservation, or work read only, or allow changes but don’t save back to cloud storage afterwards.
- Here’s one case where we want to allows changes but not save back: you deleted old data (say 3 years back), need to temporarily restore backup including 4-year-old data, in order to create replacement receipt.
- Serious warnings for options other than working read only!
- This provides one way to get your version to become the master version again, for instance if you did work and weren’t able to have it saved because Internet was down, then someone else did some work (but your changes are more important than theirs!). Save a local backup, when you can run with Internet up again restore that backup (overwriting the one that is automatically downloaded) and go on.
- Doing this is also a solution for if you decide your latest work messed up the database.
Change Unique ID for Internet Backups
- The Unique ID determines, among other things, in what directory on the server the backups are stored.
- Do we really see any reason for allowing the Unique ID to be changed after it is first set up?
- Possible Reason: Take away access from people who no longer should have access. But can do that by giving new password, making 3 backups (because only the last 3 Internet backups are saved on the server).
- Danger if only some people change the Unique ID, they will be working on different versions of the database!
- So, don’t allow.
Everyone Forgets the Encryption Password
- Part of the solution to this might be if the last user can get in without providing the password, then they can change it later. That happens when Request Reservation returns the code saying we are the last user and thus we don’t need to download the backup, and thus it doesn’t need to prompt for the password.
- In that case, we would have to prompt for the password on program exit, which would give another way to change the password.
- If everyone has forgotten it, and they can’t find the computer that was the last user (or nobody was the last user – change of volunteer personnel), clearly need an option to just start with that user becoming the one who uploads the next official version and sets the password.
- Might be made better if people sent us their passwords, but then we really become a potential target. Don’t want that.
- Solution: We can provide a temporary override password like for lost program entry passwords. You can only override a startup that needs to restore a backup and can’t because of a wrong encryption password if you have that override password.
Use Same Password for Program Entry and Encryption
- Should this be an option? Yes.
- If it is, would only have to enter it once on program startup.
- However, doesn’t make sense if a read-only or limited user password has also been assigned (or gets assigned afterwards), because those users would then know the full program entry password (whether they were aware of it or not!) because they’d have to know the encryption password.
- So don’t allow this setup if already have a read-only or limited user password, and don’t allow creation of those passwords if the two main passwords are the same.
Turn off Cloud Storage
- Have to tell everyone to do so, circulate database with it turned off.
That’s it so far!
Please do not reply to this if you don’t at least largely understand it (which we don’t expect everyone to do!). Only reply if you can think of things we may have missed, things you don’t think will work, etc. Thank you.