Exciting news - Release 329 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
![]()
Exciting news - Release 329 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
![]()
We are sunsetting {{open file}} and {{save image}} triggers supporting non letter drive paths on Windows.
Tulip is implementing a new site setting in the Account Settings page which will give customers the ability to toggle being able to write to or read from network drives.
What do you mean by “non letter drive“ ?
How to Map Network Drive in Windows 10/11 from Explorer, Command Prompt or PowerShell. - WinTips.org
Are you sunsetting the access to Z: ? \\desktop1\shared_folder? or both.
@jaksif I’m not directly concerned by that feature, but I find this paragraph extremely unclear and confusing! One sentence seems to contradict the previous one systematically and it feels like some information is repeated:
Security fix: We are sunsetting {{open file}} and {{save image}} triggers supporting non letter drive paths on Windows.
Tulip is implementing a new site setting in the Account Settings page which will give customers the ability to toggle being able to write to or read from network drives. This new site setting will be implemented starting in r329 and will be enabled such that writing to or opening from network drives is not allowed by default but can be modified. Writing to or opening from local drives will remain enabled regardless of this new setting.
Would you mind having it reworded?
Hi @ta-aoki,
The letter drive is in reference to this deprecation. This would not impact named drives as noted above.
Sincerely,
Jake
Thank you for the comment, but you are not answering my question.
letter drive can be a network drive in Windows. I guess that is why @fti and I think the wording is confusing.
I hadn’t noticed that but indeed, this certainly doesn’t help! ![]()
With the new site setting enabled, if you are going to refer to a network drive, like \\desktop…, it has to be mapped to a letter drive, Z:. You cannot directly reference \\desktop.
If you have the new site setting off, you can use \\desktop but that is not recommended by Tulip.
Sincerely,
Jake
Thank you.
OK, so the access using a mapped network drive (e.g. Z:) is not going to be sunsetting.
I’m confused.
Hi @thorsten.langner ,
The account setting is available from r329 onwards, but the account setting will only block you from accessing network drives in r336.
It’s okay if they are listed on different letter drives (A: - Z:) and you can still map a network drive to a letter drive (like in @ta-aoki ‘s example above).
The issue with non-letter drives (i.e. network drives) is that there is a security vulnerability of a bad actor reading/writing files to and from a network drive. Tulip is giving you the option to enable/disable network drives but we recommend that you leave them disabled.
Sincerely,
Jake
Thank you but sorry I don’t get it.
When Station A has a Z: … and Station B has a W: … for the same drive \\testdata\line1\ .
What would I set up in the App, so that it works with them?
Z: …could be something different on station B and it should open the correct path…
Currently I choose \\testdata\line1\ and it works for all. But when I set it to Z:\ it will open a different path on station B doesn’t it?
I would recommend that you use the same letter drive (i.e. “Z:\testdata\line1”). Alternatively, you could opt out of the site setting.
Sincerely,
Jake
Thats what I was talking about. This is almost impossible with hundreds of stations, where also a lot are personal stations.
Ok thanks for clarification.
Hi everyone,
I’m writing to provide more context and clarity around a recent release note regarding network drive access. We recognize our initial communication was confusing, and I want to apologize for that and set the record straight.
To be clear: We are not removing or deprecating support for UNC paths (e.g., \\servername\share).
Instead, we are adding a new, optional security setting for customers who operate in highly regulated industries. Based on their feedback, we are introducing a control in the Account Settings page that allows administrators to block the use of UNC paths in triggers like {{Open File}} and {{Save Image}}.
This setting will be enabled by default. For customers who wish to continue using UNC paths, no action is needed, and your workflows will not be affected.
Why are we adding this option?
For some of our customers in regulated verticals allowing applications to access non-lettered network drives can pose a compliance challenge. Disabling UNC path access is a security hardening measure they requested. The primary reasons for this preference are:
Attack Surface Reduction: Limiting accessible network paths to a predefined set of lettered drives can reduce the potential surface area for malware that tries to enumerate and traverse network shares.
Simplified Auditing & Monitoring: It is often simpler to configure and monitor access logs for a finite set of mapped drives, which helps in tracking access to sensitive data and identifying anomalies.
Clear Policy Enforcement: Administrators can use tools like Group Policy Objects (GPOs) to map specific drives for specific users, providing a clear and enforceable mechanism for access control that aligns with the principle of least privilege.
Our goal is to give customers more granular security controls, not to take away functionality. We missed the mark in our initial announcement, and we are committed to communicating more clearly going forward.
Hope this context helps.
Pete
Hi @Akira,
The account setting is on by default, and Tulip’s stance is that this is the best general recommendation. However, if you decide to change the account setting, you are more than welcome to.
Sincerely,
Jake
Hi @jakerigos ,
OK. I got it. I need to announce this to our customers.
Kind Regards,
Akira Takahashi