Follow

4.5.31.2 - Advorto release notes - Roll-out mid-January 2017

This release is mainly aimed at addressing a few minor known issues, but there's some key enhancements as well:

  • The new map display of vacancies in the Candidate portal may now be configured to be the default, rather than the standard vacancy list table
  • New invite to vacancy feature will now check whether or not a candidate has already applied directly or not (in addition to whether they have already been invited or not)
  • Usability enhancement for all forms to reduce the number of times data is sent back to the server - this is expected to improve user experience due to having less unexpected screen refreshes, which may cause users to be jumped back to a previous scroll position, etc.

Read on for a full summary of this release.

Backoffice

Invite to vacancy feature should not send invites to people who have already applied
The recently introduced "Invite to vacancy" functionality (used after a talent pool search), was allowing candidates to be invited to a vacancy, even when they had already applied and where they had not already been invited. The functionality has now been updated to take account of this scenario.

The "Already invited" message will now be displayed when a selected candidate has already started or submitted an application to the relevant vacancy and they will no longer be emailed.

Incorrect system status set when using the bulk vacancy menu to change workflow status
A bug with the bulk vacancy status change action in the Backoffice has been addressed. Previously, for clients with custom vacancy workflow statuses enabled, although the workflow status was updating as intended, the underlying system status change was not, resulting in a mismatch between the workflow and system statuses, e.g. an Archived vacancy not actually being truly archived.

Detaching documents from vacancies and requisitions when a doc field is not compulsory
This is an issue impacting a very small number of clients where vacancy or requisition documents are configured to be not compulsory. In this scenario, detaching a document and saving a particular vacancy or requisition was not saving the fact that the document had been removed. This issue has been resolved and requisitions and vacancies may now be saved with no documents added or after removing existing documents.

Candidate portal

Allow external candidate portal vacancy list to be configured to show in map mode by default
This is a new feature which allows the new map view of vacancies introduced in the previous release to be configured to be shown by default on the external Candidate portal, as opposed to the standard vacancy list table.

General (all system forms)

Forms should only post data back to the server automatically if they need to
This is a change to how application forms work. Previously, the system would consider that any fixed list-based field could have an option which may cause further fields or text to either show or hide on the same page. As such, when a selection was made, the data entered so far on a particular page would be posted back to the database and saved (this is known as a "post back").

For users with a slower connection; or where the form page included over a certain number of fields, this would result in a visible flicker whilst the data was being saved and the page refreshed. In the worst cases, users may have scrolled down the page or been able to enter text in a field immediately below, before the save completed. This, in turn, could result in text needing to be re-entered or an unexpected jump in the scroll position of the page occurring after the page had refreshed.

These "post backs" used to be triggered, regardless of whether they were actually required or not. Following this release, they will now only be triggered when necessary. This is expected to greatly reduce the number of times a form page posts data back to the server and therefore also to reduce the likelihood that unexpected jumps in scroll position occur, etc. In addition, where a post back does occur, it will always result in additional text or fields being displayed, which we expect to be more intuitive for users.

The change applies to all of the following form types:

  • Candidate application forms 
  • Candidate top-up forms 
  • Backoffice/User portal forms, e.g. Screening, etc. 
  • Requisition forms
  • Vacancy edit form

System Builder - Technical information for Partners

How to configure the external candidate portal vacancy list to display in map mode by default
To configure the vacancy list page to display in map mode by default, check the "Show map on first load" box on the Vacancy list configuration page in System Builder (System pages > Vacancies > Vacancy list). This feature is only obviously applicable if map mode and other relevant location-related configuration is also enabled and completed.

Only add geocode metadata to classifier items marked as location
This change addresses an issue where unneccessary geolocation-related metadata was being stored against classifier items in the system configuration files, where a classifier was not configured to be a location type classifier. The geolocation metadata will now only be stored when making self-service changes to classifier options for classifiers configured to be used for the purpose of displaying data on maps.

Candidate and Person sub item names are now mandatory
This change addresses an issue in System Builder, where it was previously possible to configure fields (Candidate or Person sub-items) to be available for Backoffice views, merge fields or reporting without specifying a name for the field, which results in the field not being available to report on in Analytics.

The page will now display a "Required" field validation message if the field name is left blank, preventing this. In addition, a new pre-flight check has been introduced to pick up this issue at the point of publish for any existing systems.

Restrict access to some Backoffice admin pages
This issue is a minor security enhancement to prevent unauthorised users from accessing a small number of configuration pages when they shouldn't have access to view these pages with their current security group or user type settings. Previously, the pages were only "hidden" because the links to them were no longer shown. Now, the users access rights will also be checked, which will prevent users from guessing URLs and accessing these pages.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk