All in one line: object -- 1:n -- approval -- 1:n -- action ?So what you propose is: -- 1:1 -- Action Object -- 1:n -- Approval -- 1:1 -- Action -- 1:1 -- Action
My idea was this one: object -- 1:n -- action -- 1:1 -- signature
there i would have some questions:
- which signature would stand in the end
and
- then, it is not clear anymore who did which action
- and the operator may not be 'liable' for it since
- he didn't sign his action
- ok this could be handled by a manipulation safed audit traili think there should be clear workflows for the openca instance defined by the user - there should be a default workflow:
object - action/operation...(1) -> "Approve"
action/operation...(1) -> "Reject"i think: in such a case, you have to define an operation that 'overwrites' others, so in a 1:n szenario, one reject may stop the whole thing in the default setup, a other instance may ona have this different, but would make it also more complicated in the application logic, to privode choosable ammounts of each operation... to wight them
but since we are in a security related area i like the 'failsafe' aproach more, means, one denies an operation - so reject kills, even if there may be 5 approve 'votes'
maybe we call this state 'voting' ;) - even if its no real voting, or its voting with veto - and reject is an veto operation
ah ok, i just see, martin wrote the same
but i think, why copiing, why not 'assign' or create a voting/edit table, mark the object to be in voting/edit state and have a reference to the object in the voting/edit table and catch all the operator 'votings' there
if a object is in edit/voting state it isn't allowed to change, untill the data in the edit/voting table is cleared up, means enough votings occured for this object and a decission is made...
- for example if the first veto voting occurs (in this case reject), the system can handle the object, all further operators will see then, it has been rejected, or they doesn't even see the request anymore, so less work for them
but they can 'recall' it with a list like rejected requests... and look up why it has been rejected
- since i think, why put several requests into the database - that makes no sense to me...
- to handle the idea of 'safing' the object changes, this may be done through the audit trail i think, or one may have another table:
object id - state - timestamp, but finaly this should be also in the audit trail... and therefore doesn't need to be done for every object again... or?
- so maybe we should have a clean and clear audit trail approach and look what can be handeld by it - so we don't have to think everytime again about this...
- the decission making process could be 'documented' in the audit trail too and additionaly (since this are cruicial operations) in the edit/voting table itself:
therefor the voting/edit table could have a column called: processed
if a object changes into the edit/voting phase through the first operator who 'votes' or by default, so operators get signaled - you have to vote a new request... - then the entries in the edit/voting table gets create through each voting-step of each operator, there the processed clumun is clear, if the first veto operation occurs or all necessary votings are there, all entries for this object get marked 'processed'
- so the object itself leafes the voting/edit afterwards and moves to its new state - depending on the decission made by the operators
just my 2 cents, what did your phone conference bring up`?
greetings dalini
------------------------------------------------------- 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
