Martin Bartosch wrote:
nope, note the 1:n in front of action. One entry for each admin.
yeah, i think thats clear ;) - i maybe didn't rewrite this so clear
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.
no the object isn't floating, the object is in state 'edit' - and there it stays until the necessary steps (blackbox for the object) are done, to move it to another state
how can one request block another?requests that blocked others, but believe me, in field usage it pays to have a design that does not allow for inconsistent data.
my understanding is, that they get handeled independet from each
other... i mean the aproval, since mass aproving makes no sense, therefore are the operators wich have to review each request, if its not pre authenticated, but then is the request review just at a other time and at a another step in the processing of an request... (before the request is inserted into openca)
And multiple contradicting edit entries *are* inconsistent.the entries are only for this object - like in the 'edit' table, where the votings get 'captured' and handled by application logic, and this logic makes a dicission one time in the future, which leads to change of the 'edit' state of the object...
(actually this could handled soly by the database logic, but not all support this, so in the end our application logic has to do it... otherwise one could do this with triggers and db-scripting quite nice, but this is no option fur us i think)
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.)
but thats actually the same i mean, just with other words ;)
yes, since you won't ever circuumvent 'hacked' operator accounts, a reject kills - it has to, to make the application reliable in sense of, its hard to get an 'faked/malicious' certificate inOne 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.
of course, i mean, thats what i meant with: the object get 'locked' into 'edit' state until a decission - from 'voting' is made, in this second table, but the object itself is always in consistent state, just the decission making process gets handeld separate (black box for the object and its state)
but they can 'recall' it with a list like rejected requests... and lookNo need for this, I think.
up why it has been rejected
good
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.)
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.
ack
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.
yes, thats sounds good
-> Optionally the system could generate notification emails once a request is in the queue that needs approval.
this we have somewher on the todo - so should be integrated anyway this should be configurable: - every new request triggers a information - every n new requests triggers a information - at least one information per day/houre/$timespan (if n is not reached, so none gets 'lost' or a to high amount of time until processed)
the last two options is to avoid 'spamming' of the operators
but to guarantee 'deadlines' when request get 'announced' to them outside the system (by e-mail or other things), if an operator logs in - he gets always shown how many open issues are there for him to work on
* 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.
thats exactly what i wanted to say ;)
the processed flag has been just an idea for keeping knowledge about the decission process, if someone wants to see it outside the audit-trail ;)That way we should be able to do without the 'processed' flag, shouldn't we?
so the entries in the 'edit' table doens't get deleted, but 'ignored' since this object has been processed (not in state 'edit' anymore, an object is only alowed to leave state 'edit' if the 'edit' table is either clear of entries of it, or all entries are marked 'processed')
this means - your conclusion about the state change stays the same,
- if a veto operation (reject occurs) all entries in 'edit'-table get removed for this object and the object state changes,
- if all necessary 'votes' are there, the same happens
- if not - nothing happens
if we have the 'use-case' keep information about decission making process, the entries won't get deleted but marked processed
thats all ;)
this can be skiped or keeped - it won't change the general behavior if its not necessary to have this knowledge we don't put it in...
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
