How to Design Security - II
This is an attempt to present an alternative and more comprehensive Security Design based on ERP5s 5A Security Model. The document structure has been borrowed from HowToDesignSecurity . Once the document has been discussed and verified by the 'authorities' on this topic, it may be moved to the HowTo section upon their discretion.
Design process
To be able to implement security system, you have to first design it - which means two things:
a. designing rules stating who is authorized to do what under which conditions (this is a managerial decision) b. translating these rules into ERP5 vocabulary
A purchase order (PO) may be created by a Purchase Executive or a Purchase Manager. It is mostly 'draft'ed by a Purchase Executive. It can be 'order'ed by the either of them but only the Purchase Manager can 'confirm' it. Before a formal order is made it may be 'cancel'led by any one of them, but once ordered it can only be cancelled by the Purchase Manager. The system automatically generates a confirmed Paking list once the order is confirmed. A confirmed purchase packing list (PPL) goes through the stages of 'set-ready', 'start', 'stop' and 'deliver'. A PPL may be cancelled at any time except when the goods have been 'deliver'ed. For example the above stages may be defined as follows: set-ready - The goods are packed and ready for dispatch start - The goods have been shipped stop - The goods have reached the destination port deliver - The goods have been received by the purchaser A PPL may be marked as set-ready, start, stop or delivered by the Purchase Executive or the Purchase Manager. Purchase Manager may cancel the PPL at any stage, except after delivery. Any changes in the contents of the PPL can be made by either of them which shall result in a diverged state of the PPL as it shall no longer be consistent with the PO. Only the Purchase Manager is authorised to execute any of the divergence solvers on the PPL. Once a PPL is in the start stage a Purchase Invoice is generated. The Accounting Executive or the Accounting Manager also recieves the Commercial Invoice from the seller. Either of them can 'validate' the PI against the recieved Commercial Invoice.Once validated, the Accounting Manager 'closes' the PI.The Accounting Executive or the Accounting Manager can 'cancel' the PI when in 'draft' state, but once validated it can only be canceled by the Accounting Manager.The Purchase Executive or the Purchase Manager can view the PI at any point of time.ie. when PI is in any of the above states.
Roles, or who is who
Now, let's anyalyze it the ERP5-ish way: what we see here is that there are five designations/groups of people involved:
Purchase Manager |
Purchase Executive |
Accounting Manager |
Accounting Executive |
Business Auditor |
What are these five groups supposed to do in relation to the above process statement?
Purchase Manager |
has the final say with respect to PO and PPL, monitors purchase executive, reviews the PI |
Purchase Executive |
selects the goods and preapres draft order, reviews the PI |
Accounting Manager |
has the final say with respect to PI, Accounting and monitors the accounting executive |
Accounting Executive |
processes the PI |
Business Auditor |
monitors everything for adherence to regulations |
When we translate it into the "5A" roles, it all fits very nicely:
Purchase Manager |
has the final say with respect to PO and PPL, monitors purchase executive, reviews the PI |
Assignor on PO, PPL, Associate on PI |
Purchase Executive |
selects the goods and preapres draft order, reviews the PI |
Author on PO, Assignee on PO, PPL, Associate on PI |
Accounting Manager |
has the final say with respect to PI, Accounting and monitors the accounting executive |
Assignor on PI |
Accounting Executive |
processes the PI |
Assignee on PI |
Business Auditor |
monitors everything for adherence to regulations |
Auditor on PO, PPL, PI |
The Purchase Executive has to be an associate on purchase invoice so that goods invoiced for can be verified against goods received..
Workflow
The Purchase Order(PO) is first created.Once the PO is confirmed, the system automatically generates a confirmed PPL. Once a PPL is in the start stage a PI is generated. We can now design a workflow, which has states and transitions. From a process point of view, there is one rule: if the process enters a different phase, it means a change for the corresponding document's state.
A purchase order (PO) which may be created by a Purchase Executive or a Purchase Manager is initially in a draft state.It can be ordered by the either of them.The system automatically generates a confirmed Paking list once the order is confirmed The various states for a PO are as follows:
Draft |
|
Order |
|
Confirmed |
|
Cancel |
|
It should now be pretty easy to fill the second column with roles and permissions (V means "view", M means "modify") for the PO Module:
Draft |
Author(M), Assignor(V,M) ,Auditor(V) |
Order |
Assignor(V,M), Assignee(V,M) ,Auditor(V) |
Confirmed |
Assignor(V), Assignee(V), Auditor(V) |
Cancel |
Assignor(V), Assignee(V), Auditor(V) |
The last question we must ask ourselves, is who can make workflow transitions? The process statement is quite clear about that, so let's draw a table:
Draft--->Order |
Assignor, Assignee |
Draft--->Cancel |
Author, Assignor, Assignee |
Order--->Confirmed |
Assignor |
Order--->Cancel |
Assignor |
Once,the PO is confirmed, a confirmed PPL is generated. It can have the following states
Confirmed |
Assignor(V,M),Assignee(V,M),Auditor(V) |
Assignor(V,M),Assignee(V.M),Auditor(V) |
|
Start |
Assignor(V,M),Assignee(V.M),Auditor(V) |
Stop |
Assignor(V,M),Assignee(V,M),Auditor(V) |
Deliver |
Assignor(V),Assignee(V),Auditor(V) |
Cancel |
Assignor(V),Assignee(V),Auditor(V) |
For Diverged PPLs
Diverged |
Assignor(V,M),Assignee(V,M),Auditor(V) |
The workflow transitions can be shown as
Confirmed--->SetReady--->Start--->Stop |
Assignor,Assignee |
SetReady--->Cancel |
Assignor,Assignee |
Start--->Cancel |
Assignor,Assignee |
Stop--->Cancel |
Assignor,Assignee |
Stop--->Deliver |
Assignor,Assignee |
Confirmed--->Cancel |
Assignor |
For Diverged PPLs the following transitions apply as per the process statement
Diverged-->SolverAction |
Assignor |
Once a PPL is in the start state a PI is generated.The states for a PI are as follows:
Draft |
|
Validate |
|
Close |
|
Draft |
Assignee(M,V),Assignor(M,V) |
Validate |
Assignee(M,V),Assignor(M,V) |
Close |
Auditor(V),Assignor(V),Assignee(V) |
The workflow transitions can be shown as
Draft--->Validate |
Assignee,Assignor |
Draft--->Cancel |
Assignee,Assignor |
Validate-->Close |
Assignor |
Validate--->Cancel |
Assignor |
to be continued...