Blog

Extra commands are required for PowerShell to use those commands

• Install-Module -Name Az.StackHCI
• Connect-AzAccount (then login to Azure via popup)

Then the rest as per documentation

• Install-Module -Name ExchangeOnlineManagement -allowprerelease
• Import-module ExchangeOnlineManagement
• Connect-ExchangeOnline -Organization
• New-ServicePrincipal -AppId <APPLICATION_ID> -ObjectId <OBJECT_ID>
• Get-ServicePrincipal | fl
• Add-MailboxPermission -Identity "john.smith@contoso.com" -User <SERVICE_PRINCIPAL_ID> -AccessRights FullAccess

One issue was the https://ps.outlook.com/.default scope did not work and caused Authentication failed. error
Now using the outlook scope for both SMTP and IMAP with the final code as per the documentation

var confidentialClientApplication = ConfidentialClientApplicationBuilder.Create(appId)

            .WithAuthority($"https://login.microsoftonline.com/{tenantId}/v2.0")

            .WithClientSecret(clientSecret)

            .Build();

var scopes = new string[] {

    "https://outlook.office365.com/.default"

};

var authToken = await confidentialClientApplication.AcquireTokenForClient(scopes).ExecuteAsync();

var oauth2 = new SaslMechanismOAuth2(accountEmailAddress, authToken.AccessToken);

client.Connect("outlook.office365.com");

client.Authenticate(oauth2);

The other PowerShell command needed to enable SMTP was

• Set-TransportConfig -SmtpClientAuthenticationDisabled $true
• and
• Get-TransportConfig to check the change

nopCommerce WEB API covers most of the functionality, including multistore and multivendor.

Please find the frontend methods at https://app.swaggerhub.com/apis/nopCommerceAPI/nop-commerce_web_api_frontend 

and the backend methods at https://app.swaggerhub.com/apis/nopCommerceAPI/nop-commerce_web_api_backend

General rules for using settings in nopCommerce are as follows:

1. If you have a single store (so you don't use a multistore feature), you can always inject settings by DI.
2. If you use a multistore feature, then getting settings depends on the place of use:

a) you can still inject settings by DI in any code that is called by a user request (controller actions, factory methods, service methods, some code on views, etc.), they will be injected for the current store (for which the request is executed);
b) when configuring a plugin or settings in the admin area, you should load the settings for the selected store ID to override them for this store;
c) in any code that is called by third-party and not by user actions (for example, schedule tasks, webhook notifications from third-party services, etc.), getting settings should be considered case-by-case:

i) You can inject settings, but get ready that they will be injected for the store for which the webhook was registered, or from which the whole application was started (usually the first one from the list) in the case of schedule tasks.
ii) You can somehow get the store ID (e.g. from a query string in case of webhooks) and load the settings according to this ID.
iii) You can load all the settings, and then use them separately for each store (suitable for tasks with synchronization).

So in our Brevo plugin we use few approaches at the same time:
2-a in the view component, since this code is called by the user;
2-b in the plugin configuration;
2-c-iii in the schedule task since this is a synchronization task.

If you are developing your own plugin or customizing the solution, follow the rules above.

Depending on the system, configuration and access there are different ways people like to upgrade.
The way I do it is to create a new installation in a new directory for v4.7.
Then I run the Install to create a a test database.
This allows you to check the install is all working before making any changes to the configuration.
Once you have checked everything is working in this test mode, take a copy of the newly create .json files in case you need to go back.
Then you can then you edit the .json files above to make any changes to the configuration and point the system to your existing database to do the upgrade.
You can then test everything is working with the production configuration
Then I install the plugins which should do their own upgrade of the database as required.

Also refer to Upgrading nopCommerce

Installing nopCommerce and having issues ?

Here is a document which shows the basic Setup for IIS
You can download here https://www.selectsystems.com.au/Content/Server%20install%20IIS%20and%20SQL%20Server.pdf

Or check for errors on a New Installation Here
https://www.selectsystems.com.au/checking-for-errors-on-a-new-installation-of-nopcommerce

I searched for the answer for a while before I found this works

                $.ajax({
                    cache: false,
                    type: "POST",
                    url: "@Html.Raw(Url.Action("DailyReport"))?date=" + $('#EventStartDateTimeUtc').val() +
                        "&groupProductId=" + ddlGroupProductId + "&associatedProductId=" + ddlAssociatedProducts,
                    xhrFields: { responseType: "blob" },
                    success: function (data) {
                        var blob = new Blob([data]);
                        var link = document.createElement('a');
                        link.href = window.URL.createObjectURL(blob);
                        link.download = "Daily_Report_" + $('#EventStartDateTimeUtc').val() + ".pdf";
                        link.click();
                        var file = new File([blob], filename, { type: 'application/force-download' });
                        window.open(URL.createObjectURL(file));
                    },
                    error: function (error) {
                        alert("Error: " + error);
                    }
                });

For Paypal Commerce Plugin I have setup Sandbox and can do transactions no problem.

But where do you see the transactions in Paypal when using the Sandbox like you would in your Buinsess Dashboard ?
What is the link ?

One option is lookign at notifications See https://developer.paypal.com/developer/notifications

Notifications only show the emails sent to the buyer and don't contain full transaction details, though they can be used as a confirmation of successful payments without visiting a sandbox account.

The other option is using Sandbox.

The link is https://www.sandbox.paypal.com, this sandbox test site mirrors the features on the PayPal production servers.

You can create an individual test account, or use the ones automatically created for a developer account (https://developer.paypal.com/dashboard/accounts).
You have to set up a sandbox in the plugin configuration and pay with the above test account during the checkout. Transactions will be shown on the sandbox test site (https://www.sandbox.paypal.com/activities/), just like for a Business account.