ShippingService sets the SystemName - please change to do that conditionally

Andrei,
It appears that the nopC core ShippingService sets the ShippingRateComputationMethodSystemName:

\Libraries\Nop.Services\Shipping\ShippingService.cs  
    
                // add this scrm's options to the result
                if (srcmShippingOptions != null)
                {
                    foreach (var so in srcmShippingOptions)
                    {
                        so.ShippingRateComputationMethodSystemName = srcm.PluginDescriptor.SystemName;


So, even if ShippingDirector wants to set it (based on calling carrier plugin - e.g. Shipping.UPS), it will be overwritten by the core.  Would you please consider making a core code change- e.g. add bold line:

                        if (String.IsNullOrEmpty(so.ShippingRateComputationMethodSystemName))
                            so.ShippingRateComputationMethodSystemName = srcm.PluginDescriptor.SystemName;


Otherwise, Tracking won't work with SD, because the core uses the system name on completed orders when Tracking info is requested.

Thanks

Hi Dennis,

Sure. Please see changeset e050cc371d1b. Thanks!

Thank you Andrei, this is something that will really help us.

Andrei

Well, I guess I never noticed, but it appears that still "Tracking won't work with SD".  It's because when using Shipping Director, it is supposed to be the only ACTIVE shipping provider (rate calc method).  That's because otherwise duplicate methods would appear to customer since SD can conditionally call other shipping rate plugins to get their methods.  However, when getting a tracker, the core code is checking to see if the rate calc method is active...

The offending ;) code is in (3.80) \Libraries\Nop.Services\Shipping\Tracking\ShipmentExtensions.cs

var shippingRateComputationMethod = shippingService.LoadShippingRateComputationMethodBySystemName(shipment.Order.ShippingRateComputationMethodSystemName);
if (shippingRateComputationMethod != null && shippingRateComputationMethod.PluginDescriptor.Installed &&
    shippingRateComputationMethod.IsShippingRateComputationMethodActive(shippingSettings))
    return shippingRateComputationMethod.ShipmentTracker;

I don't see any downside to allowing Tracking when a shipping provider is not active.  Even if not using SD, a store owner may have had a provider active in the past, and then decides to no longer use it;  they should still be able to track prior orders.

Thanks

New York wrote:
Hi,

I think this very-very rate case. But anyway I've just created a work item. Thanks!

Thanks for creating work item.  I agree it's rare, but I see no downside to allowing inactive shipping providers to still support tracking.  Also, I'm creating a plugin that will allow customers to enter their own shipping account # for use in B2B stores. In this case, the account "type" will still refer to a shipping provider to utilize the tracking, but the store owner would not necessarily want to offer all the methods to non-B2B customers.

Hi,

And done

Thanks!