Only use EasyPost when the item has a ShippingCategory that uses EasyPost

[brchristian]

This is an attempt to address some of the functionality desired by #47.

Here is one way that a store (like ours, which offers subscription products and digital products that don’t ship normally and have very specific custom shipping rates) can use SolidusEasypost along more custom functionality.

It adds a use_easypost boolean to each Shipping Category (true by default). Then there is a check to see if a package belongs to any shipping categories that use EasyPost. If so, it overrides the estimator shipping rates as normal for solidus_easypost. If not, it falls back to the default Solidus behavior for those shipping categories.

Something like this would be terrific for a store like ours, and would be the start of the work described in #47.

@vassalloandrea what do you think?

[brchristian]

Note that we’ll have to tinker with the specs at

solidus_easypost/spec/models/spree/stock/estimator_spec.rb

Lines 63 to 69 in 4dc95fd

	let(:package) do
	instance_double(Spree::Stock::Package, easypost_shipment: fake_shipment)
	end
	let(:fake_shipment) do
	double(EasyPost::Shipment, rates: [])
	end

...which are a bit brittle at the moment, but we can sort that out easily enough if this general approach looks good!

[vassalloandrea]

Hi @brchristian, thank you for your PR! We really appreciate your input 🔥
Your solution likes simple and correct but what do you think about merging the Easypost rates with the Solidus ones?
Merging them we can use the Easypost rates like USPS and permit the customer to get the package directly to the warehouse with pick up in the area option 😄
Example
app/prependers/models/spree/stock/estimator/override_shipping_rates.rb

shipping_rates = method(:shipping_rates)
      .super_method
      .call(package, frontend_only)
      .concat(
        super(package, frontend_only)
      )
    # Here we should choose the default shipping rate
    shipping_rates

Another problem occurs when the admin user tries to ship the rate since this extension will buy the rates from Easypost and with the changes above, we can ship the packages also with the Solidus ones.
To correct this bug we need something like this:

• Add a custom field to the shipping methods that defines if it is custom (created from the Solidus admin panel) or not custom (created by Easypost)
• When the package is marked as shipped, buy the Easypost rate only if the shipping method isn't custom
  Example:

module Spree::Shipment::AllowCustomShipping
  def buy_easypost_rate
    return if shipping_method.custom?
    super
  rescue EasyPost::Error => e
    raise e unless e.code == 'SHIPMENT.POSTAGE.EXISTS'
  end
end

What do you think about it?
BTW, I'm already writing a PR to solve this problem and it is almost ready. If you like this approach, I will undertake to merge it as soon as possible.

[brchristian]

@vassalloandrea merging the Easypost rates with the Solidus ones sounds like a great idea! Go for it and LMK if I can be helpful!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It might be closed if no further activity occurs. Thank you for your contributions.

[fthobe]

@kennyadsl this PR addresses some of the issues we have with current shipping implementation. A decision should be made to either throw easypost or decide to address a lack of working state. @vassalloandrea made some perfectly valid requests that should be made either a discussion or an issue but should not have stopped this PR.

Following issues are currently show stoppers:

• Issues addressed in this PR,
• to fix EasyPost no method api_key #108 & Everything returns SHIPMENT.INVALID_PARAMS #104 would address issues caused by the easypost API itself (fixed by PR Restore easypost functionality #112)

Following issues would be great additions:

• Returns are not integrated with EasyPost out of the box #83 fixing Returns would be a great addition (discussion moved to Restore and Extend EasyPost functionality #111 );
• An inverse shipping method flag allowing pickups as well (discussion moved to Restore and Extend EasyPost functionality #111 );

@brchristian your PR was a great contribution. Do you have this extension still running somewhere with the changes required by Easypost API updates? We would pick it up and complete it with the additions.

@ccarruitero Have you managed to align the extension with the api changes of easypost?

[brchristian]

Hi @fthobe I’m afraid I’m no longer developing on Solidus since 2022, but thank you for revisiting this PR and I am glad to hear that this approach is helpful! You are welcome to rebase this PR, amend it, or close it as you feel is best. Cheers!

[fthobe]

Hey @brchristian what made you leave?

[brchristian]

After 9 years in my role as Director of Technology at my company, I passed the torch to my successor and left for other adventures!

[fthobe]

@rahulsingh321 as bespoken please pick up this PR as bespoken in #111

[fthobe]

@tvdeyen @kennyadsl @jarednorman I need your help here:
we use easypost, but I am aware that that's not the only solution. There's anything from shipstation to self packaging. We should consider having something in core that the extensions can augment with their own value. I have limited experience in the whole extension space. Please provide some guidance.

The ideal outcome would be some kind of enum name shipping_label_creation_channel (or any better suited name) with default value "" that extensions can write into to extend for example with "easypost" or "shipstation" to allow multiple implementations at the same time.

Fire away if I am missing anything, but for me the basic column should go into core.

[tvdeyen]

@tvdeyen @kennyadsl @jarednorman I need your help here: we use easypost, but I am aware that that's not the only solution. There's anything from shipstation to self packaging. We should consider having something in core that the extensions can augment with their own value. I have limited experience in the whole extension space. Please provide some guidance.

The ideal outcome would be some kind of enum name shipping_label_creation_channel (or any better suited name) with default value "" that extensions can write into to extend for example with "easypost" or "shipstation" to allow multiple implementations at the same time.

Fire away if I am missing anything, but for me the basic column should go into core.

I could live with a field on the shipping method (provider, or gateway? <- same as payment methods). Not sure why the category is used here tbh. The category is more like the "what" is shipped (a book, a carton, a pallet) vs. the shipping method that describes "how this category of product" is shipped with a certain carrier. In my understanding this belongs to the shipping method (like with the carrier field we already have). But I can live with both if this easier to handle that way.

[jarednorman]

As @tvdeyen mentioned, I think this PR is going down the wrong path. EasyPost and shipping categories shouldn't be tied together. Let's pull this conversation to #47 and talk about what actual functionality needs to change in this extension.