Release 230 is going live, read below for some of the highlights.
App Editor
Custom widgets are now on for everyone - and there is some default Tulip themed CSS included
A new e-Signature form has been added to enterprise accounts
Checkboxes, single-select, and multi-select widgets can now have triggers attached to them!
A new look and feel to the steps tab! This is one of the first steps to some big usability improvements coming down the line. For now though, we’re very excited to begin introducing these changes.
You can now view and adjust the ordering of elements on the page by adjusting their position on the steps tab!
You can also search the elements on the steps tab
Try right clicking on it as well to quickly delete, duplicate, or group
Analytics
Improved performance by preventing redundant rendering
Connectors
Added the capability to toggle visibility on the password, secret, and token fields for headers.
Fixes
Fixed running SPLIT() on a null value in the expression editor
Fix machine output change trigger not firing when an attribute or state changes
Analytics Editor: Fix the line chart to work properly with null values
Fixes a bug where table record links would not render properly after incrementing a different value in the table record.
Fixed a bug where users couldn’t add or edit Downtime Reason triggers in app editor
Improved performance of the trigger modal using User datasource
In regards to text and number inputs… Any chance you could fire a trigger when enter is pressed while in the input field? That is something I always wished I could do.
How should we handle this for a text input where someone might be making a multiline note and need to use enter to type their note?
I made a custom widget to do this in this video, but it comes with those caveats:
We are actively discussing adding this as a quick win, and your feedback would go a long way to deciding if we enable this natively. The concept of a separate widget trigger type for “On enter” is one avenue to address this, but it is also a bit more work than a trigger that fires on any input.
The way I see it there are two types of Text input.
Single Line (Also includes Number Inputs) and Multiple Line.
I don’t know if you can treat these differently in terms of your internal logic.
If possible I would say on single line just pressing Enter should be enough. Since you can’t have a line break anyway.
For multiple line you could potentially register a Key combination of SHIFT + Enter as the trigger input.
Im gonna have a look and try out the custom widget later. Sounds like a nice solution for now as well.
This is one approach we have definitely discussed. My role in the product team is primarily to make the product easier for new users, so I am always looking to add features that are as intuitive as possible. When I think about that approach, a few concerns come to mind:
If we split the text widget into a single line and multiline widget
If I dont know about triggers yet, why are there 2 text input types?
Which one should I pick?
Why can I only add triggers to the single line one?
If we just relied on the multiline text input toggle and kept just a single text input-
How do we make it discoverable that you can add triggers to an input if you are on multiline mode?
Do we display triggers but in a greyed out state when in the multiline mode? Can you edit them in the wrong mode?
If you toggle an input from single line to multiline, do we delete the trigger, or store it in the background just in case you ever turn it back to singleline? What if when you toggle it back on it is referencing a table you arent using anymore? We won’t let you delete a variable used in a trigger, but what if that trigger is hidden in an input?
Just a little more color on how we think about these sort of features internally. Absolutely something we are trying to find the right answer for, but not necessarily an easy one, or one where a one size fits all approach can be implemented in a way that someone on day 1 might understand.
Cool! I’ve waited so long for this feature.
But one question: In which order do the actions happen? Is the variable changed first and then the trigger is fired, like with interactive tables, or is the trigger fired first and after its completion the variable is changed? Or is there a totally different order?
The variable value is updated before the trigger is executed, so you could have a single select where users select a line they are auditing, then on a trigger on that single select, you could do a conditional based on the user selected line.
Out of an abundance of caution I just tested every edgecase I could find around this, to see if there was a case where this behavior wasn’t correct. What I found is if an input is tied to a table record field (not super common, but possible) it won’t update before the trigger fires, so conditional logic is incorrect.
This is a high priority bug to fix, and we are hoping to have this resolved in the next release. In the meantime I would highly recommend only using triggers on these widgets when tying them to variables, not table fields.
That is the case right now. Having said that, once a widget is created any app editor user can use it. This was an intentional home just for the time being until we can build more governance around user management and rights. There is work going on to improve how user roles can be managed and custom widget will be part of the feature set that can be assigned/unassigned to any role. This work is just starting, so I wouldn’t expect this to change in the next quarter.
App Editor
Analytics
Connectors
Fixes