Closed (fixed)
Project:
Commerce Migrate
Version:
8.x-2.x-dev
Component:
Ubercart D6
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
9 Jul 2017 at 06:28 UTC
Updated:
24 Aug 2017 at 15:49 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
quietone commentedComment #3
swickham commentedThis patch contains the migration for taxes and its test.
One point I'm still unsure about is since 2.x taxes require a territory while UC6 taxes did not was how to handle that value. I realize UC6 taxes could have territories defined by rules but that seems like a whole ball of wax we should avoid. Currently, this patch defaults the territory value to be what the UC6 store's location was.
Comment #4
swickham commentedComment #5
quietone commentedRetesting now that HEAD is fixed.
Comment #6
heddnI think we can use sub-fields or even sub_process here instead of the work in the source plugin.
I don't see config_rate in the fields array.
This makes the source migration non-idempotent. Meaning, I cannot re-run the migration and expect the same results. Can we leave it to the destination entity to auto-generate the UUID for us?
Comment #7
swickham commentedNew patch re-rolled to work with the new module structure with submodules and addresses heddn's notes.
Comment #8
heddnAnd, it needs another re-roll again.
I'd like to see a test that verifies we are assigning the UUID. I bet that could be easily added to assertTaxType() pretty easily.
Nit: missing new line.
Comment #9
swickham commentedRerolled and moved the rate testing which originally existed in the TaxTest.php file to CommerceMigrateTestTrait.php as requested.
Comment #10
swickham commentedComment #11
heddnI'm not seeing a UUID assignment test. Back to NW for that last piece.
I did some more research also why we need to set the UUID. It only seems to apply to custom tax rates. Non-custom don't use a UUID. So we need to check for type of tax in the subscriber. Also, it might make sense to move the assignment of the UUID into an event subscriber in commerce core, rather than just in migrate. If anyone wants to interact with a custom tax rate using the entity api, they are going to run into the same situation.
Comment #12
mglamanWe don't need a UUID. This is good enough.
EDIT: We can use same pattern for the rate ID.
Comment #13
heddnOK, to summarize a chat I had with @bojanz and mglamman in Slack:
The rate id doesn't need to be a UUID. It can be any value that is unique within that tax type. The id in D6 UC is unique. So, let's ditch the event subscriber and just map the id as the rate's id too.
Or better yet, just map the @id to configuration/rates/0/id.
Like this:
Comment #14
swickham commentedUpdated patch so the rate ID is simply the same as the TaxtType's ID.
Comment #15
mglaman\o/ yay. Looks good to me. Thanks for updated fix.
Comment #16
willeaton commentedThe following needs removing from modules/ubercart/migration_templates/d6_ubercart_tax.yml
migration_group: ubercartAs per https://www.drupal.org/node/2898755
Comment #17
quietone commentedLooks good. Just a bunch of changes to catch up with some naming changes happening in parallel. Also, when I got to the end of that patch I saw the test was for a tax type. So, the migration and source plugin names should be changed to include 'type'.
Please start with Ubercart, 'Ubercart 6 taxes'
Just 'Ubercart'
Remove migration_group
Remove the expected_ prefix. s/expected_//
s/d6_ubercart_tax/d6_ubercart_tax_type/
s/d6_ubercart_tax/d6_ubercart_tax_type/
s/d6_ubercart_tax/d6_ubercart_tax_type/
s/tax/tax type/
s/TaxTest/TaxTypeTest/
Comment #18
swickham commentedThanks for the reviews everyone, here's the patch addressing all notes.
Comment #19
swickham commentedComment #20
quietone commentedThanks, swickham. Just 2 nits.
Should be tax types. Or, since there is a label field, the comment is superfluous, delete this comment.
Should be tax types. Suggest just 'Ubercart 6 tax types'.
Comment #21
swickham commentedIgnore this, fixed patch coming up shortly.
Comment #22
swickham commentedFixed patch.
Comment #23
quietone commented@swickham, thanks. All points addresses.
Comment #25
heddn