Submit behaviour with locked files

Can anyone tell me what the expected behaviour is when you submit a locked file to STAGING?

What happens in our version is that the file if locked does not appear in STAGING but there is no warning, the Submit workflow tasks runs as expected.

Running TeamSite 7.1 on Win 2003

Find more posts tagged with

Comments

nipper

That is the expected behavior. The lock does not prevent it from being versioned.

Rick Poulin

If you're the lock owner, or have a role that allows you to bypass perms, the expectation is that it would submit it normally (i.e. the same as if it weren't locked).

If you're a normal user and you don't own the lock, I don't recall what's supposed to happen. Our workflows always trap that situation before anything else. But I'd expect it to submit just the same.

In your case, it sounds like your submit operation is failing for some reason (even though the task transitions). You should check your log files to find a relevant error message.

(EDIT: after seeing nipper's post.. I read your query as "the locked file gets skipped by the submit op"; not sure if that's the case now)

Adam Stoller

I think it depends on the attributes associated with your Submit Task (or submittask if you're using a WFT). The option to check is:

skiplocked (supposed to default to "f", but could be set to "t")

If skiplocked is set to "t", then the process should silently skip any locked files and just submit those that are not locked.

I don't recall what the behavior is supposed to be if (a) you are the lock-owner or (b) you are a Master or Administrator user on the branch where you are attempting to submit the file -- nor whether that behavior differs based on the setting of skiplocked. You should be able to verify what it does pretty easily - either through the workflow or via the command line.

If you're going to use the command line to test it - I suggest doing the following:

Create a file like /tmp/foo (or c:\temp\foo) that contains a list of three files: one that is unlocked, one that is locked by you, one that is locked by someone else.
Remember that the format of the file should be:

/default/main/..../WORKAREA/.../path/to/file1
Obligatory comment
/default/main/..../WORKAREA/.../path/to/file2
Obligatory comment
/default/main/..../WORKAREA/.../path/to/file3
Obligatory comment

From the command line, logged in as a "non-power-user" (e.g.: Author who owns the lock on "file2"), run:

iwsubmit -s -r -f /tmp/foo

Repeat the process logged in as a "power-user" (e.g.: Master), changing the lock on "file2" first to make sure it is owned by "you")
Repeat both of the last steps (making changes to "file2" as needed), this time leaving off the "-s" flag.

Compare the results (posting them would be nice)

tbkeith

In this case it was the OOTB workflow "Submit Workflow" and I was not the lock owner.

When you click "Run job" it completes without any warning/message. My expectation was that it would warn I was trying to submit a file that is locked to another user. While this would be obvious when submitting a single file, when submitting folders with nested folders, it would not be obvious. Compounding this issue is that the Unlock operation does not cascade through folders.

Adam Stoller

One of the short-comings in a number of workflows is that they fail to expand folders into the full list of constituent files - this can often be fixed either within the WFT (if WFT) or an initial externaltask script (WFT or WFM).

That being said - you didn't indicate what the setting for skiplocked is in that workflow (just because it's OOTB doesn't mean that someone hasn't modified it) - nor have you indicated doing any of the verifications I suggested along with the results.

tbkeith

Not been able to try those suggestions yet (due to permissions) but thank you providing those.

The expanding folder thing does ring a bell, this seems to occur on other commands like Copy To.. and Unlock, they only seem to work for single folder level.