This document (including, without limitation, any product roadmap or statement of direction data) illustrates the planned testing, release and availability dates for Spotfire products and services. It is for informational purposes only and its contents are subject to change without notice. Planning to implement - generally 6-12 months out. Likely to Implement - generally means 12-18 months out.
Copyright © 2014-2023 Cloud Software Group, Inc. All Rights Reserved.
Cloud Software Group, Inc. ("Company") follows the EU Standard Contractual Clauses as per the Company's Data Processing Agreement.
Terms of Use |
Privacy Policy |
Trademarks |
Patents |
Contact Us
Hi Miguel,
fully agree that we need to avoid that files will be permanently locked and that there must be an alternative for unlocking. It is probably fine to allow other users with write access to release the lock and not limit this to an admin. However, it must be clear to those users who created the lock and that they consciousnessly release it and it should be separated from saving the file.
On the other question how to create the lock: users should be able to open a file either in edit mode (default) or read-only mode and the lock should be created automatically when doing the former.
Finally, this functionality should be only a first step towards being able to collaboratively work on a file similar to what is normal in code development (see https://ideas.tibco.com/ideas/SPF-I-4925)
Hi Christian,
Yes, the lock is normally released when the user saves or closes the file. But, in many systems, sometimes that does not happen (the user never saves/closes the file) and the files are left locked for other users. Therefor, I think it should exist a clear alternative way for unlocking: either let other users with write permissions to release the lock or only allowing an admin to release that lock.
Another question is how the lock is set. Would it be another step independent of opening a file (as in another tools where I've seen this pattern)? Or would it be automatic lock once the user opens the file and changes to edit mode?
We need to think carefully about this, since we do not want to introduce more steps on every operation, neither introduce possible bottlenecks.
Hi Miguel,
I agree that simply locking a file and then potentially forgetting it, wouldn't be the best solution. But if a user with edit rights opens the file in Analyst or Business Author this could trigger a lock until the file is closed again. And when other users with edit rights want to open the file in the meantime, they should see the lock either in the library browser before opening the file or within the file when it is open. And an admin or someone with full control in the corresponding folder of the library could remove the lock if needed. Would that work?
Hi,
I see this idea is getting some traction.
I have to say that this feature is controversial. If a user sets a lock on a library item, that blocks any other user for doing contributions. Some old applications (e.g. MS SharePoint) have this lock mechanism and often it is considered as a bottleneck that stops team members for contributing because often some user forgot to release the lock.
Maybe it could be useful if other users can do a "force write" to override a previous lock from some other user. In that case, it is a conscious decision and avoids locking the whole team when someone forgets to release a lock.
What are your thoughts?
Hope this happens with Library version control that is being planned.!