Overview
The Q4VR Barefoot integration was refactored to accommodate customers who have more than one location & website but will share the same PMS account. Additional configuration fields are available within the Q4VR Plugin and Q4VR Hub to make this happen.
Barefoot Area Filtering
To segregate properties within one PMS account Barefoot allows for filtering based on an “area” amenity code. This code is required when a Barefoot client has multiple locations but does not want all properties to appear together during a search.
The Q4VR Plugin & Hub were enhanced to handle this.
New Barefoot Property Areas tab
Area Amenity & Area Amenity Values
The above configuration is only required when the client requires a separate Q4Launch site for a subset of their properties via the Barefoot “area amenity filtering.”
VR Plugin Amenity Configuration
Background
When the VR Plugin runs the property sync, the implicit and configuration settings that need to be considered.
Implicit (automatic) settings:
During the property sync for Barefoot clients, the plugin calls the HUB for each property and the HUB returns “Core” amenities which are saved against the property:
These “Core” amenities are determined by a mapping setup in the HUB on a client by client basis, noted in the HUB Barefoot Amenity Configuration documentation. Each of the above “Core” amenities are saved with the property and can then be seen in the VR Plugin → Vacation Rentals → Filters page:
Additionally, these “Core” amenities can immediately be configured in the VR Plugin Basic or Advanced Search configuration.
Non-Core Amenity Usage
To use other Barefoot amenities, they must be configured in the Amenity tab exactly as they are received from the HUB.
The value received from the HUB must be set as the Amenity name in the Choose Amenities tab. Once the Amenities are entered they may be used in the Basic Search & Advanced Search.
Basic & Advanced Configuration
When amenities are required in more than one search parameter, the search parameter configuration must be of type “Taxonomy”. This is required to avoid a bug with parsing the query string as the query string has multiple “filter=” parameters and if Taxonomy is not used, only the last “filter-” is used. When Taxonomy is used, each filter parameter is consolidated into an array.