This function retrieves information from TIXnGO about the ticket (status, holder) and stores it inside SecuTix.
With FIFASTX-2770, we aligned the statuses and the screens between TIXNGO and S-360 :
- with the lifecycle mode, we synchronize the tickets from a "business" perspective
- with the history mode (legacy behaviour), we synchronize the tickets from a "blockchain transaction" perspective
| Table of Contents |
|---|
Ticket statuses
History mode (legacy behaviour)
- Possible Statuses (tixngo.legacyStatus) : INJECTED, RECEIVED, ACTIVATED, TRANSFER_PENDING, TRANSFERRED, CONTROLLED, DELETION_PENDING, DELETED
- Possible Actions : INJECT, TRANSFER, DELETE, BURN
- Possible States : PENDING, CONFIRMED, KO, DELETION_PENDING, DELETED, REGISTRATION_PENDING, CANCELLED, FAILED
Lifecycle mode (new behaviour)
- Possible Statuses : INJECTED, DOWNLOADED, ASSIGNED, CONTROLLED, PENDING_TRANSFER, FAILURE_TRANSFER, TRANSFERRED, BT_ACTIVATED, MANUAL_ACTIVATED, OFFLINE_ACTIVATED, ONLINE_ACTIVATED, DELETION_PENDING, DELETED, ACTIVATED, DEACTIVATED, DEFAULT, INVALID, PENDING, FAILURE
- Possible Actions & States : Does not exist anymore. Replaced by Business Statuses
| S360 Ticket Status | S360 Blockchain Status (history) | S360 Blockchain Status (lifecycle) |
|---|---|---|
| Not printed | NA | NA |
Printed | (after injection) INJECTED No Action/Status as long as the user does not have a wallet | (after injection) INJECTED |
(after download) RECEIVED Action/Status : Inject/Confirmed | (after download) DOWNLOADED | |
(after assignment) RECEIVED Action/Status : Inject/Confirmed | (after assignment) ASSIGNED | |
(after transfer initiated) TRANSFER_PENDING Action/Status : Inject/Confirmed | (after transfer initiated) PENDING_TRANFER | |
(after transfer cancelled by sender) RECEIVED (after transfer rejected by receiver) RECEIVED Action/Status : Inject/Confirmed | (after transfer cancelled by sender) FAILURE_TRANSFER (after transfer rejected by receiver) FAILURE_TRANSFER | |
| (after transfer accepted) TRANSFERRED Action/Status : Transfer/Confirmed | (after transfer accepted) TRANSFERRED | |
(after ticket offline activation) ACTIVATED (after ticket online activation) ACTIVATED (after ticket manual activation) ACTIVATED (after ticket bluetooth/beacon activation) ACTIVATED No specific Action/Status | (after ticket offline activation) OFFLINE_ACTIVATED (after ticket online activation) ONLINE_ACTIVATED (after ticket manual activation) MANUAL_ACTIVATED (after ticket bluetooth/beacon activation) BT_ACTIVATED | |
Controlled → ACS control → Ticket check (BO) | (after control BUT before feedback from TIXNGO) ACTIVATED (after control and feedback from TIXNGO) CONTROLLED No specific Action/Status | (after control before feedback from TIXNGO) XYZ_ACTIVATED where XYZ is the activation method used (after control and feedback from TIXNGO) CONTROLLED |
Invalidated → Reprint ticket → Post ticket on resale | If the ticket was already existing in TIXNGO ...
If the ticket was never sent to TIXNGO → NA | If the ticket was already existing in TIXNGO ...
If the ticket was never sent to TIXNGO → NA |
Cancelled → Cancel ticket (manually or by batch) | If the ticket was already existing in TIXNGO ...
If the ticket was never sent to TIXNGO → NA | If the ticket was already existing in TIXNGO ...
If the ticket was never sent to TIXNGO → NA |
History mode
...
What and how we synchronize ticket details ?
Each mode has a specific mapping. Find more details in this document : <DOC_TO_UPLOAD>.
How to configure the interface ?
In the custom parameters, to enable the lifecycle mode, you can use TIXNGO_LIFECYCLE_MODE=history
what happens if we don't ?
Mapping > blockchain_ticket
...
Mapping > blockchain_ticket_trans_log
...
lifecycle.
By default, if not specified, the history mode will be used.