Hi, >> 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
nope, note the 1:n in front of action. One entry for each admin. > 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 IMO we should really prevent having more than one object floating in edit state at any time. This problem always comes up with dual control. We did the same in our other project and also had the problem of requests that blocked others, but believe me, in field usage it pays to have a design that does not allow for inconsistent data. And multiple contradicting edit entries *are* inconsistent. > 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 I would rather not call it voting. I also propose not to allow anything different than a 100% agreement on any change. (This is consistent with various legislatory requirements that are in effect e. g. for banks.) One single denial should cause the whole operation to be rejected. Of course this *could* be abused for DOS attacks, but as admins are usually trusted and rejections leave an audit trail, this problem can be addressed formally. > - 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 The request should be removed from the edit state. > but they can 'recall' it with a list like rejected requests... and look > up why it has been rejected No need for this, I think. > - since i think, why put several requests into the database - that makes > no sense to me... agreed > - 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? The application shouldn't normally read the adit trail itself. In fact, it could even be implemented write-only for the application. (Then another (auditing) system could open the database read-only for the audit trail.) > - 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... See above, I don't think we should abuse the audit feature that way. Reason is that some time in the future we will notice that there is this-and-that that is not present in the audit trail information and then start messing around with it. The audit stuff should be separated from any appliation logic. > 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 How about this: * detection of pending changes waiting for additional approval -> Once an administrator logs on the system gets a list of all changes in edit state that need approval (and that have not yet been approved by this admin). It presents a list of all pending requests or better yet, a notification indicating how many pending requests are there that need attention. -> Optionally the system could generate notification emails once a request is in the queue that needs approval. * state change -> after each approval the system checks if the required number of approvals have been applied. If so, the change is committed into production state. Otherwise no operation. If the operation was a rejection, the change is immediately removed. That way we should be able to do without the 'processed' flag, shouldn't we? > just my 2 cents, what did your phone conference bring up`? what phone conference...? :-> 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
