Help Centre Forum

TOTECS Forums

TOTECS Platform Release 15.01

Author
Thread

Author moderator
23rd March 2021
View details of the 15.01 TOTECS platform release. watch key details at https://youtu.be/WyxNY2s1N9E

New Features


TOT-4056 - Send submitted order data to Google Analytics from Order Checkout/Submission and Guest Order Checkout/Submission content managed web page areas

On a content managed website containing a webpage with either a Order Checkout/Submission area, or a Guest Order Checkout/Submission area, once an order has been submitted there is now the ability to send the confirmed order details across to Google Analytics via its Google Tag Manager feature, allowing Google to provide additional statistics on details of the users, orders and products associated to the orders being submitted.
To allow the ordering areas to send order information back to Google Analytics the following needs to already have occurred:

  1. A Google account has been created
  2. Google Analytics has been enabled for the account
  3. Ecommerce Reporting has been turned on within the Google Analytics account
  4. Google Tag Manager has been enabled for the account
  5. At least one tag has been created within Google Tag Manager that is used to record submitted orders against it.
  6. The Tag within Google Tag Manager is linked to a "Google Analytics: Universal Analytics" tag type, with its Track Type set to "Transaction", and the Google Analytics settings contains the Tracking ID of the Google Analytics account
  7. The Tag within Google Tag Manager contains a custom event trigger with a specified name, such as "confirmed-sale, purchase, weborder"

Once both Google Analytics and Google Tag Manager have been set up, then within the Administration Centre, under the Websites menu, within the Websites interface, upon editing a content managed web page that contains either a Order Checkout/Submission area, or a Guest Order Checkout/Submission area, in the area settings dialogs the following settings have been added under the "Order Reporting - Google" sub heading:

  • Google Tag Manager ID: ID that google has been for the Google Tag Manager account to report order submissions against
  • Google Tag Event Name: Name of the custom event that has been set up in the trigger for the tag within Google Tag Manager
  • Report Orders To Google Tag Manager: If set to Yes then when a user submits an order, the order details sent across to Google Tag Manager and on to Google Analytics. The order data reported includes: Order ID, name of the company supplying, order total inc. tax, order total tax, order surcharge total inc. tax
  • Report Order Products To Google Tag Manager: If set to Yes then when a user submits an order, the order details sent across to Google Tag Manager will also include a list of products submitted. In the order product data will include, product code, product name, unit price inc. tax, quantity

Note that the Google Tag Manager ID, Google Tag Event Name, Report Orders To Google Tag Manager settings must all have values set, otherwise no order data will be send to Google.
Also note that there's no guarantees that the order data will be successfully recorded within Google's system. This is because the user may have blocked or not allow the ordering data to be sent to Google, or Google's servers were unavailable at the time the order was submitted, or Google Tag Manager/Google Analytics may have been misconfigured.

Functionality Affected: Order Checkout/Submission, Guest Order Checkout/Submission content managed web page area
Impact: Normal

 

 


TOT-4033 - Eway Payment Gateway 3D Secure credit card payments within Order Checkout/Submission content managed web page areas

On a content managed webpage containing either Order Checkout/Submission or Guest Order Checkout/Submission areas there is now the ability to handle having credit card payments be made via version 3 of Eway's payment gateway, supporting 3D secure payments that may require users to be taken to a separate website to authenticate themselves (typically the credit card issuing bank's website), before allowing the credit card payment to be applied. The can provide banks with greater certainty of the credit card holder, and transfer the risk of a fraudulent transaction from the seller to the bank. This capability has been added to the Order Checkout/Submission area by supporting Eway's "Transparent Redirect" feature https://eway.io/api-v3/?shell#transparent-redirect
Within the user reaches the Payment Form, after filling in their credit card details and clicking on the Pay button, the user will be redirected to Eway's servers to create the payment. Eway may then either redirect the user onto the banking website to authenticate themselves if Secure 3Ds is turned on in the Eway payment gateway profile. Once the payment is confirmed the user will be redirected back to the content managed website where the payment will be verified with Eway, and if successfully the user will be shown the success area, or otherwise be shown the credit card payment form again with the error that may have occurred (such as incorrect card details).
To enable this capability, within the Administration Centre, under the Stores menu, within the Payment Settings interface, under the Credit Card section, the "Credit Card Payment Gateway" setting now has the option "EWay (With 3D Secure Support/API v3)". If this option is saved then all Order Checkout/Submission areas on content managed websites will use above capabilities for users to pay for orders.
Two additional settings have been added to the Payment Settings interface:

  • Credit Card Api Key: This needs to be set to the API key that Eway provides for each customer profile within its system.
  • Credit Card Api Password: This needs to be set to the API password that can be customised within the Eway customer profile in its system.

