I have a requirement to allow users to suggest updates to their profiles on a site I'm working. They would be able to view their profile details, then click on and "edit" button, which would basically make a copy of all their data contained in a handful of one-to-many related DB tables. They can then add or remove items and update various text fields before saving the draft. Upon saving, an administrator would have to approve this change before the new data is actually published onto the live site.
I currently have an identical set of tables for live data and drafts (and history, but that's not important). My difficulty is that the client doesn't want an actual draft entry created in the drafts db structure until the user has hit "save". A user would be able to perform CRUD operations against all the data, including uploading new images, but I am not allowed to touch the DB unless they're ready to commit these updates.
My great problem is that I have no idea how to begin developing what seems to the client to be a very simple thing, even though it's technically quite challenging. I also can't seem to make the client understand that hitting the "Cancel" button next to the save button would remove the entry plus all its related data from the DB, making the problem moot in my humble opinion.
So, the question is such: is there a way to phrase my objection in such a way that the client can understand what I'm getting at. Or failing that, what would be a good way of developing such a session-stored object?
Best Answer
You could try storing client drafts in a cookie or the browser's web storage, that way the clients have the drafts 'persisted' but they aren't in the database.