OVERVIEW

• Backoffice timezone is based on browser local timezone.

Image Removed

• Every date-time displayed on Backoffice is converted to local timezone if no specific timezone is mentioned.

The TIXnGO AdminTool is a Management console for every Organizer. It allows them to inject, monitor and edit Tickets, Events, Transactions, Spectators and Custom App Settings. It is accessible at https://console.TIXnGO.io, where Organizers can sign in with their account, or create a new one.
This documentation is here to help support teams get a hold of this console.

DOCUMENT Related to V3.73

Image Removed

URL

• Production: https://backoffice.tixngo.io/
• Pre-production: https://backoffice-preprod.tixngo.io/
• Val: https://backoffice-val.tixngo.io/

0. Diverse

0.1 PROFILE PAGE - ACCOUNT

The profile page allows organiser to see the information liked with their account, such as company name, address and the api_key needed to do call the TIXnGO API.
This page is only accessible via the "ADMIN" account of the organizer and lets organizer manage their different accounts (ability to create/delete new accounts with specific role, see more in the Privilege section).

0.2 TIME IN THE CONSOLE

The Console display the Start Time (and all other time) in "Browser Time" so that the person using it sees it in the time zone they are in (offset is written in parentheses for StartTime).
The Mobile Application display the time as it was injected, which should be the local time of the Event (standard ticketing).
Example:
Lets say a Ticket is injected for an Event that starts the 2020-01-01 at 20:00 in Lausanne (UTC + 1) the time sent in the injection batch should be "2020-01-01T20:00:00+01". Imagine this event is organized by an English company based in London.
On the Mobile ticket in the app, one will see 2020-01-01 20:00 (as it is always display in the local time of the event).
On the Console the Support Team based in London (UTC) will see Start Time 2020-01-01 19:00 (their local browser time). The purpose of this is that the Support Team see correctly when the event (and other time) will start based on their local time, meaning they won't have to make time conversion every time they look at something.

1. TICKETS

1.1 TICKETS PAGE

The purpose of the Tickets page is to monitor every tickets that has been injected in the TIXnGO system in real-time. This view displays the Ticket ID, it's taxation number, barcode, current owner name / email, initial owner name / email and status, as well as the related event's name, start time and file ID and it can be exported to an excel sheet, using the excel button.
One can search for a specific ticket(s) using the search field at the top of the page (black rectangle in the screenshot example).
Clicking on a Ticket ID will redirect you to the Support → Ticket screen, showing much more information about one particular ticket (see Support section).
Clicking on the Event name will redirect you to the Event page for that specific Event.
Clicking on the Owner email will redirect you to the Support → Spectator screen, showing information about that specific spectator (see Support section).
The Action column is used to display information about the ticket such as Transfer rules, Main and Extra data (Ticket button) and allows Main and Extra data edition (Pencil button). Organizers can also delete ticket, deleted reason and deleted ticket visibility are required (Wastebasket button).
Clicking on Export Ticket Details to export ticket details data.

1.2 TICKETS STATUS DESCRIPTION

AdminTool statuses

...

• PENDING_TRANSFER
  Organizer: Ticket can be seen in the AdminTool as PENDING_TRANSFER.
  Spectator: Transferrer sees Ticket in his wallet in the transfer screen. Transferre still does not see the ticket in his wallet

• PENDING_P2P_RESALE
  Organizer: Ticket can be seen in the AdminTool as PENDING_P2P_RESALE.
  Spectator: Transferrer sees Ticket in his wallet in the resale screen. Transferre still does not see the ticket in his wallet.

...

• FAILURE_P2P_RESALE
  Organizer: Ticket can be seen in the AdminTool as FAILURE_P2P_RESALE.
  Spectator: Transferred can see ticket in his wallet. Transferred failed (either failed, rejected or cancelled)

• FAILURE_2MKT_RESALE (not yet applied)
  Organizer: Ticket can be seen in the AdminTool as FAILURE_2MKT_RESALE.
  Spectator: #