Note that the Credit Card Api Key and Credit Card Api Password settings are only required to be set values if the "Credit Card Payment Gateway" setting is set to "EWay (With 3D Secure Support/API v3)". Otherwise these settings can be left empty for all other payment gateways (as of the time this was written).
Also note that if the "Credit Card Payment Gateway" setting is set to "EWay (With 3D Secure Support/API v3)" and credit card payments are made either through the Administration Centre's Payment interface, or by users for invoices within the Account Enquiry feature, the payment gateway used will be "EWay (With Card CVN Number Checks)" instead. As such the "Credit Card Merchant Id (customer Id)" setting will need to be set to the Eway Customer ID for these credit card payments to be accepted by Eway.
Also note that for sellers wishing to use 3D Secure, this capability needs to be turned on within Eway's system, as well as the merchant bank account that the payments are being placed into needs to be a bank that supports 3D Secure as well as Eway supports. We suggest talking to Eway and the bank itself for performing these checks and setup work.

Functionality Affected: Store Settings administration centre interface, Order Checkout/Submission and Guest Order Checkout/Submission content managed web page areas
Impact: Normal

 

 


Improvements


TOT-3930 - Replace Adobe Flash multi file uploader to HTML 5 based file uploader within Administration Centre

Within the Administration Centre, under the Websites menu within the Website Libraries interface, and under the Data menu within the Product Images and Category Images interfaces, the Adobe Flash Multiple File Uploader has been replaced with a Javascript based file uploader using HTML 5 functionality to allow for multi-file selection and uploading of files.
After administrator users can click on the Select Files To Upload button, they can select or more files from the file system, Alternatively users can drag and drop files directly on the Select Files To Upload button from a file explorer window.
These files will be added to the upload queue and be displayed within a list. Upon the user then clicking on the Start Image Uploads button. Each file in the queue will attempt to be uploaded one at a time. The status of the upload will show against the file being uploaded. If successful then the file's status will be changed to uploaded. If an error occurred then a message will display containing the cause of the error. If the Stop Image Uploads button is pressed then any files in the queue not yet uploaded with be cancelled from being uploaded. If the user clicks on the Clear Image Upload List, then any queued files will be cancelled and cleared from the list. If a file is attempted to be uploaded and succeeds or fails, then the file cannot be uploaded again unless its added to the queue again.
Note that for image uploads for products, categories and against content managed web page image libraries the image files need to be under 2MB in size and have the file extension jpg. jpeg, png or gif, otherwise if the files are selected they will be ignored from being added to the queue. For files being uploaded to the content managed website attachment libraries, the max file size is set to 15MB. If these file sizes are exceeded then error messages will display with the reason why the files could not be uploaded.

Functionality Affected: Website Libraries, Product Images, Category Images administration centre interfaces
Impact: Normal

 


TOT-4012 - Display make/model product attribute values within the Model Product content managed web page area

On a content managed web page that displays a a Model Product area, the area can now be configured to display attribute values that have set against each product that has been assigned to a make/model for a given category. Additionally within the Make/Model Administration Centre interface there is now the ability to see the attribute values assigned to each model-product-category record, as well as create and remove attribute values.
Within the Administration Centre, under the Websites menu, within the Websites interface, upon viewing the a web page containing a Model Product area in the Web Page Editor. Within the area's settings window, a new setting labelled "Display Model Product Attribute Values" now displays, if set to Yes then this allows the areas to find and display attribute values for each product-category displayed in the area.
Additionally the following formats have been added to the Model Products area:

  • Model Product Attribute Value Record: This format controls how each attribute value record is displayed when viewed against each product-category record displayed in the area.
  • Model Product Category Record: This format controls the surrounding formatting and structure for each product-category record, including the positioning of the collection of attribute values assigned to each product-category record, as well as the positioning of the formatted product data shown using the Product Search Record format.

