Arbitration Tool
Preface
In her Email Eva wrote:
“I would like to propose the following: Deleting accounts is now done by support without much arbitration interaction. But the DRP tells us that one may not ask for termination of membership as long as one is involved in an arb-case. For this all delete procedures somehow stated that support should check this somehow, but we have no technical way to do this. So it would be good to have a tool for this, so that a) arbitration could add the names and email addresses of people involved in a case and b) support could enter a name/email of someone who wants to leave for a case number If there is a case number support could check if it is open or closed. That would be the absolutely basic functionality."
Analysis
There are some necessary data to collect for this purpose. So if we take the way of a case:
- a dispute is filed
a initial case-manager (role= iCM) creates a case and assigns a case-number
he asks for a case-manager (role= CM) and an arbitrator (role = A).
the case-manager defines the claimants(s) (role = Cnn) and the respondents (role = Rnn)
might be there will be witnesses (role = Wnn)
Functions
The functions on the side of arbitration could be:
- It is necessary to insert at least a single sentence including the appropriate items.
- Also it should be possible to insert all entries for a case in one action.
- It should be possible to add entries to a case.
- There need to be stored, if a person leaves the case.
- Also it should be possible to close a case in one step.
- If an address was entered in error it must be deletable.
The functions on side of support could be:
- Find out if a given person is involved in an open case.
Special conditions
- it must be guaranteed, an email-address can't be in {iCM, CM, A} and for the same case in {Cnn,Rnn, Wnn}
- it should be controlled, an email-address in a case has to be unique except the second date to enter is greater than the leaving date of the previous entry. this event should be logged
Solution
Datastructure
For the first phase it is enough to have a sentence containing the following items:
Field |
Definition |
|
Case Number |
VARCHAR (20) |
|
Email-Address |
VARCHAR (50) |
|
Name |
VARCHAR (50) |
|
Role |
CHAR(3) |
|
Date Join |
YYYY-MM-DD |
Date the person in question joins the case |
Date Leave |
YYYY-MM-DD |
Date the person in question leaves the case |
Where Role would be one of these values
Value |
Meaning |
ICM |
iCM intermediate Case-Manager |
CM |
CM Case-Manager |
A |
Arbitrator |
Cnn |
Claimant nn |
Rnn |
Respondent nn |
Wnn |
Witness nn |
An possible extension could be to store the reason for Entering or/and leaving the case.
In case board is involved, it could be necessary to have a field / fields that name(s) the person in charge.
it should be thought about to handle each entry with flags for active and inactive, to have in case of deletion this documented.
Tests
Definitions
- combination
- a combination of case-number and email-address
- complete data sentence
- a full set of data as: case-number, email-address, name, role, date of joining
Cases
case 1
To add a entry to the case enter a complete data sentence
if the combination does not exist, the sentence should be added
if the combination does exist and the existing sentence(s) does contain a date for leaving the case less than the entered date, the sentence should be added
if the combination does exist and the existing sentence(s) does not contain a date for leaving the case less than the entered date, the sentence should be rejected and logged
if the combination does exist and the existing sentence(s) does not contain a date for leaving the case, the sentence should be rejected and logged (included in previous scenario)
case 2
To add a complete case enter for a case-number for each role one complete data sentence
case 3