Are you using Courier the product? Or Umbraco cloud?

Hi Matt, we are using Courier the product.

I have an immediate issue of getting 4 (I think) products that have been set up on Staging, up onto live. I am going to look at manually editing the JSON in this situation.

Assuming I am allowed the time, I will suggest that I create a data resolver. Your help will almost certainly be needed and I'd be happy to contribute it back to the community.

Hi Gordon,

I'd start by creating a standalone project TeaCommerce.Umbraco.Courier and then add the same UmbracoCms.Core 7.1.8 and Courier.Core 3.1.7 nuget dependencies as used in the Umbraco repository.

From their I'd create a TeaCommerceVariantsDataResolver class that inherits from PropertyDataResolverProvider and then look through the examples here to see how that needs to be implemented:

https://github.com/umbraco/Umbraco.Courier.Contrib/tree/dev/src/Umbraco.Courier.Contrib.Resolvers/PropertyDataResolvers

Ultimately, these grab the JSON value and parse out the node ID's and tell Courier to resolve them. Then on the flip side, take a node ID and update the JSON with the other environments ID. You'll need to review the TC Variants property editor JSON format though to undersrtand where these need to be extracted from.

Hopefully this gives you a starting point.

I can't see / find Courier.Core in Nuget?

Looking at the Umbraco repo, I think you might need to add a Nuget source in VS for https://www.myget.org/F/uaas/api/v3/index.json. See if that helps.

I'm hoping it's not in some private Nuget repo :(

I added it as a source, but the Nuget package manager just hangs saying "Retrieving information..."

Can I just copy the Umbraco.Courier.Core.dll from our website?

Sure, if it's quicker for now. Just drop it in a Lib folder in the project root and reference it from there.

That's correct, so we need to tell Courier about the id and groupIds for each item.

You could look at the MultiUrlPicker one here https://github.com/umbraco/Umbraco.Courier.Contrib/blob/dev/src/Umbraco.Courier.Contrib.Resolvers/PropertyDataResolvers/MultiUrlPickerPropertyDataResolver.cs

You don't need to implement the DataType side of things like some others do as we don't store any IDs as part of the data type config. So you only need to implement PackagingProperty and ExtractingProperty.

When packing you need to loop through the JSON, and when it finds an id / groupId you need to use the Courier API's to fetch the nodes GUID and then you

• Tell courier about that dependency
• Update the JSON swapping the ID to the GUID
• Reserialize the JSON back to the propertyData.Value

Then in the Extract method, you do the opposite, looping through the JSON, extracting the GUID and then requesting the related ID on the given environment and then update the JSON swapping the GUID for the local ID and saving the serializaed JSON back again.

Sorry you will also need to implement the EditorAlias property like so:

public override string EditorAlias
{
   get
   {
     return "TeaCommerce.VariantEditor";
   }
}

To be honest, i think you could just ignore that property to. That just records which variant groups were open in the UI (which I don't even know if that works right). Leaving them out would just mean on the next environment, everything would be defaulted to closed, which I don't think is a big deal.

OK, but I wasn't sure that this command would work if there wasn't a definition for "variantGroupsOpen".

How would you recommend I test this, once I (hopefully) get some code together?

RE the variantGroupsOpen, there should be a check in the code to see if it exists or not so it should be safe to remove:

https://github.com/TeaCommerce/Tea-Commerce-for-Umbraco/blob/ca70e42acbdf5c0e68ef447d716bdb2d7623d7c0/Source/TeaCommerce.Umbraco.Application/PropertyEditors/variant-editor.controller.js#L41

However on newer instances, this doesn't actually work as it looks like at some point it was changed so that the property value was only set on form submittion, and at that point it strips anything other than variants.

Either way it should be safe to ignore them for the time being.

RE testing, the only way I was able to do it in the past (which is the harder part) is that you HAVE to push it through courier. Unfortunately they don't have any kind of testing tool so you'd have to setup 2 environments, make a change in one and then try and deploy it to the 2nd and make sure it works.

Ideally I'd try and make is that the variants get different node IDs (maybe create a few dummy pages on 2nd environment so that the ID's move on a bit). This way you can make sure the IDs actually map.

So this may or may not work, but I've just roughed this out in VS Code (so there is every possibility it doesn't compile and it's defo missing using statements).

https://gist.github.com/mattbrailsford/777a8c5b6e6a063176d32e84964da14a

This might at least give you a rough idea.

Thanks for that! Amazingly, I had pretty much the same thing :-)

