This is helpful to have when debugging feature specs.

Co-authored-by: benjamin wil <[email protected]>

Co-authored-by: benjamin wil <[email protected]>

We need to evaluate when an order should be reported to TaxJar in
multiple places. Currently this logic all lives in the reporting
subscriber module and is unfortunately duplicated in both handlers. In a
future commit we want to introduce a Sync or Retry action for failed
transaction syncs, which will also require that we perform these checks.
This change attempts to extract some of that logic in a `Reportable`
concern and provide a `with_reportable` API which takes a block to
evaluate when all conditions are met.

In the next commit we'll attempt to further extract the pre-requisites
for replacing a transaction on TaxJar into this and possibly other
checks specific to that flow.

Co-authored-by: benjamin wil <[email protected]>

These conditions were already implicitly true for the
`report_transaction` event action, so we can safely move them into the
shared module which now provides all the checks that need to be
satisfied by an order.

The tests needed a small change to better reflect the state of the
shipment and the order, when the `shipment_shipped` event is fired (i.e.
after the transition of a shipment to the `shipped` state).

Co-authored-by: Benjamin Willems <[email protected]>

This is the last step of the refactoring work to extract the logic
around `Reportable` orders. This change combines the conditions for
whether a transaction on TaxJar is replaceable into a single public API
we can expose on the `Reportable` module. This will allow us to
condition logic on this check by simply including this module wherever
we need to re-use this logic.

This will allow us to completely remove any conditions from the
reporting subscriber and creates a clean API around executing any code
that needs to check if an order can be reported/replaced.

Co-authored-by: benjamin wil <[email protected]>

For some reason our feature spec will receive a shipment record which
isn't yet shipped, and that is likely because in our feature specs we
run the jobs for the reporting subscriber async, unlike in our unit
tests where we just assert that a job has been queued.

Firing the event is done synchronously, so this change will ensure that
the service layer that handles generating Carton objects when inventory units
# are actually shipped and also updates the order and shipment states
has been performed (in `Spree::OrderShipping`), before the event is
consumed by our subscriber.

We tried updating the unit specs to expose this, but we were not successful.

Co-authored-by: benjamin wil <[email protected]>

We are about to make some changes to this file so let's re format these
lines for readability.

Co-authored-by: benjamin wil <[email protected]>

Our test helper to stub calls to the event system does not work on
Solidus 3.2 and newer where Omnes is the default bus implementation.
This change updates the stubbing to correctly stub out the new system if
that is the one in use.

Co-authored-by: benjamin wil <[email protected]>

The method we were using previously, was deprecated in Ruby 2.2 and is
removed in 3.x. We should be using the new API here as we now support
Ruby 3.x on this extension.

Co-authored-by: benjamin wil <[email protected]>

In order to support the new Omnes event system on Solidus 4.x, we are
duplicating our existing subscriber class and renaming it to
`LegacyReportingSubscriber` and updating the implementation of what will
be the new `ReportingSubscriber` to use the new Omnes API.

One change we realized is necessary is to move both subscriber files
to the `lib` folder so they are no longer automatically loaded by the host app.
This means we need to manually require and "activate" the correct
subscriber based on the Solidus version. For this we are introducing a
`solidus_taxjar_legacy_events.rb` initializer for versions of Solidus
where Omnes has not been introduced yet - prior to 3.2.

Co-authored-by: Cameron Day <[email protected]>
Co-authored-by: benjamin wil <[email protected]>

Solidus 2.11 has been deprecated for a very long time, so we should drop
this before releasing version 1.0 of this extension.

Co-authored-by: benjamin wil <[email protected]>

Now that Solidus 4.1 is released and Solidus 4.0 was added to the CI
task [^1] for solidus-older we need to bump the version of Ruby used to
3.0.

[^1] solidusio/circleci-orbs-extensions#87

There is something happening when setting up the order for this refund
spec which is causing it to sometimes not get taxes on CI. That results
in a mismatch in the refund amount causing the test to fail.

Prior to this commit, we ran into issues retrieving the latest order
transaction as many contained the same transaction date. To fix, we add
secondary sorting ordered by `created_at`.

Co-authored-by: Alistair Norman <[email protected]>

Co-authored-by: Benjamin Willems <[email protected]>