These formats change how area works, with now the Product Search Record format now embedded within the "product_search_record" hook of the Model Product Category Record format. For existing Model Products areas if no Model Product Category Record format is assigned to the area then the area will directly embed the Product Search Record format into place where this format would be set, allowing existing areas to not be altered or affected.
Note that model-product-category attribute values can be created/imported from external systems through the "Model/Product/Category Mappings" Connector data import, and is the preferred way of creating the attribute data when 1000s of models exist.
Within the Make/Model administration centre interface, upon clicking on the Products count column of a model, within the Model Products dialog an additional column labelled "Attributes" now displays, showing how many attribute values are assigned to each model-product-category record. Upon clicking on a value in the Attributes column, will display the Model Product Category Attributes dialog that shows all the attribute values assigned to each model-product-category record. Attribute values can be deleted by clicking on the delete icon, and attribute values can be assigned by typing in the attribute profile name, attribute, and value into the dialog's form and clicking on the Add Value option. For this to work attribute profiles and attributes need to have previously been created/inported to the Products Attributes administration centre interface.
Also within the Make/Model administration centre interface, within the Model Search drop down the following search filters have been added to provide additional ways to search for models:

  • Key Maker Model ID: Find models that have search value matching the Key Make Model ID
  • Active Models: Find all models that are active
  • Inactive Models: Find all models that are inactive
  • Product Code: Find all models that have products assigned to them with a Product Code containing the search value set.
  • Product Name:Find all models that have products assigned to them with a Product Name containing the search value set.
  • Product Key: Find all models that have products assigned to them with a Product Key containing the search value set.

Within the Model Detail dialog there's now the ability to view the Key Make Model ID set for each model, as well as update the key. This relevant if models have been imported using the Make/Model Connector data import.

Functionality Affected: Make/Model administration centre interface, Model Products content managed web page area
Impact: Normal

 

 


TOT-4043 - Limit the number of failed credit card payment attempts allowed by users when paying for orders

Within the Trade interface's Order Detail page, as well as on a content managed webpage containing either an Order Checkout/Submission area, or Guest Order Checkout/Submission area, if the user chooses to pay for an order with the credit card payment type, then after the user enters their credit card details in the credit card payment form and clicks the Pay button, the number of failed payment attempts that is allowed to occur in a user's session is now limited to 5 attempts. Once the limit is reached then no more credit card payment attempts will be passed across to the payment gateway's, avoiding the payment gateways and banks receiving a large amount of credit card payment attempts.
This helps reduce brute force attempts being made to guess credit card credentials, such as when automated software is used to perform these attempts.
When the credit card failed payment attempts threshold is reached, the user will always see the error message "Unable to process the credit card payment due to the maximum number of attempts being reached. Please contact us to complete your payment." until the user logs out and in again. After that they will be allowed another 5 credit card payment attempts. For guest users they would need to create a new session to allow further credit card payment attempts to be made, either by closing and reopening their web browser, or clearing their browser cache, or by using a different web browser.
Guest users would also need to add products to basket again, proceed through the order checkout process again and pass Recaptcha checks before being allowed another 5 credit card payment attempts for orders.

Functionality Affected: Order Checkout/Submission and Guest Order Checkout/Submission content managed web page areas
Impact: Major

 


TOT-4045 - Add settings to allow Recaptcha to display within credit card payment in Order Checkout/Submission content managed web page areas

On a content managed web page displaying either a Order Checkout/Submission area, or a Guest Order Checkout/Submission area, if a user has selected to pay for an order with the credit card payment type, then upon proceeding to the Credit Card Payment Form, there is now the ability to show a recaptcha form element that checks to see if a real human is entering the credit card details. This reduces the chances of automated software attempting to make a credit card payment.
Within the Administration Centre, under the Stores menu, within the Payment settings interface, under the Credit Card section, a setting labelled "Require Recaptcha For Credit Card Payments" has been added that controls if the Recaptcha element should be used within the credit card payment from within content managed web pages displaying Order Checkout/Submission and Guest Order Checkout/Submission areas.
Within the "Payment Credit Card Form" content managed web page area format a hook labelled "cc_recaptcha_field" has been added that allows the Recaptcha form element to be embedded within the format, allowing it's position to be customised, The hook will only display a Recaptcha form element if the Require Recaptcha For Credit Card Payments setting is set to Yes, otherwise the hook will be empty, This hook must be embedded within the area's format if the Require Recaptcha For Credit Card Payments setting is set to Yes, otherwise the user will be blocked from submitting the payment and see a failed Recaptcha error message.

Functionality Affected: Store Settings administration centre interface, Order Checkout/Submission and Guest Order Checkout/Submission content managed web page areas
Impact: Normal

 


TOT-4048 - Modify login process to redirect using secure redirect URL after user has successfully logged in from a secure content managed website to avoid browser warnings

