Due to this line near the top of commerce_tax.rules.inc:

function commerce_tax_rules_action_info() {
  $actions = array();

  if (count(commerce_tax_rates()) > 0) {

So... What's happening is that the actions in this file are sometimes not being created. Here is the scenario:

a) We live in a state (WA) that requires you to calculate tax rates based on where you are delivering things, and there are around 360 possible rates/jurisdictions, and they can change quarterly, so a rule-for-rate approach simply is not practical to keep up.

b) So I created a module with a hook_commerce_tax_rate_info() in it. So far, so good, but this requires to have a rule set up to calculate whether the tax is applicable (i.e., delivery address is in WA).

c) But this rule uses the actions set up by the Commerce Tax module. So at the time when the rule is attempting to be set up (which I did during hook_enable() for various reasons involving a Rules issue), Tax doesn't think there are any tax rates (none has been defined in the UI), and Tax doesn't therefore set up the actions, so the Rule I'm trying to define in my hook_enable() can't be created because Rules complains that the action doesn't exist.

My feeling is that if the Commerce Tax module is enabled, it should create those rules actions (you can disable Tax if you don't want to calculate taxes). So that if(count()) line should be removed.

#1 no-tax-rates.png51.31 KBrszrama


rszrama’s picture

51.31 KB

I'm torn. I think I understand the issue, and it seems like an unresolvable race condition. Your hook_enable() could rebuild the default rules manually instead of waiting for it to happen on the cache clear, but there's no way for us to clear it from the Tax module through hook_modules_enabled(), because that gets called after hook_enable().

I could simply remove the if statement around this and the tax type action, but then you end up with unusable actions in the Rules UI. Worse, there's no good way for us to indicate in the UI that the reason the action can't be used is because no tax rates / types have been defined. The user simply submits the form and sees this:

Because Rules is confusing enough as is to new users, if I have to choose between a more complex Rules experience and a slightly more difficult developer experience, I'd likely privilege the UX. That said, let's make sure my idea even works. At the top of your hook_enable(), add:


Let's see what happens after that.

Of course, if I can satisfy both the UX and DX in one fell swoop, I'd prefer that even more. ; )

jhodgdon’s picture

Good point. I'll see if that addition to my hook_enable() fixes the problem.

jhodgdon’s picture

The above two lines added to my hook_enable do not work. I still get:

RulesIntegrityException: Unknown action <em class="placeholder">commerce_tax_rate_apply</em>. in RulesAbstractPlugin->integrityCheck() (line 1456 of (mysite)/rules/includes/rules.core.inc).

Any other ideas?

As another note, I also tried putting my default rules into commerce_tax_wa.rules.inc, but this resulted in:
#1309144: PDO Exception SQLSTATE[HY000]: General error: 1364 Field 'plugin' doesn't have a default value
on module enable and at least sometimes also on cache clear, which is why I had put them into hook_enable().

rszrama’s picture

No sweat; it was a bit of a guess, sad to see it didn't work. I'll see what we can do about the UX problem then and just make the actions always available. Open to ideas.

jhodgdon’s picture

One thought: Change the user-facing label of that action to "Apply an existing tax rate to a line item", which would be at least the start of a clue that they have to have a tax rate defined before they can use the action.

Maybe the "commerce_tax_calculate_by_type" action could be changed to "Apply all taxes of an existing tax type to a line item" too? Because I have also seen problems with that one not being defined (chicken and egg).

Which is to say... I think Commerce Tax sets up the sales and VAT tax types automatically, but I am not sure when that happens or under what conditions. If it waits for tax rates to be defined, then this could also be a chicken-and-egg problem. It seems to me that when you enable the Tax module, it should go ahead and create the VAT and Sales Tax types, as well as the actions, in preparation for modules that might need them (any module doing something complicated will never hit the Tax module's UI).