zapier / zapier-platform

The SDK for you to build an integration on Zapier

Home Page:https://platform.zapier.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Curlies in dynamic fields not resolved

kentico-ericd opened this issue · comments

Zapier Platform Core 10.2.0
My repository: https://github.com/kentico-ericd/xperience-zapier-cli

I have a nodeAliasPath input field which alters other fields:

inputFields: [
{
  key: 'nodeAliasPath',
  type: 'string',
  required: true,
  label: 'Node alias path',
  helpText: 'The path of the page to update. For example, "/Blogs/Food"',
  altersDynamicFields: true
},
...

My other (dynamic) field calls getPageData with the nodeAliasPath to make a z.request

inputFields: [
async function (z, bundle) {
  const pageData = await getPageData(z, bundle, bundle.inputData.nodeAliasPath, bundle.inputData.culture);
  if(!pageData) throw new z.errors.HaltedError(`Page not found. Please check the Node Alias Path and Culture.` );
  else return await getPageColumnsField(z, bundle, pageData["NodeClassID"], pageData);
},
...

The getPageData function uses {{bundle.inputData.nodeAliasPath}} to get the provided input:

const options = {
        url: `{{bundle.authData.website}}/rest/content/currentsite`
            + `/${data.DocumentCulture}/document{{bundle.inputData.nodeAliasPath}}`,

But, when the request runs I can see in the Monitoring tab of Zapier Platform that the request performed is actually /document{{114648603__NodeAliasPath}}. This only happens if I try to pull a value from a previous step- if I type in some value, the request looks perfect and runs fine.

How can I resolve the curlies in the URL to get the actual value of the field from another step? The dynamic fields in the current step rely on the results of this request.

@kentico-ericd I don't believe curly resolution works at runtime in JS functions. Instead, you can use regular JS string interpolation:

const options = {
        url: `${bundle.authData.website}/rest/content/currentsite`
            + `/${data.DocumentCulture}/document${bundle.inputData.nodeAliasPath}`,

If you're already passing the bundle into the function, that should "just work"

Unfortunately that has the same result (I was doing that before I tried to use the {{}} notation). Using ${bundle.inputData.nodeAliasPath} still results in the unresolved dynamic value passed to the URL: /rest/content/currentsite/en-US/document{{114648603__NodeAliasPath}}.

If it helps clarify, the problem occurs because I'm trying to use a value from another step to load additional fields in the current step:

chrome_ssYd5u2FRr

If I manually type a valid "Node alias path" in that field, the extra fields load fine. Dynamic values don't work though.

Ah! So this is a known edge case in the editor.

For now, when setting up a zap, custom fields generation can't depend on mapped values. So for your purposes, you should type in the actual value /Articles/Coffee... into the text box and hit "refresh fields", which will run your request with the correct input data.

Once the fields have loaded, you can re-map the Node Alias Path value and it'll work as expected when the zap it's run for real.

We've got docs about this here (on the JIRA app because that's where it shows up most often for customers, but it's the same root issue you're seeing).

Hmm.. I see what you're saying and that does work, but not for this scenario. The step updates a page, and pages can be of any type, e.g. an "Article" could have ArticleText and a "Product" could have ProductPrice.

The Zap editor will have no way of knowing what the value of nodeAliasPath will be, so they can't type a value in that field to generate the extra fields. And, since they don't know what the path might be, they also won't know what "type" of page it is and they cannot enter a similar path to generate the fields to update. All of the data needs to be pulled in dynamically.

Is this just something that isn't possible at the moment?

That all makes sense, and is a perfect use case for custom fields. The expectation for a given zap is that it only operates on a single page type ("Article", "Product", etc). So if a user is setting up an "Update Article" zap, they'll have to manually type in an article's nodeAliasPath to load the fields.

Once they've mapped values into those fields as desired, they delete the hardcoded node path, map the value, and turn the zap on. When it runs, it'll correctly update dynamic pages.

The zap will misbehave if it gets a "Product" node path as input, because the user won't have set up a ProductPrice field. But, a second "Product" zap would have that field set up and would work as inspected.

Does that make sense?

Yes, I agree that's a valid workaround and now that I'm thinking about, probably makes more sense in a real world scenario. I will just have to provide more detailed instructions for the repo. It would be cool if this worked dynamically, but it is not a show-stopper for this particular integration. Thanks @xavdid 👍

No problem, happy to help! Let us know if you've got any other questions.