Removal Approvals
Manage Contracts- to view this screen
- to request a contract removal
- to approve a request, or to take your approval off one
When the Maker Checker functionality is active for an application, a contract removal performed from the Backoffice is not carried out on the spot. It opens a request that other operators have to approve first. This screen is where those requests are listed, reviewed and approved.
The functionality is configured in Settings > Functionalities.
How it works
An operator asks for a contract to be removed from the Contracts screen, as usual. Instead of removing it, TrustFactor opens a request and tells the operator that approval is needed. Other operators then open the request and approve it. As soon as the required number of approvals is reached, the contract is removed and the request is marked as done.
The number configured for the application counts operators besides the one asking. A setting of 1 therefore means one maker plus one checker: two different people.
The operator who requested a removal can never approve it. Trying to approve your own request is refused, and the request details screen tells you so:
You requested this contract removal, so you cannot approve it. Another operator has to.
Application administrators and Backoffice owners are not subject to the gate. They remove contracts directly, because they are the ones who decide how many approvals the application requires in the first place.
Requesting a removal
After asking for a removal on the Contracts screen, one of three messages is shown:
- A request was opened - no request existed for that contract and device, so a new one was created and is now waiting for other operators.
- Your approval was added - a request was already in progress and your attempt counted as an approval on it.
- It is already waiting for you - a request is in progress and you are already on it, either as its author or as an approver. Nothing changed.
A request identifies exactly one contract removal: the application, the app user and the device. The same device can therefore have separate requests open for different app users.
Pending and History
The screen has two tabs. Pending lists the requests still waiting for approval, and History lists every request, including the ones already carried out or closed. Both list:
- Status
- Approvals - how many approvals have been given, out of how many are required
- Requested by
- Requested at
A request is in one of three states:
- Waiting for approval - it still needs approvals and the contract has not been touched.
- Removal done - the required approvals were reached and the contract was removed.
- Closed - the request was ended without the removal being carried out.
The sidebar entry carries a badge with the number of requests currently waiting, so operators do not have to open the screen to know that something needs their attention.
Request details
Opening a request shows its current status, how many approvals it has out of the number required, who has approved it so far, the app user it concerns and the device key, along with a shortcut to that user's devices.
Two actions are available, each behind a confirmation:
- Approve - adds your approval. If it is the one that completes the request, the contract is removed straight away and the request is marked as done.
- Reset my approval - takes your own approval back off the request. You can only withdraw your own.
There is deliberately no reject action. A request that should not go ahead is simply left without enough approvals.
Every step is recorded in a history table showing When, Who and What:
- Requested the contract removal
- Approved
- Reset their approval
- Contract removal performed
- Request closed
The names are stored with each entry, so the history stays readable even after an operator is renamed or deleted.
Requests that can no longer be carried out
If the contract or the device is already gone by the time a request is approved, the request is closed rather than left waiting, with the reason The contract no longer exists recorded in its history.
A removal that fails for a transient reason leaves the request pending, so it can be retried later with the approvals it has already collected.
Turning Maker Checker off stops the gate immediately, but requests that were already waiting are kept. They stay visible in the History tab.