How do I save user profile changes that need to be approved before being sent live?
I'm trying to figure out how I should keep the edit a user makes to their profile in such a way that it doesn't go live or affect existing live data until it's approved by the admin. Do you have a second table for edited profiles, then copy the approval data? Store everything in one table and have a _tmp copy of all fields that can be edited? Is there a best practice for this?
Thanks for your thoughts.
source to share
For simplicity's sake, I often use some "status" column in the database to determine if a particular row is public. In your SQL, you would add
WHERE status = 'published'
This works well for simple sites.
For more busy sites, I suspect there are some performance benefits of not having this WHERE clause. Waiting for an edit on a separate table would be a good option and then you INSERT INTO ... SELECT FROM to move it to the table.
source to share
You can create a small workflow in your application. This way, you will have a Workflow table that will define various states (e.g., entered, proposed, approved, etc.).
Then you can also have a PendingChanges table that stores these proposed changes. When the proposed change is approved, you change the change to a change to the main user profile.
source to share
If you have many cases like this (in many different tables), you can have a TempObject table where you serialize changes to XML or some other state until they are approved.
Or, if it's just a user profile table, you can have a unique key in UserID + Approved (boolean). When a user edits their data, it goes into the table as UserID, Approved = false, and then approves it, you just delete the approved one and update the unapproved one (in a transaction of course).
After all, you already have a structure to hold all this data - why not reuse it?
source to share
It seems simple: you can add a VERSION and STATUS row to the USERS table. Then use the STATUS field to display the highest VERSIONed row if needed. Obviously, this gives you version control as well.
As long as VERSION and STATUS are indexed, they won't really slow down any display operations. Adding rows will be slower as indexes need to be maintained.
source to share
The second table, in the same format as the first, makes it difficult to make multiple changes easily.
I would recommend developing a specific structure for recording each change request as a change request. The fields for whom it changes, what changes, what, who made the request, when, etc.
Then enter the code to apply the change if / on checkout.
It can also be easy to track the audit.
I would not make changes to the same table, it ties implementations tightly together and makes subsequent maintenance a headache. Independence reduces how closely everything is connected for more flexibility in the future.
source to share