Means of locking a file that is risky to merge
Hi
Our team is trying to set a team role permission to allow files to be locked to prevent concurrent development. But the setting appears to have no effect. We are using RTC 3.0.1. Below is a description of what we require, how we attempted to configure RTC for this purpose and the error that the user continues to receive.
Are we missing something?
What we need:
As a team of 4 working with a file type that is both difficult and risky to merge we need a means of locking the file to prevent concurrent development.
Only the team member holding the lock should be allowed to modify the file. The locking mechanism must operate at the file level if it is to be a pragmatic solution.
What we have done:
Configured the Team Member role to allow locking by checking "Locking" as a permitted action under Save Stream (server) / Modify / Stream - (within Team Configuration Permissions).
We still get this error when attempting to lock a file:
"In order to carry out this operation, you would need permission to perform the following additional actions: Acquire, Release or Transfer locks. ID: modify/stream/locks/manage"
Please help.
One answer
please read: https://jazz.net/library/article/291
The permissions have to be set in the context that owns the stream, check who owns it. The top level Team Configuration is for the project. You have to make sure the user has the role with the permission granted in that context.
Locking is a manual process out of the box today. I have heard other users have created extensions to automate it. There is a work item to support pessimistic locking.
Comments
Hi,
please read: https://jazz.net/library/article/291
The permissions have to be set in the context that owns the stream, check who owns it. The top level Team Configuration is for the project. You have to make sure the user has the role with the permission granted in that context.
Locking is a manual process out of the box today. I have heard other users have created extensions to automate it. There is a work item to support pessimistic locking.
Thank you Ralph. We had been setting the role permission within the team configuration only. Now it is set for the project timeline and the locking looks to be working now. Thanks for the pointer.