• TRANSFERRED
  Organizer: Ticket can be seen in the AdminTool as TRANSFERRED.
  Spectator: Transferrer do not see ticket anymore (only transfer history). Transferre sees the ticket in his wallet.

• RECEIVED

Organizer : #

Spectator : Ticket received = injected + app download and ticket visible in the app for the spectator (to confirm with Team)

• RESOLD_P2P_RESALE
  Organizer: Ticket can be seen in the AdminTool as RESOLD_P2P_RESALE.
  Spectator: Transferrer do not see ticket anymore (only resale history). Transferre sees the ticket in his wallet.

• RESOLD_2MKT_RESALE (not yet applied)
  Organizer: Ticket can be seen in the AdminTool as RESOLD_2MKT_RESALE.
  Spectator: #

...

• DELETED
  Organizer: Ticket can be seen in the AdminTool as DELETED.
  Spectator: Spectator does not sees ticket anymore (or greyed-out if show deleted ticket selected).

1.3 TICKETS INJECTION

The Tickets Injection page lets organizer inject new tickets providing the minimum required information for the ticket and event, as well as more detailed information such as the activation parameters, transfer rules and custom ticket details.
The injection can be done for a single ticket, which can be useful to create a few test tickets, or it can be done for multiple tickets at a time using a .CSV file.

...

Indicates if the spectator is the main applicant (SecuTix) for this ticket (default false).

...

Maximum profit (price increase in %) of the original ticket price for a resell between spectator.

...

Resale rules can technically be different for every ticket. Organizer might want to chose to have different resale rules for different types of ticket (ex: Adult, child, VIP, etc…). This GroupID is the Resale rules group ID representing a group of resale rules applied to certain tickets. If Organizers want to apply the same rules to every tickets, by default this groupID is set to the EventID and every ticket will be in this group.

It is editable or used only if organizer resale setting is enabled

...

Enables or Disables resale functionality for given match for all Tickets (Send menu item in the ticket view hidden or displayed)

It is editable or used only if organizer resale setting is enabled

...

Enables or Disables resale functionality for given match for ActivatedTickets (Send menu item in the ticket view hidden or displayed)

It is editable or used only if organizer resale setting is enabled

...

Resale Options

...

Support organizer define the resale price with three options A, B and C per Transfer Group Id:

• "Option A: Price range" [the resale price of this ticket is allowed by the event organizer to be resold between a minimum and a maximum]
• "Option B: Fixed price" [the resale price of this ticket is set by the event organizer]
• "Option C: Unlimited price" [the resale price of this ticket is allowed by the event organizer to be resold at any price]

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option A is selected. Min resale price decrease (in % of the initial price) of the ticket to be resold

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option A is selected. Min resale price amount of the ticket to be resold

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option A is selected. Max resale price Increase (in % of the initial price) of the ticket to be resold

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option B is selected. Specific resale price decrease/increase (in % of the initial price) of the ticket to be resold

• Value > 0: Increase
• Value < 0: Decrease

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option B is selected. Specific resale price amount of the ticket to be resold

• Value > 0: Increase
• Value < 0: Decrease

It is editable or used only if organizer resale setting is enabled

...

The Resale & Purchase Agreement URL in P2P resale

It is editable or used only if organizer resale setting is enabled

...

Ticket Terms & Conditions URL in P2P resale

It is editable or used only if organizer resale setting is enabled

...

1.3.1 CSV File Injection

The CSV file injection tab allows the organizer to inject up to 20'000 tickets at a time.
This page list the jobs that were sent by the organizer and its status for all of them. The uploaded CSV is downloadable as well as the output, explaining which ticket where injected and which were refused (with the error associated with it).
Failed jobs are also downloadable and the error provided on each format error that would be in the injection CSV.
Two templates are available, a minimal required fields template and a complete templates with all possible ticket fields to help with the CSV setup.
The CSV file must be UTF-8 encoded.
A full documentation is available here: https://developer.TIXnGO.io/pdf/TIXnGO-Injection-Doc.pdf