On a fully secure content managed website that contains a web page with a User Login area, once the user enters their login credentials and clicks on the Login button, the redirect URL that directs them back to the content managed website now uses the https: protocol to load the content managed webpage without having to resort to an additional secure redirect.
This avoids users logging into a content managed website from seeing an warning messages presented by browsers. If the user is logging into to either the Trade interface or the Administration Centre, then an additional webpage load will occur to correctly redirect the user to the home page of either interface without a browser message occurring.

Functionality Affected: User Login content managed web page areas
Impact: Normal

 


TOT-4059 - Limit invoice credit card payment attempts to one at a time within Customer Account Invoice Payment Form content managed web page area

On a content managed web page displaying an Account Invoice Payment Form area, if a user double clicks on a Pay button it is no longer possible that multiple requests will be sent to the server to apply credit card payments to pay for the selected invoices.
Within the area's "Invoice Payment Form" format, the credit_card_payment_onclick javascript function will only allow one payment request to be sent through, any subsequent attempts will be ignored until the previous payment request has returned a response and the area has updated itself with the result.

Functionality Affected: Account Invoice Payment Form content managed web page area
Impact: Normal

 


TOT-4065 - Settings to control passing delivery address details to Paypal in Order Checkout

For the Order Details page on the Trade interface, as well as on content managed web pages that contain the Order Checkout/Submission area, as well as the Guest Order Checkout/Submission area, if a user selects the Paypal payment type, then when the user is directed to Paypal from the Order Review stage, there is now the ability to pass the delivery address information across to Paypal. This allows more information to be stored against the payment in Paypal, and may allow Paypal to perform additional validity checks on the payer, covering costs of fraudulent activity through its Seller Protection mechanism.
Within the Administration Centre, under the Stores menu, within the Payment Settings interface, under the Paypal payment section, an additional setting has been added labelled "Set Delivery Address In Order Payments" that controls if order delivery address should be passed across to Paypal or not during the Order Checkout process. If the setting is set to Yes then when the user proceeds through the checkout process and is redirected to Paypal, within Paypal they will now be able to see the delivery address they set for the order. Note that the user won't have the option to modify the delivery address unless they navigate back to the Order Details page. Once the user has completed the Paypal payment and submitted the sales order, then within the seller Paypal account, in the payment Transaction Details page it will display the delivery address details with a status indicating if the address is eligible for Seller Protection from Paypal.
Note that if the "Set Delivery Address In Order Payments" setting is set to Yes then it's allow customer's address details to be shared with Paypal, and Paypal may use this information for a variety of means (see their terms and conditions to understand). If you don't want Paypal to know your customer's address details then its best to leave this setting to No, which is the default value (and note that you could be liable to cover costs if the payment is charged back at a later stage by Paypal).

Functionality Affected:  Order Checkout/Submission, Guest Order Checkout/Submission content managed web page areas
Impact: Normal

 


TOT-4067 - Modify Product Search admin centre interface to contain an advanced search rule to find products that have fields without values set

Within the Administration Centre, under the Inventory menu, within the Product Search interface, within the Advanced Search form, for the Search Category "All Products", in its "Select all products where" rule, for the "equal to" drop down it now has 2 options labelled "is empty" and "is not empty", that can be used to find products that don't have a value set within the selected field, or do have a value set in the selected field.
Additionally for the search rule, within the the list of fields to choose from now includes the 4 description fields, and the 3 meta product fields (seo) fields.

Functionality Affected:  Product Search administration centre interface
Impact: Minor

 


TOT-4070 - Setting to allow Receiver Name in SmartFreight order to be set as delivery contact name if delivery org name is empty

When an order is submitted either through the Trade interface, on from a content managed web page area containing a Order Checkout/Submission area or Guest Order Checkout/Submission area, if the project is configured to send the order to Smartfreight, then in the SmartFreight order request there is now a setting that controls what order data should be placed in Receiver Name when the order is submitted to SmartFreight. This field will be set to the delivery address's org name, or it is empty then either the delivery address contact name, or the customer account company name.
Within the Administration Centre, under the Stores menu, within the Freight Providers settings interface, under the "Freight Provider - SmartFreight" section a new setting labelled "SmartFreight Order Receiver Name" has been added, it can be set to one of the following values:

  • Delivery Address Org Name else Account Company Name: When orders are submitted to SmartFreight it will place the order's delivery address org name into the Receiver Name field. If the org name is empty then the Customer Account Company Name will be used instead. This is the default option.
  • Delivery Address Org Name else Contact Name: When orders are submitted to SmartFreight it will place the order's delivery address org name into the Receiver Name field. If the org name is empty then the delivery address's Contact Name field will be used instead. If the contact field is empty then the Customer Account Company Name will be used instead.

