Hi Everyone,
This isn't directly CSLA related, but I'm using the framework and I know there are a lot of smart people here. My scenario is the following. I have two types of users in a system "Admin" and "Researcher". The researcher is allowed to make changes to an existing record in a database, but the change should not show up in the official record until it has been "approved" by and admin.
Has anyone dealt with something like this in the past? I'm not sure where to start. Any suggestions greatly appreciated.
Here is a scenario. There is a Person table and Person object. The Person table has a record that looks like the following
ID FirstName LastName
1 John Doe
The Researcher changes "John" to "Jane", but this change shouldn't show up until it has been approved.
Thanks for any insight!
Hi reagan123
There is also the problem with concurrency around this issue and how long can a record stay in a dirty state waiting for 'approval'?
There are probably a number of ways to do this:
1. duplicate table (BO) and the duplicate is used to lock the original from change until the updated record is approved or rejected.
2. another table that only contains the diff (fields that have been changed) also used for locking the original record.
3. flag the record, with a new field, that when approved/rejected is set off
cheers
Just a few thoughts :)
From a generic standpoint, the easiest way to manage this is to have a set of "staging tables" that hold the pending changes. Then when your administrator approves the change, it's copied over to your final tables. Those staging tables can take a couple different forms, from copies of your originals to a single table that holds nothing but changes. But I would have some questions:
1. Do you allow unapproved changes to "stack up"? For example, if I change the record from "John" to "Jane", and then - before my change is approved - someone else changes it from "John" to "Jack", what happens?
2. Or, what happens if the person after me changes "Doe" to "Smith"?
3. As an alternative, if someone wants to change something that has a pending change already, do they see other users' pending changes (thus eliminating the potential concurrency issue)? And thus, would a researcher be allowed to change my "John-to-Jane" change to a "John-to-Jack" change? Or would it have to be a "John-to-Jane-to-Jack" change? That may be a semantic thing, but it could be an important difference.
4. What happens to pending changes after they are approved? Do they need to be kept around for auditing/history purposes?
Yes, some of these are basic concurrency questions. But the answers to them could provide some insight on what the staging tables might look like.
HTH
- Scott
This is also a good scenario for using workflow. Workflows work great for long lived objects that contain state (such as approved/pending), etc. At the database level you could add a status column and when the user requests approval, change the status to pending approval.
Thanks for the input so far. I'm definitely still trying to work out all of the different scenarios. I'll come back with some more details.
Thanks so far!
In line with the workflow concept, you'd likely have some objects who's only job is to move the item from one stage of the workflow to the next. Each stage in the workflow may actually have different objects. For example, I have a workflow which starts with Quotes to Orders to Invoices, and to move from one to the next I have a QuoteConverter and OrderConverter, which are BOs in their own rights with validation rules (usually tied to the state of the relevent document).
Copyright (c) Marimer LLC