TIX2-2415 / TIX2-2553 - Assignment data collection per event

This new features will make ticket assignment and management easier for organizers and mobile users alike. Here are the details of the changes:

Setting up the new required fields 

• Organizers can now set up extra fields for ticket assignment at the event level, using the AdminTool. These fields can be customized to collect any additional information that organizers may need from ticket holders.

• When assigning a ticket in the mobile app, the new fields will either be mandatory or not visible, depending on the configuration set in the Admin Tool at the event level. If the fields are visible, users can input the required values, which will be saved automatically.

• On the mobile app, in the ticket detail screen, the name of the ticket holder is now clickable. Clicking on

• The value of the new fields entered by mobile users will be sent to S360 using the Feedback interface. (if you are using the S-360 feedback interface).

• Additionally, the new fields will be displayed correctly in the Support Ticket section of the Admin Tool, allowing organizers to view and manage the additional information collected from ticket holders.

Admintool setup per event	Guest details collection on the app
Open	Open

Data collection on the mobile app

Two new popups have been added that notify spectators about missing information for wallet owners and guests. The popups is displayed when spectators download their tickets and it will redirect them to the correct page to fill in the missing information.

There are different scenarios for when the popups will appear, depending on the number of tickets that require extra information. If the wallet owner has not received any tickets for an event that requires extra information, then no popup will appear.

If the wallet owner has one ticket for an event that requires extra information, a popup will appear if the Ticket owner is not yet assigned or has not kept for ticket for himself.

• Pop-up 1 appears for the wallet owner

• Pop-up 2 appears for additional tickets for guest of the wallet owner. (assign or keep action required).

For example : If the wallet owner has two tickets for an event that requires extra information, several scenarios can arise. If the Ticket owner's extra fields are missing for both tickets, P

If the wallet owner has two tickets for two different events that require extra information, the same behavior as in the case with one event will occur.

These changes will make it easier for organizers to collect and manage important information from ticket holders, while also improving the mobile user experience. These updates will enhance the overall ticket management process for everyone involved.

TIX2-2723 - Quick manual check on event day and event day + 1 only

The quick manual check feature that let's you check a ticket manually with a double tap was possible no matter the date when it was enabled.

From now, the quick manual check will be only possible on event day and event day + 1. This new feature will make sure we don't have situations where tickets are activated well in advance (e.g. event day - 2) and the tickets are being check prior to event day by error. Reducing this risk will reduce the number of troubleshooting that may need to happen in such situation.

TIX2-2595 Admin tool pagination improvement

You can now jump to the page you want directly by typing in the page number in the pagination component. 

Open

TIX2-2712 - Beacon instance ID can be the same across a whole event for all activation groups 

If you are users of beacons for ticket activation or checks you know that TIXNGO supports the following mode :

• dynamic beacon instance ID generated per activation groups (different instance ID for each activation groups)

• static beacon instance ID across the whole app (systematically the same instance ID for all events and all activations groups)

In this Breithorn V1 release, we are introducing a new dynamic mode :

• NEW : dynamic beacon instance ID generated per events (same instance ID across all activation groups of a given event but different instance ID for each events)

This new mode facilitate the configuration and configuration changes for a whole event while keeping a strong level of security with different instance IDs per events.

How to use this new mode ?

• A new setting key introduced named bt.instanceid.unique-per-event and set to tru

• Please note that this setup needs to be done during the onboarding process. To activate it, please reach out to your Professional services manager.

Open

TIX2-2016 - Event group management improvements

The event group feature available in TIXNGO let you group event under an event group name that you can define at the injection. This release is extending the event group feature by introducing some improvements to provide more control and visibility :

• See easily the list of events/tickets belonging to an event group

• Move an event from one event group to another

• Include event group filters in all relevant screens on the admintool. 

AdminTool improvements

1. To change an event from Event Group A to Event Group B:

Open

2. In the event list screen

3. Ticket list screen 

On the API side, a new endpoint has been created to return the list of event group id and event group name (for the dropdown)

Please note that the system will automatically delete old event group not having any event associated to it.

1. TIX2-641 - Inject and search by Contingent (STG) in the Ticket List screen

2. TIX2-1872 - Search by Contingent (STG) in the Transaction list, Transaction pending

3. TIX2-1873 - Search by Contingent (STG) in Reports

1. Injection and search in Ticket List screen 

• 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 

Open

• New table REFERENCE_DATA, example:

Open

• Injection API (dependency on S-360)

Open

• 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.

Open

2. Search by Contingent (STG) in the Transaction list, Transaction pending

• If the organizer turns on the contingent feature:

  • Transactions screen

    • Filter by the contingent correctly.

    • Export: contingent and seat details are

3. Search by Contingent (STG) in Reports

• If the organizer turns on the contingent feature:

  • Reports

https://jira.secutix.com/browse/TIX2-2332 [Crowdin] Change Crowdin on the fly, do not require to upload a new build.

Business benefits: Speed-up and ease the process of updating strings in the mobile wallet.

• Old behavior

  • Step 1: Client and BA changed translation strings in Crowdin.

  • Step 2: BA created a ticket on Jira and assigned it to the development team.

  • Step 3: Developers changed the text on the local file (.json).

  • Step 4: Developers rebuilt the white-label mobile wallet and shipped the application to the client.

• New behavior

  • Step 1: Customers and BA change translate string in Crowdin and click “build project” on Crowdin.

  • Step 2: The mobile wallet users relaunch the TIXNGO application.

Open

Crowdin on-the-fly loading system flow

Open

Crowdin translation available in the app if the synchronization was done successfully after being triggered by the app loading

Disable / enable Crowdin synchronization

