Allow tagging workflows through external API [GOT CREATED]

mig82 · May 23, 2023, 5:17pm

The idea is:

Using POST on the external API’s /workflow endpoint or PUT or PATCH on the /workflow/${id} one should accept a tags array. The tags array should accept an array of tag names. If a tag by the given name does not exist, it should be created on the fly.

My use case:

I’m using Git to version my workflows. I’ve used the external API to export them from my local instance for versioning, but then on the way back I want to be able to restore a specific version, or to “promote” a specific version up to our cloud instance. In these scenarios, I want to tag those workflows to match the Git tag I’ve used in the repo.

I’ve tried using the internal API (as described here Set Workflow Tags via API), but this is unsupported and I’m facing a weird problem when updating the workflow using PATCH rest/workflows/{id}

I’m getting an error that reads:

400  'Your most recent changes may be lost, because someone else just updated this workflow. Open this workflow in a new tab to see those new updates.'

I think it would be beneficial to add this because:

It would allow developers to better manage their SDLC and be able to import different concurrent versions of a workflow, provided that they’re properly tagged.

It would also bring the creation and update of workflows more in line with what we get from the export. I’ve had to deal with removing read-only properties which I get from the export and it feels hacky.

Any resources to support this?

I’m happy to showcase the use case and my import script during a call.

Are you willing to work on this?

Sure.

mig82 · May 23, 2023, 5:27pm

@AndrewMitchell I saw your post (Set Workflow Tags via API) on this issue.
Perhaps you’d like to vote up on this feature request?
Also, did you run into this error when trying the workaround described there?

HTTP 400 Your most recent changes may be lost, because someone else just updated this workflow. Open this workflow in a new tab to see those new updates.

mig82 · May 24, 2023, 11:55am

So, I noticed that in the post referred above, the login for the cloud instance is different.
I’m now trying this.

POST https://api.n8n.cloud/auth/login?username=${username}&password=${passwrd}

But what I get in return is something like this.

{
  redirect: {
    url: 'https://foo.app.n8n.cloud/cloud/signin?code=xyz
  }
}

I was not sure of what to do with this, but following the behaviour of the n8n console I tried this:

GET https://foo.app.n8n.cloud/cloud/signin?code=xyz

Now, in the browser I can see that this should result in a cookie n8n-auth being set, but when I try this in code, I don’t get such cookie back. Any ideas?

@jburgers since you helped on that thread, do you think you could have a look at this?

Jon · May 24, 2023, 12:04pm

Hey @mig82,

Don’t forget that what you are trying to do is not recommended and it is not supported. It may also be worth keeping this topic just for the feature request so things don’t get mixed up.