Spun off from #2847862: Views support for adjustments since this doesn't require schema changes.
See https://github.com/drupalcommerce/commerce/pull/622/files for the initial code.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | adjustment-types-setting.png | 20.81 KB | jsacksick |
| #12 | SCR-20220909-kcm.png | 84.11 KB | introfini |
| #12 | SCR-20220909-kbl.png | 125.87 KB | introfini |
Issue fork commerce-3011966
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
bojanz commentedComment #4
czigor commentedSome useful snippets for this issue:
The current adjustment views field is broken since there's no field formatter for it to use.
The downside of implementing this as a field formatter (instead of a views handler) is that when displaying order adjustments we also want to see order_item level adjustments (i.e. use
collectAdjustments()instead ofgetAdjustments()). It's quite unusual for a field formatter to display data from other fields.On the the pro side (of implementing this as a field formatter) the current views field would be fixed. We could add a field formatter setting "Also include order-item adjustments".
Comment #5
mglamanWe have
EntityAdjustableInterface, which gives usgetAdjustments. In order to expose adjustments as a formatter, we would need to limit based on the implementation of this interface.OrderInterfacegives us thecollectAdjustmentsmethod.So, it sounds like we almost need two formatters. We need the regular adjustment field formatter that calculates the results out of
getAdjustmentsand a second one that considers and order's collected adjustments viacollectAdjustments.It feels improper to have the formatter check if the entity's interface implements
EntityAdjustableInterfaceOROrderInterfaceand deciding what to display (or configured to display).Comment #6
introfini commentedJust as a quick fix for a project I'm working on, I did a very rudimentary views field plugin for getting the total order adjustments per type. (no filter). If anyone needs it as a quick fix also, just let me know.
Comment #7
jeff veit commentedYes @introfini, I'm interested in that. I was about to do exactly that too.
Comment #8
introfini commented@Jeff Veit here it is: https://www.dropbox.com/s/pp3mc6ftpj175ag/bloom_custom.zip?dl=0
Has I said it's very rough, but you get the idea.
Comment #9
jeff veit commentedThanks very much. I started on mine last night, and this will definitely help @introfini.
Comment #10
bradhawkins commented@introfini or @Jeff Veit do you still have a copy of that field plugin? The dropbox link seems to be broken.
Comment #11
markjsjordan commentedAlso wondering about that field plugin link @introfini / @Jeff Veit
Comment #12
introfini commentedI apologize for the delayed response.
As I've previously stated, this can be greatly improved; it was only done as a temporary solution to my issue.
Add this to your custom module:
Add a views field plugin at mymodule/src/Plugin/views/field/OrderAdjustments.php
Clear the cache and add the field to views:
Select the adjustment you want to include in the total:
Comment #13
tomtech commentedComment #15
tomtech commentedMR created that implements two field formatters for adjustments.
One is separator based. The other displays as a table.
Configuration options include specifying the adjustment type(s) to include, whether to display the label(s) of the adjustments, and currency options.
We can consider the collectAdjustments as a followup enhancement.
Comment #16
jsacksick commentedThank you Tom for addressing this, retitling the issue.
Tested this manually, works great! Only one minor comment regarding the Adjustment types setting. Just wondering whether we should use the label simply? Or if we stick with the plural label, perhaps we should uppercase the first character using ucfirst?
I think everywhere else (e.g: when adding an adjustment from the order edit form) we simply use the label (which is singular).
Comment #18
jsacksick commentedOk, went with the label for consistency. We might need a followup to call
collectAdjustments()as it looks kinda odd to only display order level adjustments (which normally only contains shipping, shipping taxes and eventually shipping promotions). Other than that, all other adjustments are added to order items.But I'm fine with doing this as a followup, since this is already a big improvement as we don't have formatters for anything atm :).