News Digest - 29 November 2021

[OlegoO]

Highlights

• Assets were decoupling from the platform - In 3.94 release, the assets were decoupled from the platform to their own modules.
• Selecting properties for payload - WebHook module allows selecting fields that will send to the recipient.
• UI improvement - Improved scrollbars
• UI improvement - New modal dialogs
• New features in XAPI - XAPI was extended with Category Descriptions and Video,m Added Menu and CMS domains.

Assets were decoupling from the platform

To simplify the platform, in Virto Commerce 3.94 release, the assets were decoupled from the platform into their own modules.

Starting from this version, the Platform does not contain assets-related functionality anymore. It was decoupled into three modules separately out of the platform:

Module	Description
vc-module-assets (VirtoCommerce.Assets)	Common abstractions to implement assets-related functions.
vc-module-filesystem-assets (VirtoCommerce.FileSystemAssets)	File system assets module. Implements assets storage in the ordinal file system.
vc-module-azureblob-assets (VirtoCommerce.AzureBlobAssets)	Azure blob assets module. Implements assets storage in the Azure blob storage system.

Note: Please install these modules to your custom solution if you update the platform to 3.94 and later. All three modules are included in the “commerce” bundle and installed with every new platform installation.

If your custom module uses assets functionality from the Platform you need to make several changes to your module.

1. Add a dependency into the module.manifest to the latest available VirtoCommerce.Assets module;
2. Add nuget package reference in related projects to the latest available VirtoCommerce.AssetsModule.Core package;
3. Remove using of VirtoCommerce.Platform.Core.Assets namespace from your code and add VirtoCommerce.AssetsModule.Core.Assets instead;
4. If your module extends Admin UI, change assets related endpoint uris URIs: ‘api/platform/assets?XXXXXXX’ → '‘api/assets?XXXXXXX’;
5. If your module extends Admin UI and uses angular templates from the assets modules, change templates URIs similar way: ‘$(Platform)/Scripts/app/assets/blades/XXXXXXX’ → ‘Modules/$(VirtoCommerce.Assets)/Scripts/blades/XXXXXXX’

Selecting properties for payload

We improved UX of the webhook module. WebHook module allows selecting up to 10 fields that will send to the recipient. The module uses reflection to extract available properties, so all properties - default and custom are available.

And here is JSON document. ObjectType and ID are include automatically.

UI improvement - Improved Scrolls, Improved modal dialogs design

As part of continuously UI improvements, we improved scrollbars and modal dialogs design.

Improved scrollbars:

New modal dialogs:

Design in Figma: (Figma)

All dialogs in the platform are provided by dialogService (wwwroot\js\common\dialogs\confirmDialog.js). There were the four main kinds of dialogs (and dedicated methods) and one universal method, using with a custom template (showDialog):

showAcceptanceDialog and showNotificationDialog methods are using in platform modules and can not be deleted. But they are marked as obsolete and have to be replaced in appropriate modules.

The main SASS file with modals styling is _window-modals.sass . This file is still using by some kinds of a dialogs such as all the password manipulation dialogs ( wwwroot\js\app\security\dialogs ) or login windows ( wwwroot\js\app\security\login ) and all custom VC modules dialogs.

The new dialogs are using BEM approach and styling by the _dialogs.sass . After refactoring the password, login and modules dialogs only the _dialogs.sass file should remain.

There are four main new dialogs implemented (located in wwwroot\js\common\dialogs\templates\):

Dialog name	Filename	Usage scenarios
Confirm Dialog	confirmDialog.tpl.html	1. On a blade close, if there are any unsaved changes (for example, when a user changes the product name and close a parent blade without saving). 2. On delete any asset folder or file in the Assets module. 3. On delete any dynamic property in the Dynamic properties module. 4. On a user delete the Security module. 5. On an account API key delete in the Security module. 6. On an OAuth delete in the Security module. 7. On a Role delete in the Security module.
Warning Dialog	warningDialog.tpl.html	1. After clicking on the “Restart” button after a module installation in the Modules module. 2. After clicking on the “Restart” button on a toolbar in the Settings module.
Success Dialog	successDialog.tpl.html	1. After cache reset in the Settings module
Error Dialog	errorDialog.tpl.html	1. When trying login on behalf in Secutiry → Users → User settings 2. When clicking the “see details” link in a blade header after an error appears.

Confirm dialog

The Confirm dialog is a base dialog using for confirmation of any user actions, if there are any unsaved changes or when user is trying to delete something. The dialog implements three actions:

Button	Action
Yes	Close the dialog instance and run a callback with a true result.
No	Close the dialog instance and and run a callback with a false result.
Close (“X”)	Close the dialog instance without any other actions.

Warning dialog

The Warning dialog can be used in the same scenarios as the Confirm dialog, but generally warning dialog is using to take a user’s attention in cases when data can be lost and other meaningfull effects can be achieved. This dialog can be used to inform a user about starting any irreversible process. The dialog implements three actions:

Button	Action
Yes	Close the dialog instance and run a callback with a true result.
No	Close the dialog instance and and run a callback with a false result.
Close (“X”)	Close the dialog instance without any other actions.

Success Dialog

The Success dialog is using when we need to inform a user about any success operation or event. There are only two actions and they have logically equivalent results - close the dialog instance. But you can use callback with true result clicking by OK. The callback shouldn’t run any user-affecting processes, but it can run an exit process from the current context (if there are no any possible user actions and useful data), log any data or process result, and so on.

Button	Action
OK	Close the dialog instance and run a callback with a true result.
Close (“X”)	Close the dialog instance without any other actions.

Error dialog

The Error dialog is using when we need to inform a user about any errors or failed processes. There are only two actions and they have logically equivalent results - close the dialog instance. But you can use callback with true result clicking by OK. The callback shouldn’t run any user-affecting processes, but it can run an exit process from the current context (if there are no any possible user actions and useful data), log any data or process result, and so on.

Button	Action
OK	Close the dialog instance and run a callback with a true result.
Close (“X”)	Close the dialog instance without any other actions.

Custom dialogs

This dialog is a kind of a confirmation dialog, displaying when a user tries to install, update or uninstall any module. The dialog template file is moduleAction-dialog.tpl.html placed in wwwroot\js\app\modularity\dialogs\ directory. This dialog is styled by the same _dialogs.sass file as the other shared dialogs. The dialog implements three actions:

Button	Action
Confirm	Close the dialog instance and run a callback with a true result.
Cancel	Close the dialog instance and and run a callback with a false result.
Close (“X”)	Close the dialog instance without any other actions.

New features in XAPI

XAPI was extended with Categories’ Descriptions and Video. Added Menu and CMS domains. Find more details in Experience Documentation.