Hi,
>> -- 1:1 -- Action
>> Object -- 1:n -- Approval -- 1:1 -- Action
>> -- 1:1 -- Action
>
> All in one line:
>
> object -- 1:n -- approval -- 1:n -- action ?
yes, of course. Stupid me. :-) Forget it.
> My idea was this one:
>
> object -- 1:n -- action -- 1:1 -- signature
>
> action is in my understanding the operation (e.g. approval, deletion)
> plus the user information. So perhaps action is the wrong name. Perhaps
> the name approval or authorization for all is more correct. Ok, some
> definitions:
>
> APPROVED - is a state of OpenCA's object lifecycle
> DELETED - is a state of OpenCA's object lifecycle
> approval - is an action of an operator which authorizes data or a
> process information
>
> So let's name it approval and always remember that this is not identical
> with the state approved.
Hmm, the problem is that we have multiple different meanings of
'approval' here. What you are thinking of is
- the object remains unmodified in the database until the completion of
the process
- a number of 'action/operation/transition/modification' entries
are generated by each administrator
- the desired transition is indicated in the 'action/operation...'
entry ('approve', 'reject')
- the object is modified once the required number of transition objects
are available
I see some problems with this approach:
There is no clear indication of how the object should be modified,
because the transition type (approve, reject) is contained
in each 'action/operation...' handle.
Although it could be prevented by application logic, it is possible
to create inconsistent data:
object - action/operation...(1) -> "Approve"
action/operation...(1) -> "Reject"
What should we do now? The whole thing is ambiguos now, should we
approve it or reject it?
I was implicitly thinking of the approach we had in this other
project:
- object
- administrator wants to change object, modifies it and writes it
to another table of the database. let's call it the 'edit' state.
by looking at the differences
between the original object and the new one it is perfectly
clear what action is going to be performed on the object
- other administrators may acknowledge or reject this change
- one single reject results in deletion of the changed object in
the 'edit' state
- a number of n acknowledge entries for the change object triggers
promotion (copying) of the object in edit state to the original
table, replacing the original object
This is how we did it in the other project. The approach is very
clean but unfortunately not very easy to implement.
(We also had some performance issues in a later stage, but this
was because each and every object in the system had an 'edit' table
that was used to hold modifications until the modification was approved
by the required number of administrators. The performance problems
began when multiple objects depending on each other were transferred
between 'edit' and productive state.)
> Next question is the new state. If we start approving a pending request
> then this request is no longer pending and it is not approved. There is
> a state for exact this situation - signed. If we support multi approval
> mechanisms without signature then we should use another name than
> signing. Any ideas for a good statename?
How about 'edit' state...? :-)
Michael, Oli, how about a telephone conference about this issue?
I really think we have to get a clean design before we start messing
things up...
cheers
Martin
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
