0

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?

  • Have you been able to ask them why they don't want it to touch the DB? If so, what did they say? – Becuzz Oct 9 '13 at 14:53
  • The idea is that if a user creates a "draft" then admin users are unable to create one too, unless they first reject the user's draft. – Captain Kenpachi Oct 9 '13 at 14:58
  • So if I understand this correctly, each user can only have one "draft" of changes open for their account at any given time? Why can there only be one draft at a time? Or why couldn't there be one open admin draft and one open user draft at a time (and then have some kind of conflict resolution page when it comes time for approval)? – Becuzz Oct 9 '13 at 15:16
  • Because "conflict resolution" is a huge chunk of work. – Captain Kenpachi Oct 9 '13 at 16:07
1

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.

  • That's a good idea. Cookie is a no-no because the storage is too limited, but browser storage may be just the thing. – Captain Kenpachi Oct 9 '13 at 16:07
  • 2
    If it's stored on the browser, how would the admin see it to approve? – Michael Brown Oct 9 '13 at 16:18
1

Rather than storing changes in a series of tables, store them as a document that your application will know how to render. When the admin views the draft, the application will render it (and possibly highlight the differences between the original and the proposed change). Finally when the draft is approved, the document is applied to the DB, pushing the changes from the draft into the permanent data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.