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)

• Enable organizers to classify a ticket by a contingent.
  • 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 contingent,
  • Export the ticket with the contingent then doing some analysis.
• New Back Office AdminTool 2.0 Console > Settings > Organizer Settings > enable.contingent.feature 
  • 
• New table REFERENCE_DATA, example:
  • 

• Injection API (dependency on S-360)

• 

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 (or manually), the ticket cannot be transferred.
• The organizer can allow/disable the ticket transfer after the Bluetooth activation by setting parameter transferRules.allowTransferAfterActivationByBT to TRUE/FALSE per ticket level (default = TRUE).
• 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 Bluetooth 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 Bluetooth 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
  
  • 

Screenshot and screen recording protection (native)

https://jira.secutix.com/browse/TIX2-1809 [Screenshot/recording protection] As TIXNGO, I replace ScreenShieldKit existing solution by implementing flutter library screen_protector (available on https://pub.dev/).

Related to the previous delivery in 2022 Weisshorn V2 all organizers: 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.

  • 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 the “Mobile logs of spectator” list of the “Support Page” screen, as follow:

  • 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 (AU) can enable/disable a Second Factor Authentification (2FA) on the AdminTool for the users (i.e. support-user (SU), basic-user (BU), moderator (Mod)). The feature is disabled by default. If the organizer also wants to activate the 2FA for the AU, they should contact TIXNGO as an additional service.
• 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.