This doesn't belong here!

Co-authored-by: Alistair Norman <[email protected]>

Prior to this commit, all line items would be reported to TaxJar,
including returned line items. To fix this, we check that a line item
has at least one inventory unit with a state other than 'returned'.

Co-authored-by: Alistair Norman <[email protected]>

Prior to this change, each request to TaxJar sent all line items. We
should exclude line items that have been returned or cancelled so the
total of the line items still adds up to the order's payment total.

Co-authored-by: Noah Silvera <[email protected]>

Prior to this change, the query for inventory units that are not
cancelled or returned was repeated three times so we move the query into
a private method.

Co-authored-by: Alistair Norman <[email protected]>

We want to show the user a reference to the TaxJar refund transaction
that is created when updating an order in TaxJar.

Prior to this commit, we never created a transaction sync log when
replacing an order on TaxJar. Now that a previous commit returns the
refund transaction and order transaction from the reporting class, we can
create the transaction sync log.

Prior to this commit, any errors raised by this job would remain
un-rescued and most likely in someone's error reporting software.
Instead, it's more helpful to create a transaction sync log and show the
error in the Solidus admin.

We should show this information to the user so the sync records in
Solidus match up with the sync records in TaxJar.

VCR is configured to block network requests during test runs. But if
Selenium Manager requires Chrome binaries for feature tests, it makes
requests we need it toamke. For now, let's just ignore the known Google
hosts.

In a subsequent commit we want to use this outside of the reporting
subscriber tests.

If the last transaction sync log was a failure, add a "Retry" button to
the admin interface so an admin user can resolve the issue and then
get the order synced with TaxJar.

Co-authored-by: Chris Todorov <[email protected]>
Co-authored-by: Nick Van Doorn <[email protected]>
Co-authored-by: Noah Silvera <[email protected]>
Co-authored-by: benjamin wil <[email protected]>

This change updates our extension to use the new method provided by
`solidus_dev_support` instead of manually requiring the files. This is
in line with how `FactoryBot` recommends factories are registered and
resolves an issue with our custom override for the `Spree::Address`
factory.

Currently the upstream version of `solidus_dev_support` does not handle
our use case of having a two folder deep namespace, so this change needs
to wait for that to be fixed. We have opened a PR upstream for that to
be changed - solidusio/solidus_dev_support#207

Co-authored-by: Nick Van Doorn <[email protected]>

With the latest releases of Selenium, the `webdrivers` gem is no longer
compatible. Upstream, `solidus_dev_support` requires
`selenium-webdrivers` explicitly, meaning our Webdrivers-specific
configuration will cease to work.

This commit prepares us for the future.

Co-authored-by: Adam Mueller <[email protected]>

A user brought it to our attention that they experienced an unrelated
error stopping their backfilling jobs early.

We can improve the experience of using our report transaction job by
rescuing from all standard errors that could occur.

Closes SuperGoodSoft#248.

Co-authored-by: Adam Mueller <[email protected]>

When a transaction which failed to be reported to TaxJar is recalculated, we
need to correctly attempt to report it, instead of trying to replace it
(which won't work because replacing requires the transaction to be
previously reported). This change adds a failing feature spec to
demonstrate this behaviour.

Co-authored-by: Kendra Riga <[email protected]>

In manual testing, we ran into some scenarios where we want an order to
be reported but it can end up in a shipped and unpaid state.

e.g. If you have an address that caused a failed sync to taxjar due to
validation errors, and then
correct the address, the tax on the order may change, resulting
 in an order that has never been reported to taxjar, but is unpaid and
 shipped.

 Co-authored-by: Chris Todorov <[email protected]>

We need to be able to run all checks in both the `with_reportable` and
`with_replaceable` methods because we are going to combine the event
actions into a single one. This commit prepares that change.

Co-authored-by: Adam Mueller <[email protected]>
Co-authored-by: Chris Todorov <[email protected]>

Because we now need a way to recover from failures to report
transactions after updates to them happen, we have decided to combine
the event handlers into one in order to avoid having to manage multiple
flows for the same action. This will also allow us to remove the need
for the custom `shipment_shipped` event this extension needs to
maintain.

