Exciting news - Release 311 is here!
The Tulip team has rolled out some fresh updates across multiple features, along with some bug fixes. Check out the release notes and dive into what’s new.
Share your thoughts and questions below 
I saw these four tickets already on r310 release notes. Why is it on the r311 release notes?
| Referenced Ticket | Description |
|---|---|
| PLAT-42769 | Fixes a bug where an operator without email couldn’t be created. |
| PLAT-42776 | Fixes the loading of analysis which referenced machine types, which were deleted in the past. The issue was present if the analysis used the machine uptime columns. |
| PLAT-42750 | Fixes a bug in the app editor where you couldn’t pick a variable for conditional formatting rule arguments because the variable list collapses immediately after opening. |
| PLAT-42774 | Fixes a bug where some instances do not display the error properly inside user invitation modal if the email is not provided |
@ta-aoki thank you for highlighting the tickets, these were all released in r310 and were included by mistake in r311 release notes.
I have now corrected this, and will double check to ensure tickets appear only in the correct release notes.
2 Likes
Hey Jordan!
What would you want to use station groups information for? Would this be something similar to this request? Station/Station Group list for Apps
No, not exactly. I’m working on a global app to use across sites. US, Sweden, and Japan. Each site needs different variables loaded on app start. Right now I have all the stations in one app group and rely on the station naming convention to load those variable.
ex:
If station name ends in “US”, do this
else if station name ends in "SE, do this
Else if station name ends in “JP”, do this.
I think a condition based on station group would be more robust. And wouldn’t require me to assign local apps to stations at another site where they aren’t relevant.
This is another use case where tags would be very useful instead of (or in addition to) groups 
Currently you always have to decide if you do it by department, by hierarchy level, by device type, by responsibility…
And sometimes these things overlap. So imagine you could add tags to stations and filter them by tags, assign apps by tags (assigned apps would also work as a tag itself) and query the tags in app runtime… 
Hi
We have the same need, to store different variable base on organizational structure (Site, Department, Production line) that end with Station (physical devise) and Operator.
Today we used a table with Station ID for storing variable.
Could be usefull to store variable at upper level of our organization.
In r320 / LTS 15, some App trigger expression functions will begin failing if they are incorrectly configured. This change affects the functions {{ROUNDDATETIME}}, {{TEXTTODATETTIME}}, {{ADD_TIME}}, and {{SUBTRACT_TIME}}. In r320 / LTS 15, if these functions are configured with an invalid timezone or datetime, they will throw an error, causing the trigger to fail. Until then, the trigger will not fail, but it will show an error toast to notify the operator that there is an expression that needs to be fixed. These changes will help prevent faulty data from being created by these functions.
We would like to fix the app before our operator see the toast message. Please could you show the list of the Apps with invalid timezone or datetime in the /apps/folders?view=warnings tab ?
2 Likes
Agree…
I guess we have tons of these.
Is not a time zone at all also invalid?
I think operators might see, that it worked just fine and therefore ignore the warning!
Also I don’t want to the apps to appear broken to the operator. That reduces trust…
1 Like
Thanks both.
We’ll start by providing a list of broken apps and triggers to your customer success manager, who can share them with you.
We’re also look into whether we can provide access to such lists through the platform - say through the Warnings tab going forward to make the process smoother.
Thank you for the feedback as well Thorsten, we’re using this as an experiment to evolve how we deprecate broken logic.
To answer your question, in this case an Expression would only give a toast warning if it was truly broken - and the database defaulted to a different timezone than the one listed.
2 Likes
I became aware of this message in r305 release note.
App trigger expression error handling:
Previously, when a user misconfigured the expressions functions {{TEXTTODATETTIME}}, {{ROUNDDATETIME}}, {{ADD_TIME}}, or {{SUBTRACT_TIME}} with an invalid timezone identifier, these expressions would default to the workspace timezone and return the timestamp value in the workspace timezone. Now, the expression will cause the trigger to fail, and this will prevent passing through data that appears correct but actually corresponds to the wrong timezone.
Are you going to postpone this behavior from r305 to r320?
1 Like
Hi Olga,
Could you please provide a list of broken apps and triggers to my customer success manager as well? Thank you.
Yes @nicolettenaya and others, we’re working on this now - we’ll need one more weekly release to get the right tracking data in place.
1 Like
Why is DATETIMETOTEXT not mentioned in the release note even though the function takes TZ identifiers as an argument?
Thanks @ta-aoki . We’re working on DATETIMETOTEXT now, and it will also be included in the deprecation, within the next few releases. It hasn’t yet been included as of r311.
1 Like