A new setting is available to enable/disable the crowdin sync feature and works as described below :

If the enable-crowdin-sync setting is set to true, the app will load the latest translations from Crowdin every time it is loaded. If it is set to false, no call to Crowdin will be made, and the translations will be loaded locally.

The local file on the app will contain translations from the last successful synchronization with Crowdin.

In case an organizer changes the value from false to true

If the enable-crowdin-sync setting is already true, and the app fails to synchronize with Crowdin, the local file will be loaded with the latest version successfully synchronized.

Open

https://jira.secutix.com/browse/TIX2-2262 Brute force protection for Console.

Business benefits: Add additional security into the Backoffice.

• Implementing the Amazon Cognito lockout behavior for failed sign-in attempts (c.f. https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html)

  • After five failed sign-in attempts, Amazon Cognito locks out your user for one second. The lockout duration then doubles after each additional one failed attempt, up to a maximum of approximately 15 minutes. Attempts made during a lockout period generate a Password attempts exceeded exception, and don't affect the duration of subsequent lockout periods. For a cumulative number of failed sign-in attempts n, not including Password attempts exceede exceptions, Amazon Cognito locks out your user for 2^(n-5) seconds. To reset the lockout to its initial state, your user must not initiate any sign-in attempts for 15 consecutive minutes at any time after a lockout.

  • Open

    

https://jira.secutix.com/browse/TIX2-184 Number of active sessions is missing in the spectator export in the TIXnGO console.

Business benefits: Add additional information in the spectator export.

• Add a new column "ACTIVE SESSIONS" in the Spectators List/Export CSV file.

• This column is placed right after PINCODE column.

• The values of this column are exactly the values displayed on the Spectators List screen.

• Open

  
  Open

  
  Open

  

https://jira.secutix.com/browse/TIX2-624 [All organizers] As an AdminTool 2.0 support-user (SU) and basic-user (BU), I can also resend communications under Support-Spectator page (so far only admin-user (AU)).

Business benefits: Provide more flexibility to the operations and enhance the Backoffice rights for SU and BU.

• Old behavior: only admin-user (AU) can also resend communications in the Backoffice under Support-Spectator page.

• New behavior: support-user (SU) and basic-user (BU) can as well.

• Reference: TIXNGO Portal / Backoffice manual / User roles and privileges: TIXNGO:Backoffice

• Open

  
  Open

  
  Open

  
  Open

  

https://jira.secutix.com/browse/TIX2-2116 We need logic in the app to activate offline mode is case of not working backend, so we can prevent loss of tickets.

Business benefits: Provide a last-minute security backup to activate the tickets.

• In case the organizer decides to use online-activation tickets and some edge cases failures occur (e.g. some offline phones, some phones with Bluetooth issue, some TIXNGO backend issues), TIXNGO have now introduced this emergency offline time-based that will activate the tickets no matter what, to make sure the barcode

  •  Application Settings / key: ticket.emergency.activation / description: Minutes before the event starts to activate tickets offline (set 0 to turn off the feature)

  • Open

    
    Open

    
    Open

    
    Open

    

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

Business benefits: Personalize with a message the transfer of a ticket.

• As a registered wallet user and transferable ticket holder, I can start the transfer process of a transferable ticket directly on the ticket "Send your ticket" section, and on the Floating Action Button (FAB).

  • Open

    
    Open

    

• 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).

  • Open

    
    Open

    
    Open

    
    Open

    
    Open

    
    Open

    
    Open

    
    Open

    

• If the new "Transfer Message" feature is enabled in the Backoffice / Application features / transfer-message and in the ticket transfer email template (c.f. make sure to include the parameter $$message$$ in your transfer templates to make sure recipient can see the content of it, more information detailed in the Mobile Wallet manual here: Wallet Features#TRANSFERMESSAGE), 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).

  •  

    Open

    
    Open

    
    Open

    
    Open

    
    Open

    

• Crowdin new strings to translate:

  • recipient_confirmation_page_description

  • transfer_recipient_empty_value

  • add_recipient_email

  • transfer_functionality_title

  • transfer_functionality_description

  • transfer_message_input_title

https://jira.secutix. As a wallet user, I can see on the ticket,

• 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

• Open

  
  Open

  
  Open

  
  Open

  
  Open

  

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.

• Open

  
  Open

  

TIX2-1769 / TIX2-1882 / TIX2-1883 Inject multilingual data for events, Manage multilingual data for events on AdminTool and export events multilingual from AdminTool.

Inject multilingual data for events

• 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, the event’s default language will be displayed (English) (including its tickets label).

• If an event is supporting a spectator’s app language, the event information by the app language of this spectator will be displayed (including its tickets label).

• JSON format example.txt (format required to inject several languages)

Open

Manage multilingual data for events on AdminTool

AdminTool 2.0 supports multilingual configuration for event and ticket details. Organizers can view and update event information in multiple languages. When switching to another language, a confirmation pop-up message will be displayed if there are unsaved changes. Changes made in each language will be saved separately. 

Open

Export events multilingual from AdminTool

Organizers can export multilingual content of their events and send it to reviewers for review for example. With the "Export Multilingual" button on the Events screen, all search results events will be exported to a CSV file, including event information and ticket detail labels in multiple languages. The exported data fields include Event ID, Group Event ID, Event date and time, Section, Rank, Language.

Open

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.

    • Open

      
      Open

      

  • Inject a ticket to userinjection pending) → search for this spectator in the AdminTool with status inactive (similar to user did not complete registration process).

    • Open

      
      Open

      
      Open

      
      Open

      

  • 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).

    • Open

      
      Open

      
      Open

      
      Open

      

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 activation, and have label "non-transferable ticket".

• 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