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,

Following issues would be great additions:

• Returns are not integrated with EasyPost out of the box #83 fixing Returns would be a great addition;
• An inverse shipping method flag allowing pickups as well

@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!