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

WFB lock issue

ShovelFace

Solaris 9
TS 6.5 SP1

Scenario:
- auth1 created content and submits to workflow
- lock task in wfb locks file, visually shows in TS as being locked by auth1
- task then routes to group task
- edit1 'takes' ownership, visually in TS the file shows up as being locked by edit1
- auth1 checks file in TS and does an Action->Unlock, and is able to unlock (ack!)

If the same scenario is repeated, but with auth2 trying to unlock via Action->Unlock, auth2 is unable to unlock

We are using Submit Locking.

Comments?

Find more posts tagged with

Comments

Migrateduser

Are auth1 and auth2 working in two different workarea or in the same workarea?

If auth1 and auth2 use the same workarea then only the user that has lock will able to unlock the file.

If auth1 and auth2 work in separate workareas then both the user can obtain locks for the file. But who ever obtains the lock will be only able to submit the file and release the lock or unlock the file.

Adam Stoller

Solaris 9
TS 6.5 SP1

Scenario:
- auth1 created content and submits to workflow
- lock task in wfb locks file, visually shows in TS as being locked by auth1
- task then routes to group task
- edit1 'takes' ownership, visually in TS the file shows up as being locked by edit1
- auth1 checks file in TS and does an Action->Unlock, and is able to unlock (ack!)

If the same scenario is repeated, but with auth2 trying to unlock via Action->Unlock, auth2 is unable to unlock

We are using Submit Locking.

Comments?

Are you saying that 'auth2' is trying to unlock a file that 'auth1' submitted via the workflow?

I presume that the locktask is owned by the initiator of the workflow ('auth1' in your initial description). The lock can then be "assigned" to other users within the workflow, but the lock is still "owned" by 'auth1'. An author has the ability to unlock a file that they own.

An author (or editor for that matter) does not have the ability to unlock a file for which someone else owns the lock - though they may be able to unlock a file for which the lock was assigned to them.

Huan

I tried this senario and it was exactly like ShovelFace described. It is so confused that the auth1 can still unlock the DCRs that locked by edit1. How to fix this problem? The workflow lock task behaves differently than what we expect. We expect that after the edit1 takes ownership of the task, sdauth1 shouldn't be able to unlock it.

ShovelFace

Are auth1 and auth2 working in two different workarea or in the same workarea?

If auth1 and auth2 use the same workarea then only the user that has lock will able to unlock the file.

If auth1 and auth2 work in separate workareas then both the user can obtain locks for the file. But who ever obtains the lock will be only able to submit the file and release the lock or unlock the file.

auth1 and auth2 are in the same workarea. So is what happening is that auth1 'owns' the lock, but has only transferred it to 'edit1', and as such since auth1 still 'owns' it they can take it back, so to speak? If so, how does one fully transfer the lock to edit1?

ShovelFace

Are you saying that 'auth2' is trying to unlock a file that 'auth1' submitted via the workflow?

I presume that the locktask is owned by the initiator of the workflow ('auth1' in your initial description). The lock can then be "assigned" to other users within the workflow, but the lock is still "owned" by 'auth1'. An author has the ability to unlock a file that they own.

An author (or editor for that matter) does not have the ability to unlock a file for which someone else owns the lock - though they may be able to unlock a file for which the lock was assigned to them.

So the owner of the lock can unlock it at any time even if it has been transfered? Is there a way to fully transfer ownership of the lock?

Migrateduser

auth1 and auth2 are in the same workarea. So is what happening is that auth1 'owns' the lock, but has only transferred it to 'edit1', and as such since auth1 still 'owns' it they can take it back, so to speak? If so, how does one fully transfer the lock to edit1?

If you are using launch pad it locks the file automatically for you, but does not release the lock when its complete. So the user auth1 needs to unlock the file before auth2 can aquire a lock and release it.

Could you elaborate more on the sequence of steps individullly for editing the file wrt to auth1 and auth2.

Adam Stoller

So the owner of the lock can unlock it at any time even if it has been transfered? Is there a way to fully transfer ownership of the lock?

Explicitly unlock the file (iwunlock) and then lock it by the other user (either iwlock or via the

locktask

mechanism).

Note - if you go the iwlock route - you probably need to make sure that your tasks do not define the

lock="t"

attribute as I don't believe that the workflow will transfer locks which were granted that way and your task will hang with something like "trying to aquire locks".