Co-authored-by: Adam Mueller <[email protected]>
Co-authored-by: Chris Todorov <[email protected]>

This updates the changelog using the format suggested by
https://keepachangelog.com and breaks up the upcoming changes into a few
separate categories. This should hopefully help users of the extension
easily identify the changes they need to be aware of when upgrading to a
new release, and also help us identify clearly what changes are
unreleased yet.

In a test environment, we discovered that sometimes these jobs would be
run before an order's new totals had been persisted by the
`Spree::OrderUpdater`. This is an effective workaround, but it is just
a workaround.

This extension is not ready for the new admin, so let's not use the new
admin when generating sandbox apps.

Co-authored-by: Alistair Norman <[email protected]>
Co-authored-by: benjamin wil <[email protected]>

This causes issues with Zeitwerk on the Solidus `main` branch, because
it lives in the `app/overrides` folder which is loaded by default as per
Rails convention. Switching the file to `.deface` ensures that Zeitwerk
does not try to load it.

Co-authored-by: Alistair Norman <[email protected]>

This fixes the `bin/sandbox` when running with SOLIDUS_BRANCH=`main`.
Previous to these changes, the building of the sandbox app would fail
with an error finding `/config/routes.rb` during the running of the
`solidus:install` task as part of the script. It's not immediately clear
which of these changes fixed the issue, but this is what
`solidus_dev_support` generates now for new extensions, so let's run
with it.

Co-authored-by: Alistair Norman <[email protected]>

We should really switch to the new frontend, but until we can figure out
why generating the sandbox app with the new frontend fails let's add
back the old one. This is also consistent with the dummy app so may help
with debugging.

Co-authored-by: benjamin wil <[email protected]>

Our checkout and post-checkout feature specs share some `before` setup,
and I wanted to extract it into a shared context to make the
spec-specific set up more clear.

While trying to make this spec pass and investigate an issue with
tax calculations we found during manual testing, I wanted to refactor
this spec so that:

1. It would be more clear which line items we were reimbursing for.
2. It would cover the case where a line item would be removed as well as
   the case where a line item would not be removed but its quantity
   would be changed

This test is pending as the reimbursement amounts populated are
currently wrong ($10.00 instead of $10.89):

    Failures:

      1) Refunding an order adds tax calculated by TaxJar to the order total
         Failure/Error: expect(find(".reimbursement-refund-amount")).to have_content("$10.89")
           expected to find text "$10.89" in "$10.00"
         # ./spec/features/spree/admin/refund_spec.rb:72:in `block (2 levels) in <top (required)>'

I removed the VCR cassette because we will need to re-record it as part
of making the test pass.

Before this commit, we were excluding returned and cancelled inventory
units in two circumstances:

  1. For tax calculations
  2. For TaxJar's transaction reporting dashboard

But this was incorrect. To explain this, we must look at orders with
customer returns on them.

We want to exclude returned and cancelled inventory units for reporting
purposes (2), but we must continue calculating tax for any returned or
cancelled units (1). The reason we must continue calculating tax is so
that we have a record of how much tax must be reimbursed to customers
when we generate new `Spree::Reimbursement`s from the admin.

A bit more context:

Before this change, whenever `order.recalculate` is called, we would
recalculate taxes, excluding returned or cancelled items. This in a
returned line item's `#additional_tax_total` being fully zeroed out. A
partially returned line item's tax total would be in an even
harder-to-understand state.

Co-authored-by: Adam Mueller <[email protected]>
Co-authored-by: Noah Silvera <[email protected]>

This spec is intermittently failing on CI, and it's incredibly hard to
reproduce why locally.

We need to keep moving so pending this on CI for now

Co-authored-by: benjamin wil <[email protected]>

Title-case everywhere.

This resolves the remaining checklist items in issue SuperGoodSoft#207.

Closes SuperGoodSoft#207.

Now that we're officially in a stable release, let's show it off. It's
also helpful for users of the extension to see the latest published
version.

# Conflicts:
#	app/overrides/spree/admin/shared/_configuration_menu.rb
#	app/subscribers/super_good/solidus_taxjar/spree/reporting_subscriber.rb
#	lib/generators/super_good/solidus_taxjar/install/install_generator.rb
#	lib/super_good/engine.rb

…eria