1.4. Tickets Bulk Update

The Bulk update page allows the organizer to update ticket details by CSV batch (Max 50 rows per batch).

The CSV template can be get by clicking CSV template button or Export Ticket Details button (in the Tickets page) .

Variable details 

...

The update result will be available in the OUTPUT column once the input file is submitted successfully.

WARNING: 

• The CSV delimiter must be ";".
• The Data format must be the same as the template gets from CSV template or Export Ticket Details.
• The maximum number of rows is 50.
• The output file will not be saved in the system

2. Support Screens

2.1 TICKET

The Support - Ticket page lets the organizer or support team look for in depth information about one specific ticket. It's easily reachable from the Tickets page by clicking on the ID of a particular ticket, or by searching for an ID or barcode in the Support - Ticket screen directly (Warning: As the page display information about only one ticket, the search result must be unique, if one only knows part of the information of a ticket, searching through the Tickets page then selecting the ticket might be the better way).
The information displayed on this screen is same as those in ticket page and more, includes:

• The ticket's Current Owner details, the Initial Spectator details as well as the ticket's Holder details (also called Guest), if there is one.
  - Current Owner: The Spectator currently owning the ticket, the ticket is inside his wallet (main applicant flag displayed).
  - Initial Spectator: The Spectator that was the first ever "Current Owner" of the ticket, the one the ticket was injected to by the Organizer. This will never change through the life of the ticket.
  - Ticket Holder: The person assigned to a ticket that is held by the "Current Owner". The name of the Ticket Holder will appear on the ticket.
• This screen also contains the Ticket Details (Main, Extra & Hidden) usually used for Seating detail and specifics to be display on the ticket.
• The ticket's Status History (all ticket status logs): injected, downloaded, activated(online, offline, Bluetooth, manual)/deactivates, assigned, pending(pending_transfer, pending_p2p_resale, pending_2mkt_resale), transferred success/failure (transfer/p2p_resale) , controlled & deletion_pending/deleted (deleted reason included) with Backend & Mobile timestamps
• The ticket's Transfer rules (editable).
• File Id: It's SecuTix number called "File ID" (ticket order number)
• The number "Total in File" = Total number of ticket with the same File ID (which is the ID of a SecuTix injection file)
• The number "Total Transferred in File" = the total number of ticket transferred with the same File Id. Here is the original JIRA: 

  Jira
  server ELCA JIRA serverId e01181c2-2438-3931-a241-44aa227a077d key FIFASTX-789

2.2 SPECTATOR

The Support - Spectator page lets the organizer or support team look for information about one specific spectator. It's accessible by clicking on a spectator's email address from any other page in the Console, or by searching for an email address, ticket ID, barcode or name (Warning: As the page display information about only one spectator, the search result must be unique, if one only knows part of the information, searching through the Tickets/Spectator page then selecting the email address might be the better way).
The information displayd on this screen includes:

