Some anomalies regarding checkout locks (exclusive).

[idselectronics]

Hello. I'm currently evaluating the latest version of Vault Standard.

I've set up the initial repository to require locks on checkout (the same way that VSS works). I then created a new project with the administrator account to test with and added files to it. I then checked out all of the files which successfully reported that the administrator account had checked them out and had "(exclusive)" next to the account name. From there, I created an additional user and set up folder permissions on the project so that the user only had "R" permissions. (I am assuming R means read-only. In retrospect, I gather that this was probably redundant as I'm also assuming the "C" stands for checkout. Please correct me if I'm wrong.)

Here's where the problems come in. I logged in with the client as the new user that has only read access to the project. I attempted to check out a file. To my surprise, I was prompted to set a working folder. I did so, and noticed that the file had been downloaded to the folder (I had the folder open and viewable next to the vault client's window). Then, I was given an error that I did not have proper permissions. The file remained listed as checked out by administrator (exclusive). However, a working folder was now set for this project with the read-only user and thus all files' statuses were listed as "Missing". This seems like a bug to me?

Beyond this, I encountered an even more glaring problem. With the same read-only user, I then attempted to a file from the project. (The file was still checked out exclusive by the administrator.) It removed the file from the project in the vault client! It then gave me an error saying that I did not have permission. Still, the file is no longer listed in the view and continues to be missing. I can refresh the view and even reconnect to the vault server, but the view remains the same with the file missing. And it's not just that it's missing from the view, as it will fail to download when I try a get latest on the entire project folder. When I log back on as the administrator, however, the file is still there. So, it didn't get deleted from the project, per se, but it is, for all intents and purposes, deleted from the project specifically for that read-only user.

I need clarification on whether these are indeed bugs or if I'm setting things up incorrectly somewhere before I can make a decision on migrating our company to this product. Thanks.

[Beth]

If you want to check out or check in, you need RC permissions at a minimum. Also, when any other user has a file checked out exclusively, no one else can check them out.

I will run a test to see if I can reproduce the missing status.

I then attempted to a file from the project.

Can you clarify the action for me?

[idselectronics]

If you want to check out or check in, you need RC permissions at a minimum. Also, when any other user has a file checked out exclusively, no one else can check them out.

I will run a test to see if I can reproduce the missing status.

I then attempted to a file from the project.

Can you clarify the action for me?

Thanks, Beth. What you describe is exactly what I was expecting.

Regarding the first issue, my surprise was in the fact that, as a read-only user, I was asked to set a working folder in this situation. If a user does not have rights to check a file out, should those rights not be the first thing the system runs a check on? Instead, I set up a working folder and even downloaded the file to it before the system checked to see if I had access to check it out and gave me the error. Because the error only shows in the messages window, I can see this being a potentially misleading problem for users. Furthermore, the client GUI goes on to show "Missing" status for the file because the working folder was set but the checkout failed.

I have to apologize for my omission regarding the second issue. The sentence you quoted should have read "I then attempted to delete a file from the project." This was once again using the read-only account. I was simply testing the permissions to make sure they acted as expected. This issue is of more concern to me than the previous as it seems to introduce an irreversible glitch for the user that attempts it without proper permissions. The glitch being that the file is removed from the GUI's view for that user, and any future "gets" or checkouts for that user do not include it either.

EDIT: After further investigation, I was able to determine how to regain access to the deleted file via "undo" in the "pending change set" window. So, not as big a problem as I originally feared. I would still like to see a change in the future that would have permissions checked before absolutely any actions like this are carried out, though. Would you acknowledge that this is not quite working as intended or am I missing something? Thanks!

[Beth]

Here's where the problems come in. I logged in with the client as the new user that has only read access to the project. I attempted to check out a file. To my surprise, I was prompted to set a working folder. I did so, and noticed that the file had been downloaded to the folder (I had the folder open and viewable next to the vault client's window). Then, I was given an error that I did not have proper permissions. The file remained listed as checked out by administrator (exclusive). However, a working folder was now set for this project with the read-only user and thus all files' statuses were listed as "Missing". This seems like a bug to me?

I tried a couple times with a few different versions and was unable to reproduce this behavior. If you would like us to investigate this behavior that you have seen, we can take this one offline to see exactly how this happened in your case.

Setting a working folder as a read-only user shouldn't be a problem. In order to read the file, it still has to pull down a copy somewhere. The status also doesn't tie into a user's rights. As long as the file was able to be retrieved to disk and as long as a cache was able to be created, some status other than Missing would be present. What's important is that the user can't lock the file nor can they check in changes.

With the Delete, there are two parts to a transaction. The Vault client prepares the transaction first, and then the transaction is committed to the server. When you deleted the file, it was set first in the Vault client, and then it was committed to the server. The two parts will seem clearer if you turn off automatic commit in the client. That is set in the Vault Tools - Options - Check In. You don't have to change that. It's just if you want to see the transactions separately. With this method it's possible to have a bunch of changes saved up and then check them in at once. It's also useful if working without an internet connection.

[idselectronics]

The Vault client prepares the transaction first, and then the transaction is committed to the server. [...] With this method it's possible to have a bunch of changes saved up and then check them in at once. It's also useful if working without an internet connection.

I understand now why the client would be designed to perform some actions before attempting communication with the server (to include permissions check). I think this reasoning actually clears up both of my questions. Thanks!

[Beth]

I should probably clarify that if you didn't have an internet connection, you wouldn't be really in the Vault client, because it requires the login, but when working in Visual Studio, it allows you to work offline while even if you are using bindings to Vault.