Security automatic switch from online to offline activations X minutes before Event Start Time 

https://jira.secutix.com/browse/TIX2-2430 Emergency activation on mobile.

• In the way to enable the mobile wallet to activate online-activation tickets in case the phone is actually not online, or the Bluetooth does not work, the following new security parameter has been created:
  •  Application Settings / key: ticket.emergency.activation / description: Minutes before the event starts to activate tickets offline (set 0 to turn off the feature)
  • 

Ticket transfer UI/UX enhancement, including transfer message

https://jira.secutix.com/browse/TIX2-225 As a ticket holder, I have a new UI/UX design when transferring my ticket.

• As a registered wallet user and transferable ticket holder, I
  • 
• On the "Send your ticket" screen, I can see the transfer ticket summary, and can add additional tickets (c.f. 2022 Weisshorn V3#2022WeisshornV3-Ticketbulktransfer).
  • 
• If the new "Transfer Message" feature is enabled in the Backend (c.f. Application features / transfer-message) and in the ticket transfer email template (c.f. transfer.message), I can see a section to input a message to the recipient (max 300 characters), which will be displayed in the email notification. NB: The message will be as well displayed in the receiver wallet, at a later stage of development (c.f. https://jira.secutix.com/browse/TIX2-2312).
  •  

Wristband handover time displayed

https://jira.secutix.com/browse/TIX2-1865 As a wallet user, I can see on the ticket, if and when a wristband has been allocated.

• When wristband is handed out (wristband activated), log is recorded at bottom of ticket : WRISTBAND HANDED OUT AT HH:MM:SS
• Wristband handed out log on mobile reset when user logout or change device
• 

Language selection and FAQ on log-in screen

https://jira.secutix.com/browse/TIX2-1830 As a wallet user, I can select the in-app language on the log-in screen, and access the FAQ.

Multilingual - PART 1: Injection and mobile app

https://jira.secutix.com/browse/TIX2-1769 As organizers, we want to inject multilingual  for events and display it on mobile app. PART 1/3 → other 2 PARTs will be deployed in next upcoming sprints (c.f. PART 2: update multilingual for events directly on AdminTool, Transaction pending, PART 3: export events multilingual from AdminTool).

• Organizers to inject their tickets from S-360 (API), or by CSV file on AdminTool with multilingual support.
  • Elements: Event name, Event website, Event address (site, line1, line2, line3, city), Group name, Group image, Master event name, Ticket details.
  • Languages code (ISO 639-1:2002): Arabic (ar), Catalan (ca), Czech (cs), Dutch Flemish (nl), English (en), French (fr), German (de), Hungarian (hu), Italian (it), Portuguese (pt), Spanish (es), Turkish (tr).
  • 
• In case an event does not support a spectator’s app language, let display the event’s default language (English) (including its tickets label).
• If an event is supporting a spectator’s app language, let display event information by the app language of this spectator (including its tickets label).
• JSON format example.txt

Search and troubleshoot spectators stuck in the registration process

https://jira.secutix.com/browse/TIX2-190 As an organizer, I can search and troubleshoot Spectators, who did not complete the registration process (for instance to retrieve registration code).

• Goal is for organizers to troubleshoot cases:
  • Retrieve users' registration code, when registration process has not been completed,
  • Retrieve users, who created an account without tickets (never had + already had tickets),
  • Retrieve users, who have tickets in pending transfer from another user,
  • Retrieve users, who have tickets in pending download (injection).
• Test scenarios
  • Spectators that did not complete registration process → search for this spectator in the AdminTool and see the Pincode.
    • 
  • Inject a ticket to user A which never registered in the system (injection pending) → search for this spectator in the AdminTool with status inactive (similar to user did not complete registration process).
    • 
  • User A transferred a ticket to user B, who has never registered in the system (transfer pending) → search for this spectator in the AdminTool with status inactive (similar to user did not complete registration process).
    • 

Ticket's Target Group (TG) Sub-Target Group (STG) - PART 1: Ticket List screen → Deployed in Pre-Production. Deployment in Production pending on S-360 dependency.

https://jira.secutix.com/browse/TIX2-641 As an organizer, I can search by STG in the Ticket List screen. PART 1/3 → other 2 PARTs will be deployed in next upcoming sprints (c.f. PART 2: search by STG in the Transaction list, Transaction pending, PART 3: search by STG in Reports).

• Enable organizers to classify a ticket by a contingent.
  • Inject the contingent successfully from S-360.
  • Filter by the contingent in several screens (e.g. Ticket List screen), in order to have an overview of ticket status per each contingent,
  • Send push notification for just some specific contingents,
  • Export the ticket with the contingent.
• New Back Office AdminTool 2.0 Console > Settings > Organizer Settings > enable.contingent.feature 
  • 
• New table REFERENCE_DATA, example:
  • 

• Injection API (dependency on S-360)

  • 
  • Data model: TICKET table adapted to add the contingent.
    • New column CONTINGENT_EXTERNAL_ID added in table TICKET, NULLABLE
    • Data migration: no needed, existing tickets are let empty.
  • If the organizer enables the contingent feature, then contingent must not be empty, otherwise, it is kept optional.
  • 
• Injection CSV (dependency on Injection API)
  • Contingent has been added in the CSV import file with the same structure as the API.
• Ticket List page
  • If the organizer enabled the contingent feature:
    • New filter by contingent is added, and new column contingent in the list:
      • Value in drop down of the new filter comes from REFERENCE_DATA table of selected event if any or all events, with (key = ‘CONT’, lang = ‘en’)
    • Query search result adapted.
    • Contingent added in the export file.
  • Otherwise, the current behavior has been kept.
  • 
• Ticket Support page
  • If the organizer enabled the contingent feature:
    • AdminTool: contingent is added to the ticket details.
    • Backend: returns the contingent for AdminTool.
  • Otherwise, the current behavior has been kept.
• 

Ticket transfer disabled after Bluetooth beacon activation 

https://jira.secutix.com/browse/TIX2-1760 Following time activation (online or offline), disable transfer only after ticket check (via beacon or manually).

• If a ticket get time-based activated, but the spectator has a last-minute blocker and cannot go to the event, the spectator can still transfer to somebody else. However, if the ticket has been already activated at the event location through a Bluetooth beacon (BT) (or manually), the ticket cannot be transferred.
• The organizer can allow/disable the ticket transfer after the BT activation by setting parameter transferRules.allowTransferAfterActivationByBT to TRUE/FALSE per ticket level (default = TRUE).
  • If param is set to TRUE: On mobile, the transfer button is available and the ticket can be transferred to another account as usual after the BT activation. 
  • If param is set to FALSE: On mobile, the transfer button is not available, if the device is online after the BT activation. The ticket can't be transferred to another account after the BT activat
• New endpoint from backend:
  • POST /spectator/tickets/secondary-activations: Inform the backend that a ticket was activated for the second time on the spectator side (mostly BT beacon). → Mobile use this flag to hide the "Transfer" button.
• New parameter work for all injections from S-360 injection (via the S-360 Ticket Template Editor) and TIXNGO CSV Injection and TIXNGO single injection.
• The Backoffice AdminTool 2.0 Console has been adapted accordingly.
  • On the Edit Event (screenshot), Support ticket screen, Ticket Detail pop-up.
  • The new rule of Allow transfer after activation belongs to each group transfer Id.
  • Under transfer rules of each ticket, rule (Allow transfer after BT activation) is updated with the value ON/OFF respectively.
  • On Support page, organizer can edit the rule to ON/OFF as other transfer rules.
  • If rule is not mentioned during injection, Backend to set the default TRUE.
  • 

Ticket deletion push notification with invalidation reason 

https://jira.secutix.com/browse/TIX2-1770 As an organizer, I want to send a push notification with a specific reason while deleting a ticket.

• When an organizer deletes a ticket in S-360 (or directly from TIXNGO), the TIXNGO backend triggers a configurable push notification to the user.
  • Examples:
• Backoffice AdminTool 2.0 Console > Settings > Multilingual Settings > 32+ new keys added
  
  • 
• Ticket delete notification configuration guideline: Notification & Email Templates#Ticketdeletenotification

Screenshot and screen recording protection (native)

https://jira.secutix.com/browse/TIX2-1809 [Screenshot/recording protection] As TIXNGO, I replace ScreenShieldKit existing solution https://pub.dev/).

Related to the previous delivery in 2022 Weisshorn V2: https://jira.secutix.com/browse/TIX2-2 Screenshot and screen recording protection.

• The screenshot/recording feature works as previously on iOS and Android.
• Organizer can enable/disable the feature under Backoffice AdminTool 2.0 Console > application features > screen.protect.shot.record.

Secure offline activation mode with the device's trueTime

https://jira.secutix.com/browse/TIX2-1755 [All Branded SDK-based App] Secure offline activation mode.

• Currently, the offline activation is based on the device date-time. So some users can change the phone time and trigger the offline activation before the actual configured time. The main purpose of this new feature is to implement a more secured offline activation to avoid those cheat cases, and to always keep offline activation at the correct date-time by leveraging the device boot and actual local true date-time.

  • 

• Important edge cases:

  • In case the user reboot his/her phone, and then opens the app again, the user will be asked though a pop-up message to connect to the internet (online) at least once.

    • This internet connection pop-up will appear if (1) the user shutdown/reset/out of battery, and (2) once user opens app aga

  • In case the user removes and reinstalls the app, the function should work as normal.

  • 

Bluetooth beacon identifier in the Backoffice AdminTool 2.0 Console

https://jira.secutix.com/browse/TIX2-183 TIXNGO Beacon Identifier not in separate column in the mobile logs in the TIXNGO console.

• As an organizer, I can know which tickets were activated by which beacon, in the new “Beacon name” column, which is displayed in the “Mobile Logs” screen and

  • Steward – valid name
  • Steward – invalid name
  • Gate – valid name
  • Gate – invalid name

Assign (keep) data missing fields (Nationality + ID passport number) + data feedback to S360

https://jira.secutix.com/browse/TIX2-1962 Assign (keep) data missing fields (Nationality + ID passport number) + data feedback to S360.

• The organizer can decide if the Nationality + ID passport number are requested (mandatory or optional) or not, when a ticket holder is assigning a ticket to someone coming along. The value of these two new fields are sent to S-360 through the TIXNGO-S-360 feedback interface.

• Backoffice AdminTool 2.0 Console >  Setting > Assignment Configuration: Nationality + ID passport number
  • 
• Backoffice AdminTool 2.0 Console >  Support ticket
  • 

Ticket activation green & blue screens automatic disappearance after X seconds

https://jira.secutix.com/browse/TIX2-2137 Ticket activation / green & blue screen don't disappear by themselves if no click.

• Ticket activation green & blue screens is used to display gate/entrance/turnstile information on the screen.

• Change previous behavior: the spectator must tap the colored screen to remove it.
• Change new behavior:
  • The spectator must tap the colored screen to remove it, if the new application setting color.fading.countdown is set to 0 (default 0).
  • The colored screen is automatically removed, after X seconds set in the the new application setting color.fading.countdown.

More flexibility on in-app Promos

https://jira.secutix.com/browse/TIX2-383 As an AdminTool user, I have more flexibility when setting Promos in the app.

• 1 or 2 free Promos

  • As an AdminTool user, I can set in AdminTool / Settings / Application Settings and Multilingual Settings up to 2 Promos in the app, with the following parameters: Image Url, Position, Title, Description, Url.

  • Change previous behavior: These Promos will be displayed as long as the wallet owner has at least one active or future ticket.

  • Change new behavior: These Promos will be always displayed (i.e. no condition on ticket).

• 1 "thank you for attending..." Promo → no change

  • As an Organizer, I can ask TIXnGO to set one "thank you for attending..." with their logo in the backend.

  • This Promo will be displayed as long as the wallet owner has no more active, nor future, but at least one past ticket.

  • This one is in Crowdin.

• Relative position between Events List Promo 1 and Promo 2 → no change

  • website_first

  • otherapp_first

My Profile mandatory information with asterisks *

https://jira.secutix.com/browse/TIX2-1987 As a wallet user, I see an asterisk ("*") next to mandatory fields.

• If the gender parameter is optional  if the gender parameter is mandatory:

Registration code: 5 tries and same code for 5 times

https://jira.secutix.com/browse/TIX2-181 As a wallet user, I receive by email the same registration code 5 times in a row, AND I can try to enter the registration code at a maximum 5 times.

• As a wallet user, I receive by email the same registration code 5 times in a row (i.e. first email, and then if tapping up to 4 times on "I did not receive my registration code: Resend"), then the registration code changes for the next 5 "Resend" requests, and so on. Sending 5 times the same registration code will help in case of bad network, we want to make sure the end user will enter the correct registration code.

  • 

• As a wallet user, I can enter and confirm a registration code 5 times max, then the wallet will request me to ask for a new registration code. This is a security measure to avoid brut force attack on the backend through API while registering, the backend should grant only 5 tries. After that, the end user will have to ask for a new registration code. The mobile app properly displays and explains the 5 unsuccessful tries and that a new code is required.

  • 

2FA to access the AdminTool

https://jira.secutix.com/browse/TIX2-1157 As a AdminTool 2.0 user, I have to pass a Second Factor Authentification (2FA)

• In the way to increase the security of the system, the organizer admin-user
• Experience
  • 
  • At the first login, a QR-Code is displayed to set the secret tokens (e.g. in Google Authenticator mobile app).
    • 
  • After a first successful login, at the next logins, the user inputs the real time 6-digit secret code (3 attempts max).
    • 
  • The AU can force the display of a new QR-Code at the next login if needed (which invalid the previous one).
    • 
• A comprehensive manual is available in the Backoffice manual / 2-Factor Authentication.