For DrupalCommerce we have this open discussion about adding a weight component to the tax rates to apply to a given product / order. Tax rates are rule components associated to "tax type" rules and one of the use cases is to have more than one tax rate applied to a single product or order.
Does make sense to add a weight in the components to set the execution order and display or should we add it our own way?

Thanks!

Comments

pcambra’s picture

Component: Rules Core » Rules Engine
fago’s picture

Generically I don't it makes sense to have weights for components, as in Rules it doesn't have any meaning. However, there is already a 'weight' property which is saved for components - as it works just the same way as for reaction rules. It's just not shown in the UI, as there is no use of it.

That said, you could make use of the weight field for that. You could also do a single "rule set" component, which may contain multiple rules and has the weighting / drag&drop functionality for rules built in.

mitchell’s picture

Category: support » feature
Status: Active » Postponed (maintainer needs more info)
Anonymous’s picture

Title: Control component order with a _ rule set & weight field » Weight for rule components
Status: Active » Postponed (maintainer needs more info)

Generically I don't it makes sense to have weights for components, as in Rules it doesn't have any meaning.

I'd see advantage of this feature for the website documentation. It would allow convenient grouping of components and make complex set-ups easier to read. But this is not intention of the OP.

mitchell’s picture

Title: Weight for rule components » Control component order with a _ rule set & weight field
Status: Postponed (maintainer needs more info) » Active

Thank you for clarifying, Shnapoo. I still only understand this up to a point, so I can't figure out without an example if that example's configuration would be a 'clonable' starting point for others configurations of this nature. If so, that could be a nice inclusion in the project. If not, then a documentation page would work.

The "_" in the title is for naming this rule set.

Anonymous’s picture

Title: Weight for rule components » Control component order with a _ rule set & weight field

@mitchell: I didn't mean to clarify the OP, but wanted to hint at another use case for weighted components. To be honest, I'm absolutely confused by the underscore and new title. :)

To me it seems this issue was already handled by fago in #2 sufficiently. Anything else seems to be in the area of DrupalCommerce and should be elaborated there (see #1095576: Allow control of display order of taxes in muti tax setup) and then perhaps come back again.

mitchell’s picture

Title: Control component order with a _ rule set & weight field » Control component execution order with a separate controller rule set & weight field
Status: Postponed (maintainer needs more info) » Active

>> I'd see advantage of this feature for the website documentation.
> ...wanted to hint at another use case for weighted components
Oh. I thought that first comment meant it was a docs issue, which I was building on. Ok, it was a hint for another potential use case. IMHO, we need to reconsider this type of approach. There are so many complaints about the module being so powerful without any obvious instructions how to accomplish common goals.

> To me it seems this issue was already handled by fago in #2 sufficiently.
Like I said, we're way too reliant on things just existing somewhere in the issue queue. It leads to duplicate support requests and generally poor UX. How are people to know about it if they don't think of it themselves over again, and then also find that one comment.

We have to start putting this info either in the docs or making reusable feature. If I'm completely misinterpreting those two possibilities being perfectly suited for the situation, then can you please clarify why we shouldn't make this knowledge more available? Otherwise... you know what I'm going to suggest. TIA.

tr’s picture

Component: Rules Engine » Rules Core
Issue summary: View changes
Status: Active » Closed (won't fix)

@fago's comment in #2 from 8 years ago is still valid, and I agree with it. I don't find it useful to keep this issue open just as a reminder to improve the documentation. Anyone can do that at anytime, and since no one has done it, I prefer to close the issue to reduce the clutter in the issue queue.