Default layout on email step when created through API
Through the API, when I create a workflow with an email step, the default layout is not set as the layout for that step. More technically, the step returns a _layoutId as null. A look at the source code confirms that behaviour as much as I could tell.
Is this what is expected/desired?
I have follow thoughts, but just want to confirm that first.
A general comment is that the Web client seems to overlay functionality/lifecycle management that I would have thought could/should be in the API. This makes it harder to understand particularly as I am trying to help maintain a client SDK (and looking to build a terraform provider).
7 Replies
Hi @todd7201
I agree with you 🙂
In UI we first call all existing layouts, show them in drop-down.
Once user select item from drop down that layout id is selected
To replica this via api, you will have to first call the get layouts api
I hope it helps 🙏
@Pawan Jain Thanks, that is what I am doing. I will note that this exposes a defect in the UI. When the Step has no layoutId on an email, the displayed layout (on the UI) is the default layout but it actually isn't set. If you click on the drop-down it then works out that it isn't set. This got me for a while because the email was being generated without the default layout.
Also, if I'm right through the UI you have to have a layout when programmatically you don't—and I can see cases to not have a layout 🙂
Cheers.
@todd7201, you just advanced to level 2!
Thanks @todd7201
I see we should use default layout if no layoutid provided
@Pawan Jain I may not 🙂 [sorry, a bit late here]
If you are meaning at the UI-level in the web interface, sure, go ahead! Certainly, at worst ensure that the UI aligns with the data. Partly here you will need to retrofit for cases where there is no default.
On the API, I wouldn't default values because generally that's not very REST. If I do a PUT then I don't expect you to mutate the resource (because I would expect the same resource back) and defaulting values should be provided to the client to include in the first place (which often also means breaking up resources). Put differently, if you want to default a value then you should make sure it is provided in the POST or PUT resource. It's not a hard problem to solve but one that the current API isn't looking to address and hence these problem leak into the solution (IMHO).
If you are meaning at the UI-level in the web interface, sure, go ahead! Certainly, at worst ensure that the UI aligns with the data. Partly here you will need to retrofit for cases where there is no default.Currently, we create a layout by default in each organisation. We set that layout as default. Default layout cannot be deleted. So there will always be a default layout present in each organisation.