It's recommended to use the Delivery Address Org Name else Contact Name option if the website supports consumer/retail based ordering, where users may be ordering personally for themselves and not for a company.

Functionality Affected: Smartfreight Order Submission
Impact: Normal

 

 


Bug Fixes


TOT-4047 - Product deal with the offer Buy Product Quantity X and Get Quantity Y for Z Percent Off Product Price incorrectly over discounting

Within the Administration Centre, under the Marketing menu, within the Product Deals and Vouchers interface, if a deal was created with the offer "Buy Product Quantity X and Get Quantity Y for Z Percent Off Product Price", when the user redeemed a deal after adding a product to basket with the allowed quantity in a content managed website, the individual quantity was not being multiplied by the Y quantity set in the deal, This in effect allowed an almost 50% discount to always be applied.
The deal now correctly applies the discount percentage against the quantities that are applicable to the deal.

Functionality Affected: Add Product To Basket process
Impact: Normal

 


TOT-4051 - Previous Instructions drop down not sorting instructions by last order date within the Order Details page in the Trade interface

Within the Trade interface, after clicking on the View Basket button, then clicking on the checkout button, on the Order Details page, within the Previous Instructions drop down the instructions are now being sorted correctly based on the order date that the last unique instruction occurred an order.
Previously the previous order instructions were incorrectly being grouped first, before being sorted, leading to the same instructions for later orders being ordered based on earlier orders where the instructions occurred.

Functionality Affected: Order Detail Trade interface
Impact: Normal

 


TOT-4053 - Invoice text line description hook is not displaying any text within the Customer Account Invoice content managed web page area

Within a content managed web page containing a Customer Account Invoice area, if the area is displaying an invoice that contained a text line with a description, the Customer Account Invoice Line Text format's "invoice_line_description" is now correctly displaying the description set within the invoice line data.
Previously it was not displaying the invoice line description for text lines.

Functionality Affected: Customer Account Invoice content managed web page area
Impact: Minor

 


TOT-4054 - Guest Order Checkout/Submission content managed web page incorrectly setting [INVALID FORM VAR] within deliveryOrgName and billingOrgName address fields if fields arn't embedded in area

On a content managed web page area that contains a Guest Order Checkout/Submission area, if the area's Order Details Form format does not have either the delvrnew_orgNameField or billingnew_orgNameField fields embedded within the area, then in the delivery address org name field or the billing address org name field, it will now correctly set empty values for these ordering fields.
If these fields are not embedded within the Order Details Form format then the field values should be set to empty text.
Note that for existing orders this fix won't remove the [invalid form var] text from the billing and delivery address data, the change only affects new orders that are submitted.

Functionality Affected: Guest Order Checkout/Submission content managed web page area
Impact: Normal

 


TOT-4057 - Yearly Project Traffic statistics displaying incorrect year label within the Project Traffic Statistics Administration Centre interface

Within the Administration Centre, under the Statistics menu, within the Project Traffic Statistics interface, under the Yearly Project Traffic Statistics graph the labels of the years that appear for July and January are now correctly set to show labels a current financial year.
Previously these labels would set the incorrect years to show if the current year was in the second half of the financial year.

Functionality Affected: Project Traffic Statistics administration centre interface
Impact: Minor

 


TOT-4066 - Unable to upload an image to a category within the Categories Admin Centre interface

Within the Administration Centre, under the Inventory menu, within the Category Trees interface, upon right clicking on a category and clicking the View menu item, within the Images tab upon selecting an image to upload and clicking on the Add button, the image now correctly uploads and is added to the images list, if the image is a jpeg, gif, or png under the valid size.
Previously if an image was attempted to be uploaded against a category the image would fail to upload, occurring since the improvement TOT-4031 was released.

Functionality Affected: Category Trees administration centre interface
Impact: Normal

 


TOT-4068 - _B_StockLevel hook showing incorrect stock level when product stock quantity is over 1000 in Basket Listing content managed web page area

On a content managed webpage displaying a Basket Listing area, if the area is showing products that have been previously added to basket that currently contain stock quantities 1000 or greater, then the _B_StockLevel hook within the area's Basket Product Record format is now correctly determining the stock level, regardless of the amount of stock quantity a product has available.
Previously if the stock quantity had a value of 1,000 or more, only the numbers left of comma would be used to calculate the stock level.

Functionality Affected: Basket Listing content managed web page area
Impact: Normal