Users can check out but they can't check in

asills · Post by **asills** » Tue Jun 26, 2007 9:13 am

I created 4 new users in Vault (3.1.9.3798) today, made their security permissions the same as other users in the system (gave them no default rights and assigned them to a group that gives them full control to two repositories), and made their passwords authenticate via Active Directory.

When those users log in, they can check files out, the files show as being checked out by them (in their UI and in the admin), but when they right-click a file to check it back in the "Check In" menu isn't enabled.

I went to the admin to make sure the file really was checked out and it is. I went to another machine and logged in as a user having trouble and I could check out but not in there also.

I've gone through their security compared to others in their "group" and it's identical.

Has anyone seen this before?

lbauer · Post by **lbauer** » Tue Jun 26, 2007 12:38 pm

This doesn't seem like a security issue, since a user without checkin rights wouldn't be able to checkout, either.

Let's see if this is user-specific or machine specific. Have a user (who is not having problems checking in) log in to a machine where checkins are greyed out for the new user. Can this user checkin after checking out?

asills · Post by **asills** » Tue Jun 26, 2007 12:52 pm

lbauer wrote:This doesn't seem like a security issue, since a user without checkin rights wouldn't be able to checkout, either.

Let's see if this is user-specific or machine specific. Have a user (who is not having problems checking in) log in to a machine where checkins are greyed out for the new user. Can this user checkin after checking out?

I think I've already done that. Our two developers who can't checkin are in India so I can't get them to do anything for us, but we've tested their accounts on our (already working) machines.

Log into Vault using my account on my box and everything works fine. Log into Vault using their account (all 4 new users) on my box and I can check out but not in.
Repeat on a coworker's machine and get the same results.
Logging into my account on a coworker's machine works perfectly as does his account on my machine.

If I create a brand new user with the exact same security setup (remove all default rights and add them to this one security group) that user is able to check out/in successfully. The only difference with the new user I just made is it's not using AD authentication.

Also note that it's not that Check In is just disabled and they can't do it. The UI is behaving as if the item is not checked out. Checkout is enabled (and I get an error by selecting it again) and the UI shows the file as checked out to me (the user having the problem).

I've added screenshots too, just in case it helps (so you can see the configuration).

asills · Post by **asills** » Tue Jun 26, 2007 1:28 pm

And FYI, I repeated the process with a new user account, AD authentication, same security and it can check out/in successfully.

lbauer · Post by **lbauer** » Tue Jun 26, 2007 2:37 pm

There may be some sort of database inconsistency, but before we go down that path, let's try a few more things.

Close the Vault Client, then delete the client-side cache for the user(s) who can't checkin. The cache would be on the Vault client machine, in Document and Settings\<WindowsUser>\Local Settings\Application Data\SourceGear\Vault_1\{repository GUID}\<Vaultusername>.

I would delete the cache, then restart IIS, which would reset anything cached on the server side. Then login to the Vault GUI client with one of the accounts that can't checkin. Reset your working directory, and do a Get Latest.

Is checkin enabled?

--If not, try this:

In the Vault Client under Tools->Options->File List columns, enable "Check Out Location."
Note the checkout location for the file checked out by that user.

Logout and login as one of the users that can checkin. Checkout the same file or at least checkout a file from the same folder.

Is the checkout location the same? We have had reports of Windows Management not correctly reporting the checkout location, which confuses Vault.

--Another thing to try:

If you give the users explicit rights to a folder, rather than inherited group rights, can they checkin?

asills · Post by **asills** » Tue Jun 26, 2007 3:04 pm

Deleted the cache (whole thing so I didn't have to figure out which GUID was which repository), restarted IIS (that AppPool hadn't recycled in over a year - sad to have to do that to it when it's going so strong), no change in behavior.

* Logged in as problem user
Set my working folder to C:\test, checked out a file. Can't check it in. Noted check out location.

* Logged in as my user account
Set my working folder to C:\test, checked out a file. Check out location is the same, I'm able to check in my file.

* Repeated on separate machine, same behavior.

lbauer · Post by **lbauer** » Wed Jun 27, 2007 9:25 am

--Another thing to try:

If you give the users explicit rights to a folder, rather than inherited group rights, can they checkin?

asills · Post by **asills** » Wed Jun 27, 2007 9:38 am

lbauer wrote:--Another thing to try:

If you give the users explicit rights to a folder, rather than inherited group rights, can they checkin?

Looks like a no-go. I gave the user RCA rights on the folder I've been using for testing (he showed no rights previously in that screen, I assume that's because it doesn't resolve groups in there?). I logged in as him, went to that folder and the checked out file still said checked out.

I undid his checkout through the admin and tried again, got some unexpected behavior, but no fix.

Unexpected behavior:
Undo checkout is available now on files that were previously checked out. My working folder was missing for some reason (I had set it yesterday) and when I set the working folder again it went back to normal (Undo Check Out disabled like it should be). Checked another folder without a working folder set, Undo Checkout is enabled unexpectedly. Is that normal? A folder with no working folder gets Undo Checkout enabled? I tested on my user account and the behavior is the same, so I assume it's not related to this problem at all.

lbauer · Post by **lbauer** » Wed Jun 27, 2007 11:03 am

We haven't had reports of this behavior before, so it's not clear what's going on. It could be a configuration/environment issue, or a database problem.

We could do a remote session for further troubleshooting, or you could send us a copy of your database so we could try to reproduce the problem here.

Email me at support at sourcegear.com, ATTN: Linda and we'll decide what to do next. Be sure to include a link to this post in your email.