nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Users can't edit DCRs locked by themself

GriffTheDog

TeamSite 6.7.2 SP2
Windows Server 2003

Users login to TeamSite with their Windows Domain accounts.

Yesterday after doing an make_toolkit in the morning one user was unable to edit DCRs that were locked to themself. The lock symbol on the DCR was the padlock instead of the key, when hovering over the lock their own name showed as the lock owner and when they clicked the properties of the DCR their name is displayed in the locked property.

We fixed this issue for this user by kicking everyone out of the production environment and performing an iwreset -a.

Unfortunately immediately after the iwreset -a a different user started complaining of the exact same issue.

We need a better solution.

What we've also tried:
1. Different browsers - IE8, IE9, Chrome 26 and Firefox 10. (we did see in a devnet post about this same issue that Firefox 3.5 worked, but that is not an option for us)
2. Different cases to login to TeamSite: lastnamef, LASTNAMEF and LastnameF
3. Had the user log out and in.
4. Had the users move to different workstations.

We have seen this issue before, but it has been over 6 months since the last time. We solved it then by performing an iwreset -a.

Any help with this is appreciated.

Find more posts tagged with

Comments

GriffTheDog

We have a solution that appears to work: Delete user from TeamSite and then Add them back.

Rick Poulin

Some versions of TS on Windows (I don't recall which exactly, but 6.7 rings a bell) had a small but annoying bug with regards to case sensitivity with usernames. Because of case insensitivity in Windows and Active Directory, both DOMAIN\username or DOMAIN\UsErNaMe are valid for logging in. However, in certain very specific cases, TeamSite doesn't consider those to be equivalent. In my particular case, I ran into this with the CSSDK where the definition of CSUser#equals() is case sensitive regardless of your OS. You might be running into a similar situation, based on the evidence you've provided. Shot in the dark, but you never know.