Release notes 4.19
Accounts
To ensure the flexibility organisers need when giving their team access to Visit Create, we’ve made significant changes to Accounts. There are more options for different permissions, and permissions are grouped into roles. User accounts can be a member of one or more roles to assign the permissions.
UI/UX
- Accounts are now an integral part of the menu Organisation > Accounts.
- We have removed account types. All new accounts created will be Standard. Following the release, all former Administrator accounts will be converted to Standard, while keeping the same permissions.
Permissions
- We have extended the permissions list to better capture the different scenarios and needs when using Visit Create.
- Permissions can be assigned 2 different modes: read-only (view information, no edit rights) and read/write (can add/change information too).
Roles
- We have created default roles with default associated permissions. Permissions for default roles can be amended based on needs. An account can have one or more roles assigned, however it will inherit the permissions of the most “powerful” role.
Example: If a user is assigned two roles, and one has, for example, a ‘read only’ permission to Shop, and the other role has ‘read/write’ permission to Shop, then that user will be granted the higher read/write permission.
- We have added the option to edit these default roles and to create custom roles within an organisation. Custom roles and their set permissions can be used across all organisation and its events.
Other
- Activity log has been moved to Organisation > Accounts and renamed to Log.
- When creating an account, you can decide to restrict its access to specific events.
- A list of all accounts can be exported from Visit Create.
- Accounts with no activity within the last 6 months will be automatically disabled.
API keys
- API is now part of the main Visit menu under Organisation.
- To manage API keys, a user will need to have the API permission enabled.
- An API key can be restricted to specific IP addresses. There is now a field which allows the API key managers to set location restrictions.
- API keys are, from now on, only visible to people within the organisation they belong to (previously visible to Visit support team too).
- API keys can now be exported from Organisation > API > Keys.
Improvements
- Country list – you can hide and translate countries now.
- Formatting phone fields – Phone numbers are now formatted into a standardized way.
- Activities – users can now download all on-site activity logs, directly from the Service Centre.
- Registration type rule – we have added a new rule which assigns users a specific registration type based on the session(s) they purchase. Users can add a minimum limit of a session which need to be purchase in order to link registrants to a specific registration type.
- Licenses – an overview of all licenses issued with an event is now available in Event > Licenses.
- Seminars – users can now filter seminars per location and/or per seminar and download a file with only the seminar/location(s) of interest.
- Dynamic fields – we have renamed #badge_code# to #visitor_code# and #registration_key# to #contact_code#.
Payments
Mollie is now part of our directly integrated payment service providers – https://www.mollie.com(opens new window)
Security enhancements
Two-factor authentication
For a more secured access to Visit Create, we have enabled two-factor authentication (2FA), whereby a user is sent a code to their device as part of the login process.
- 2FA can be set for each role. Any user who is a member of a role requiring 2FA will be required to enter an additional code to access Visit Create.
- By default, only super user accounts will have 2FA enabled. For standard accounts this has to be manually added by the person managing Accounts, under each chosen role.
- By default, when 2FA is enabled, a verification code is sent to the email address that the account is associated with. However, if desired, the code can also be sent to an authenticator app on a smartphone, sunch as Google Authenticator or Microsoft Authenticator. Alternatively, if a mobile number is provided, the code can be sent via SMS.
- Users can opt to ‘trust’ their device and not need another authentication code for 7 days.
- For those cases in which there is a phishing attack suspicion, we’ve added the option for the Accounts user to force all users in their organisation to change their password.