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; } } }

Locking Issue in SitePublisher

work4u

I am running into the following two issues with locking.

1- When I am editing a .page file and upon save it gave me an error that the page cannot be saved because it is locked, when in fact it's the same user editing the page and has the key to the locked file. If I go and unlock the .page file then it will save.

2. If I have a component that is DCR driven and when I try to edit the component it will open the DCR even though it locked. Upon completing the edit when you try to save the DCR it will prompt you that the DCR cannot be saved because it is locked.

Has anybody encountered these issues or know if these are bugs or if there is a workaround.

Appreciate your help.

Find more posts tagged with

Comments

Frederik

1- When I am editing a .page file and upon save it gave me an error that the page cannot be saved because it is locked, when in fact it's the same user editing the page and has the key to the locked file. If I go and unlock the .page file then it will save.

your platform?

We encountered that very issue recently on a brand new 6.7.2 + patch 2 install on Windows 2003.

It turned out to be like this:
- When user was created in TeamSite, I entered it as

DOMAIN\x12345

(lowercase x)
- but it was saved internally in TS as

DOMAIN\X12345

(uppercase X)
- user was logging in on webui (ccpro) as

DOMAIN\x12345

(lowercase x)
- when user started editing a SitePub page, a lock was set for

DOMAIN\X12345

(uppercase X)
- when user wanted to save page: error that the page cannot be saved because it is locked

I don't remember if we found proof in the logs, but it was at least our assumption that when SitePub / TeamSite checked the lock versus the current user, the uppercase / lowercase mismatch caused the problem.

The problem went away when the user logs in using the same capitalisation as the way the account is stored in TeamSite. In our case, that was

DOMAIN\X12345

(uppercase X)

I've been told by an IWOV engineer that this would be addressed in a future patch on 6.7.2 (supposedly in Patch 3)

work4u

Fredrik..... Thank you so much for your reply. What you described above was the issue I was encountering and logging out and logging back in with the excat case solved the issue.

Appreciate your help.

eaparicio

Fredrik..... Thank you so much for your reply. What you described above was the issue I was encountering and logging out and logging back in with the excat case solved the issue.

Appreciate your help.

We are experiencing this same issue after upgrading to 6.72 sp2 in a unix environment so the logging in with the specific case is not an option. We did however notice that the issue stops when we clear a field such as the email for a user, save, reopen and readd the email. We did this for each user but 2 people experienced the locking issue again. One solution we're contemplating is to run post install scripts that apparently rebuild iwadmin. Anyone experiencing this same issue?