I'm just installing Courier locally and then I need to setup a test destination site. Then I can see if it works!

By the way, the version of item.Dependencies.Add you used is marked as obsolete ... does that matter?

We might not actually need the resovledDocTypes cache as I think all doctypes in the prevalue would be unique, but I just copied this from the InnerContent resolver so no big deal that it's there.

Updated the Gist. Needed to do a Null check on the vars and then access their Value property. Couldn't tell they came back as DataTypePrevalue from VS Code.

RE EDIT: That should be fine, Variant Group Doc Types should get skipped if it has no value.

There is the hierarchy of

Variant Groups Variant Group (e.g. colour) Variant Item (e.g. Red)

So, will these get added when a Product is Courier'd across, as they are dependencies for the Product variants?

So the variants property editor just has dependencies on what is either in the data type config (so the varients doc type field or the doc type groups variants field) and then on the document nodes referenced within the property editor UI itself.

We should now have captured all those dependencies, but what courier should do is then asks those entities "do you have any dependencies" and then that should pull everything else along. That's what courier does. Builds up a big dependency tree, and then sends it to the other instance to process in the right order.

Umm ... oops!! It is now ;-) And it worked properly that time!

Except for the Stock field which is blank on all at the Destination.

Hmm, that would probably make sense as stock levels are maintained outside of the umbraco nodes in a custom table.

In theory though, that is the desired effect as you wouldn't want to deploy stock level changes between environments. (IE your live environment should not have it's stock levels overwritten by dev / staging).

Ah, actually - we do want to deploy the stock levels!

There are a lot of options and the stock levels on the site are not the main source of that info (it's complicated!).

Would it be possible to add that in somehow (transfer the stock levels)?

I'm not sure if Courier can deploy custom entities, would need to check with HQ.

You could try copying the TC stock levels DB table from staging to live, although I have a sinking feeling that the table holds Node ID references :(

The Stock table is just Store Id, Sku and Stock

Ahh, I think it uses the NodeID if you don't have an SKU so that's a relief. In that case, you could copy that DB table and insert values for SKUs that don't already existing in that table? (Assuming your Store IDs are the same, but that's an easier one to resolve :))

If you really wanted to try and do this via courier, you could try and write a resolver for the TC Stock prop editor and get it's values from the DB, inject it into the prop value, then push it out, and on extract, take the value and inject it into the database. Thought this is kind of a hack and not sure how that would work with these variant property editors.

As I say, from a Tea Commerce official perspective, I think our stance would have to be that Stock levels aren't transfered as it's effectively "user generated content" in the fact that those values change on the live server so you wouldn't want to inadvertantly override those from a staging ENV.

In terms of the courier provider code, did you have to change anything (other than adding using statements)? or was it pretty much as per my Gist? If it's the same I'll look at moving it to a github repo.

Regarding the stock level transferring - here it is not the ultimate indicator of actual stock (!), and they want to be able to set the stock levels on Staging and then transfer it all to live.

I think the code I have is the same as yours - I can paste it here or email it to you (if you let me know the address).

If you could send it to [email protected] that would be great.

If you aren't using actual stock levels, does that mean the values don't change? If they don't change, you could use a numeric field instead of TC stock and then that should transfer.

Alternatively, you could try and fake it by writing your own Courier resovler for the TC Stock property editor and fetch the raw value from the DB and then put it back in the DB on live. The resolver wouldn't really declare any dependencies, but it would be a temporary hold for the stock level in transit if you see what I mean.

I'm not sure if this would require additional changes to the Variants resolver though to do some recursive dependency handling. You'd need to look into the InnerContent / NestedContent resolvers for that, as they should do that type of thing.

The stock level on Variants is used / updated by the website / TC, but just because it says 10 (for example), it doesn't necessarily mean there are actually 10 in stock. I don't operate the site, apparently they often update or correct the stock levels.

I think this may be a "possible future" issue to look at. For now I think they will just set the levels directly on Live.

Yea, I can defo see some resolution issues there. If stock levels change on live, but they don't on staging, if you tell it to push the product from staging again then it would overwrite the stock level there. Courier is really meant for "content" in that it would generally be, you get it ready on staging, then push it to live, then you just overwrite it on the next release.

Things like stock levels though, and other user generated content will change, and unless you are going to sync back down before pushing back up, it really doesn't have a mechanism (As far as I know) for doing this level of diffing.