• Spectator's detail, including email, first and last name, gender, birthdate, nationality, passport number, Id card number, phone number and country of residence.
• The spectator's Tickets list: all tickets currently owned by the spectator ('Downloaded' → appear inside Owner's wallet) + the ones that were deleted ('Downloaded' + 'Deleted' → do not appear inside Owner's wallet). This list contains the Event name, the Ticket ID, the Ticket's taxation number, its barcode, status, as well as the start time of the Event, the activation time of the Ticket (if there is one), the email address of the purchaser (= Initial Spectator) and the date and time the Ticket was injected. This list is filterable in two ways: All tickets currently in the spectator's wallet OR All tickets that have been at anytime in the spectator's wallet.
• The spectator's Mobile logs.
• The spectator's Communication logs with the ability to resend a specific communication. The content of the communication can be read with a click on the reason title.

3. EVENTS

3.1 EVENTS PAGE

The Events page allows organizer to have control over their different events. Specific events can be search by Event ID or Name.
The Events are ordered by Start Time (filters by startTime/endTime can be applied).
This page first displays the Preparation, Steward and Gate beacon information, so organizers can have a quick access to those keys.

The button "Export Event" (under title "Event List") allows Organizer to export all event details
The Events list shows every Event created by the organizer with their Ticket's status count (this gives the overview of the event with the total number of injected tickets, the total number of downloaded tickets, the number of tickets still pending (Pending after transferring), the total number of controlled tickets (Tickets that have been scanned by the staff). The action column lets the organizer:

Update the event's information

...

Maximum profit (price increase in %) of the original ticket price for a resell between spectator.

It is editable or used only if organizer resale setting is enabled

...

Resale rules can technically be different for every ticket. Organizer might want to chose to have different resale rules for different types of ticket (ex: Adult, child, VIP, etc…). This GroupID is the Resale rules group ID representing a group of resale rules applied to certain tickets. If Organizers want to apply the same rules to every tickets, by default this groupID is set to the EventID and every ticket will be in this group.

It is editable or used only if organizer resale setting is enabled

...

Enables or Disables resale functionality for given match for all Tickets (Send menu item in the ticket view hidden or displayed)

It is editable or used only if organizer resale setting is enabled

...

Enables or Disables resale functionality for given match for ActivatedTickets (Send menu item in the ticket view hidden or displayed)

It is editable or used only if organizer resale setting is enabled

...

The Resale & Purchase Agreement URL in P2P resale

It is editable or used only if organizer resale setting is enabled

...

Support organizer define the resale price with three options A, B and C per Transfer Group Id:

• "Option A: Price range" [the resale price of this ticket is allowed by the event organizer to be resold between a minimum and a maximum]
• "Option B: Fixed price" [the resale price of this ticket is set by the event organizer]
• "Option C: Unlimited price" [the resale price of this ticket is allowed by the event organizer to be resold at any price]

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option A is selected. Min resale price decrease (in % of the initial price) of the ticket to be resold

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option A is selected. Max resale price Increase (in % of the initial price) of the ticket to be resold

It is editable or used only if organizer resale setting is enabled

...

Enable when Resale option B is selected. Specific resale price decrease/increase (in % of the initial price) of the ticket to be resold:

• Value > 0: Increase
• Value < 0: Decrease

It is editable or used only if organizer resale setting is enabled

...

The URL of TicketShop resale

...

Makes Sponsors Image clickable redirecting to this link (must provide Image URL)

...

The background color of the corresponding Design Id (Example: #bbccdd). If the background color is updated, all the tickets with the corresponding Design Id will be affected

...

For organizer could set amount fee for ticket of P2P resale

It is editable or used only if organizer resale setting is enabled

...

For organizer could set fee percent for ticket (calculating on resale price) of P2P resale

It is editable or used only if organizer resale setting is enabled

...

For organizer could set currency of fee for ticket of P2P resale

It is editable or used only if organizer resale setting is enabled

...

3.2. Ticket Holder Questionnaire

The Ticket Holder Questionnaire popup allow organizer to ask questions related to operation or marketing to all ticket holders.
The organizer can decide to target or not the ticket wallet owners, who “opt-in” to marketing communication during the account creation, or through the in-app menu, for optional questions.
All their answers are collected, associated with their respective information and exported to XLS file by clicking Extract answers button.

Settings variables:

...

Question:

• Click "+" button (next to the language dropdown) to add a new question.
• Click "-" button to delete a question on respective row.
• Each question can be set as optional or mandatory. Some answers could be Expected as the single mandatory answer.
• Question can be edited as bold/italic/underline characters and hyperlink by selecting text to edit and click button in the tooltip (B, I, U, Link icon)

Type of answers:

• RADIO_BUTTON: box to choose between YES/NO.
• MULTIPLE_CHOICE: box to choose between A/B/C/... (with fields which could be added by clicking "+" button next to question content).
• FREE_TEXT: text answer.

4. SPECTATORS

4.1 SPECTATORS PAGE

The Spectator screen lets organizers see the list of Spectator owning tickets for one of their events. Spectator can be searched by email, first and last name, phone number, passport number, Id card number and SecuTix File ID.
This page displays a few information about spectators, such as their email, name, gender, account creation date and promo/tracking option.
Clicking on a spectator's email address will redirect to the Support→Spectator screen, showing more information about this specific spectator.

Actions column in the Spectator table allows organizer to log out a spectator from all his devices (kills all active sessions) in case the spectator needs to log in in a new device but could not log off others.

5. COMMUNICATIONS

5.1 COMMUNICATIONS PAGE

The Communications page allows organizers to view all communication logged in the TIXnGO system. Comm. logs can be search using the email address or phone number of the spectator, the type (email or push) the status (delivered or failed) and the transmission date.
This page displays the spectator's email (recipient of the communication), the reason of this communication, the transmission date, as well as the type and status of this communication.
Clicking on the reason title will show the communication content.
This page also contains a Resend button that lets Organizers resend all filtered communications. This action will trigger a prompt, asking the user to confirm before sending X notifications. This had to be used carefully has one can easily spam someone or even get blacklisted by Amazon Web Services.

5.2 NOTIFICATION CAMPAIGNS

The Notification Campaigns tab allows organizers to view all the notification campaigns they schedules, cancelled and sent. The campaigns can be searched by name, content language and the table displays the campaign ID, name, created date, scheduled date, status (scheduled, canceled or sent), the number of impacted spectators, successfully sent and failed notifications (all those numbers are updated after the campaign is sent as they come from reporting).
Clicking on the Campaign Name will open a popup box displaying the campaign's contents in all languages.
From this table one can update or cancel a scheduled campaign and rescheduled a cancelled campaign.
A download button will appear once the campaign has been triggered, allowing the user to download a report containing the spectator's email address and the status of the notification sent to him.
New campaign can also be created from the Schedule Campaign button.

...

The system only checks if the spectator has the NotificationTokenID connected with AppID to send the notification. Therefore, the user who hasn't downloaded or registered an account won't be able to receive any notifications.

A default language must be selected from the dropdown list of supported languages. Notification title and content can be setup for all supported languages, if let blank the template is not used in the campaign. (e.g. if one supports EN and FR but only want to schedule this campaign in English, leave the French line blank).

While editing a campaign, if the text "CSV already uploaded" and the button "Download here" is visible, that means the CSV file the user previously input is still present and will be used as filter unless he uploads a new one.

6. TRANSACTIONS

6.1 TRANSACTIONS PAGE

The Transactions page allows organizers to view all ticket's transactions logged in the TIXnGO system. Transactions can be search using their transaction hash, their date, type or status.
This page displays information about the transaction such the date, the ticket ID, the sender and receiver if it exists, the transaction type, status and hash, as well as the reason if it exists (only for transfers).
Clicking on the ticket ID will redirect to the Support→Ticket screen for this ticket.
Clicking on the sender or recipient email will redirect to the Support→Spectator screen for this spectator.

7. PENDINGS

7.1 PENDINGS PAGE

The Pendings page allows organizers to view all "Pendings Tickets" (tickets where the transfer was initiated but the recipient did not yet sing-in to the app and loaded the tickets). Pendings can be search using the ticket ID, the date or the recipient registration source (account was created in TIXnGO system and user has the Mobile application or not yet: "Mobile App" or "External").
This page displays information about the Pendings Tickets, such as the ID, the taxation number, the event ID and name, the sender and recipient emails, the registration source and the date and time of the initiation of transfer.
Clicking on the Ticket ID will redirect to the Support→Ticket screen.
Clicking on the event ID or name will redirect to the Event screen.
Clicking on the sender or recipient will redirect to the Support→Spectator screen.

8. MOBILE LOGS

8.1 MOBILE LOGS PAGE

The Mobile Logs page lets the organizer see all logs from the mobile app (for the tickets injected on their mobile app). The logs can be searched by spectator's email, message content, app name (e.g. io.TIXnGO.app is the generic TIXnGO app), log level (i = info, e = error, w = warn), by platform (operating system), or by date.
The information displayed on this page contains the following: Log level, Spectator's email, action that was logged (e.g. authentication, ticket activation, etc...), the content of the logged message, the app name and version, the spectator's devise model, the platform (OS) and the date and time. All this information is mostly useful for debugging purposes.
Clicking on the spectator's email will redirect to Support→Spectator screen.

9. SETTINGS

9.1 SETTINGS PAGE

The Settings page allows the organizer to handle different app settings, app features, organizer settings, as well as translation option such as email and push notifications in different languages.

9.1.1 Application Settings

...

Values: Integer > 0 ,
Pop-up message in app for transferring ticket reminder (RBL). Value indicates the interval between 2 pop-ups. 

...

Values: List of ticket details main or extra key  which define by organizer (eg. Gate, Block, Row, Seat,...) which is used to notify ticket owner transfer tickets

(Dependent with ticket.owner.transfer.alerts feature and ticket.owner.transfer.alert.hour )

...

Values: FALSE, TRUE; disable or enable the allowing only one session. 

(For login restriction security purpose)

There are no differences between “Only one active wallet session is allowed” and “Max number of active devices at once (only if security is enabled)” = 1.
It would implies the same behavior. The first one was the first to be implemented. The second one at a later stage.

...

Values: FALSE, TRUE; disable or enable the online check if device readed max active sesssions.

(For login restriction security purpose)

...

Values: (with X, Y, Z are Integers and X is required)

Oldest version of the app that requires user to install. 

Using for force update purpose: the organizer can decide to request to have a minimal version of the TIXnGO wallet to be used. So the app will show you a informative screen to ask you to update the app (cannot do anything else in the app).

...

Values: (with X, Y, Z are Integers and X is required)

Latest version of the app that requires user to install. (Should always same or later than minimal one)

There are no features implemented yet related to this one. An example of a potential feature, you might be interested and asked us to develop, would be a new feature to display a pop-up in the app informing a new version is available

...

Values: Integer > 0

Pop-up message in app for transferring ticket reminder. 
Value indicates the number of hours between 1st pop-up and event start time. 

(Dependent with  ticket.owner.transfer.alerts and ticket.owner.transfer.alerts-keys )

In case you have tickets for different block/gates. This is for pop-up message. Organizer need to enable and define these keys to be able to use this feature:

• ticket.owner.transfer.alerts (enable the feature on mobile)
• ticket.owner.transfer.alerts-keys (Define the key to compare)

...

Values: Integer > 0

Pop-up message in app for different-gates/blocks reminder , value indicates the interval between 2 pop-ups. Number of minutes before sending different-gates/blocks reminder in the app

• In case you have tickets for different block/gates. This is pop-up message. Indicates the interval between 2 pop-ups.
• Same as above, organizer need to enable and define these keys to be able to use the feature:
• ticket.owner.transfer.alerts (enable the feature on mobile)
• ticket.owner.transfer.alerts-keys (Define the key to compare)
• ticket.owner.transfer.alert.hour (Define the first pop-up time)

...

Values: Integer > 0

Unregistered emails will be anonymized after this amount of day since the ticket's event expired.

...

9.1.2 Application Features

...

Enable / Disable ticket.owner.transfer.alerts feature, allowing organizer to notify for ticket owner has multiple tickets in different locations to transfer tickets. 

(Dependent with ticket.owner.transfer.alerts-keys and ticket.owner.transfer.alert.hour)

...

9.1.3 Organizer Settings

...

Values: Integer [0, 5] (maximum of 5 reminders per person

Type: email

...

Values: Integer >= 12 (limits to a maximum of 1 email every 12h, hence 2 per day max)

Type: email

...

Values: Integer [0, 23] representing hours of the day

Type: email

...

Values: Integer >= 0

Type: email

...

Values: Integer >= 0

Value indicates the number of hours before auto-cancel is triggered (Value = 0 : no auto-cancel)

...

• Value: Integer (hour) Default value = 0, which mean this feature is not Enable.
• The user should only receive one email for his first injected purchased ticket.
• The system shall block any purchase emails for X hours after the first sending of email for each ticket holder (counting separately for each ticket holder).
• If the X (hours) time is past, those emails that are generated in X time will never be sent.

...

• Automatic anonymization processing X days after the event ended
• Set 0 to not auto anonymize unregistered users
• Automatic anonymization processing X days after the event ended, X get from the configuration
  
  • run every night (ex: 1:00 am server time)
    
• Value: interger >= 0

...

9.1.3 Multilingual Settings

...

10. CHARTS

10.1 CHARTS PAGE

The Charts page is a new feature in the TIXnGO system (currently still under development), that shows organizer a graphical representation of the life cycle of their tickets, per event. This feature makes use of our Machine Learning algorithm to give trust scores to each user and detect fraudulent behavior.

What is the Spectators Behavior Analysis?

TIXnGO works everyday to improve security and reduce fraud in your events. The spectator behavior analysis is a Machine Learning tool developed by TIXnGO that classifies the actions of spectators during an event. Its purpose is to provide organizers with a deeper understanding of tickets life within their events and to help detecting users that might need monitoring.

How does it work?

This tool uses an ensemble of Machine Learning models and classifies regularly each spectator's behavior based on his transfers activity in every event where tickets have been injected. The Charts tab allows you to see an almost real-time representation of your events. This functionality coupled with our Blockchain technology, grants you the insurance to see who's in possession of your tickets at all times. This representation comes with a classification of spectators to help you identify users that might act in an unwanted way.

Disclaimer

Please bear in mind that this tool is an ongoing project that will improve upon time and data. Furthermore, the model used in the classification runs under the assumption that some kind of undesirable behavior will exist in the event. This implies that the resulting classification might not be relevant if every user acts with respect to the terms of use. The same applies for events with a very small amount of spectators.

How to read it ?

The color coded nodes represents users with tickets. The label on the left side explains the behavior for each color.
Green nodes are spectator with an Adequate Behavior, yellow ones are more dubious, oranges behave in a way we would prefer to avoid and red nodes are clearly bad behavior.
The size of nodes represents the inverse of trust score.

11. REPORTS

11.1 REPORTS PAGE

The Reports page allows organizer to generate a report of ticket statuses for any of their event. For now the reporting tool is limited to:

• Mobile Tickets Per Status subdivided per price category

12. QUESTIONNAIRE REPORT

The questionnaire report page is a new feature used to dig into the responses of a questionnaire. The goal is to offer the organizer the possibility to gain quick insights without having to look at an annoying CSV file.

The tool can be used even if there are no open-ended (free text) questions in the questionnaire (hence no natural language processing) since it will also help to gain insights about the closed questions (multiple-choice, radio-button).

ADDENDUM

1. Privileges on the AdminTool:

Few definitions:

1. Read privileges means ability to view a given page or a given information on the AdminTool
2. Create privileges means ability to create a new information on the AdminTool. Like create a ticket using the AdminTool
3. Update privileges means ability to update an existing information on the AdminTool. Like update ticket details, update match details
4. Delete privileges means ability to delete an existing information on the AdminTool. Like delete a ticket
5. Search privileges means ability to execute a search on the AdminTool
6. Export privileges means ability to export data from AdminTool
7. execute: ability to execute an action (such as: send communications).

Pre defined roles:

1. admin-user - AU: has all the privileges listed above.
2. support-user SU: has limited privileges to the AdminTool
3. basic-user BU: has only the ability to view information using the AdminTool

More details:

• The main user will be created manually by TIXnGO and provided to the organizer.
• The admin user will have the ability to create other users.
• Only 1 user can be admin. 

Table of roles:

...