Error: Conflicts prevent operation

I am in the process of migrating from 6.0 to 6.5.

When an approver tries to approve content that has been submitted for approval, he gets an error "Conflicts prevent operation". The system also says that such errors can only be resolved by advanced users.

Any pointers to what could be the problem?

Thanks.

Find more posts tagged with

Comments

Adam Stoller

I am in the process of migrating from 6.0 to 6.5.

When an approver tries to approve content that has been submitted for approval, he gets an error "Conflicts prevent operation". The system also says that such errors can only be resolved by advanced users.

Any pointers to what could be the problem?

Thanks.

Is the file locked by someone else?
If you have more than one workarea on a branch, is the file locked in a different workarea than the one the workflow is associated with?
Is the file up-to-date in the workarea with respect to the version that's in staging?
There are lots of possibilities - but without more information its difficult to tell what's happening - and if you take the time to dig deeper into that information you should be able to figure out what the problem is yourself.

parser

When I submit the file for approval it shows up as locked in the approver's login. But it is locked in the same workarea to which both the author and approver have access. Is this a problem?

Secondly there is no version in staging at all. This is new content.

Thanks.

Adam Stoller

When I submit the file for approval it shows up as locked in the approver's login. But it is locked in the same workarea to which both the author and approver have access. Is this a problem?

Secondly there is no version in staging at all. This is new content.

Thanks.

So there's you - userA - the submitter, and someone else - userB - the reviewer(*) - right?
You submit the file for review, the reviewer is approving the file and when it gets to the submittask in the workflow a conflict is indicated - right?
Are you sure the reviewer (userB) is the present owner of the lock on the file(s) that are to be submitted?
Are you sure the reviewer (userB) is the owner of the submittask which is attempting to perform the actual submission to TeamSite's staging area?

(*contrary to much of Interwoven's documentation, the correct term is "reviewer" not "approver" - approval is one of at least two possible decisions to be made by a reviewer)

parser

The content file gets locked when the userA submits the file to the review process. Therefore I think the lock is held by userA and not userB. This should not matter because userB is the owner of the workarea in which the content is being created. userB and userA belong to the same group at the OS level.

I do not know if userB is the owner of the submittask. How do I determine this?

Thanks.

Adam Stoller

The content file gets locked when the userA submits the file to the review process. Therefore I think the lock is held by userA and not userB. This should not matter because userB is the owner of the workarea in which the content is being created. userB and userA belong to the same group at the OS level.

If userA owns the lock and userB attempts to do something with the file - like submit it - and you don't have TeamSite configured to allow non-lock-owners to submit file (search for "

only_lock_owner_creator_submitsonly_lock_owner_creator_submits

" in the TeamSite Administration Guide for details) - then that might be the source of your problem.

I do not know if userB is the owner of the submittask. How do I determine this?

Look at the workflow - either the WFT or through iwgetwfobj after it's been instantiated, to determine who is the owner of the submittask.

parser

I have already verified that the only_lock_owner_creator_submits parameter has not been set in my iw.cfg file. This would mean that other members of the workarea can submit files as well.

Adam Stoller

I have already verified that the only_lock_owner_creator_submits parameter has not been set in my iw.cfg file. This would mean that other members of the workarea can submit files as well.

Not being set is not necessarily the same thing as being explicitly set to false or no - I would set it explicitly, do an iwreset -a, and then see if the problem persists.

Of course, I'm just guessing that this is the source of the problem - it could be something else entirely - but this should help to eliminate it as a variable.