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

Resolve conflicts

Annad

Hi,
Is there a way that I can resolve the conflicts in a submit workflow using a command line tool or a cgi script.

I don't want the user to go to the task list and resolve the conflicts but an external task to be executed which does it with a CLT.

thanks.
Anna

Find more posts tagged with

Comments

akshathp

in that case how do you plan to handle the merging of documents with selections of accept new change or keep original options? Or, is it that you want workflow external task to force the acceptance to new changes in the document by overwriting original?

Akshat Pramod Sharma

Annad

As you said I want the workflow external task to force the acceptance to new changes in the document by overwriting original.
What do I do for that?

Thanks.

Adam Stoller

You make sure that the submittask is defined with override="t" so that you will always override discrepancies between the current file being submitted and the current version in the staging area.

I think this is a very questionable way to do things - but if this is what you want, that should do the trick and there should be no conflict resolution tasks created.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Annad

Hi thanks for the suggestion.

I tried that and don't really know how to test it. I have the specifed workflow on the production server, where the users are using it for a lot of files to submit to staging. However, when I tried with some files where the staging area is empty and submit brand new files, I don't get the 'Resolve Conflict'.

When does this actually happen. Does it have to be over a certain number of files for the conflict to occur.

Thanks.

Anna

Adam Stoller

Conflicts generally occur when you have multiple workareas on a given branch.

Say you have two workareas (WA_A, WA_B) on a branch (B), and you're looking at a file (F) sitting in the top of the workarea.

You start with:
/default/main/B/WORKAREA/WA_A/F -- version 1
/default/main/B/WORKAREA/WA_B/F -- version 1

A user goes in and edits and submits the file in WA_A - you now have:
/default/main/B/WORKAREA/WA_A/F -- version 2
/default/main/B/WORKAREA/WA_B/F -- version 1

If a user then goes and edits the file in WA_B - you'll have:
/default/main/B/WORKAREA/WA_A/F -- version 2
/default/main/B/WORKAREA/WA_B/F -- version 1+

If that user tries to submit the file from WA_B - a conflict occurs because F/1+ is not based on the latest version in staging (F/2)

In the above scenario - the user should have gotten a warning when they went to edit F -- version 1 when version 2 was already created - and at that point in time should have been given the option to Get Latest for that file first -- if they had done so, no conflict would have occurred because it would have gone from:
/default/main/B/WORKAREA/WA_B/F -- version 1
to:
/default/main/B/WORKAREA/WA_B/F -- version 2
to:
/default/main/B/WORKAREA/WA_B/F -- version 2+

and then submitting 2+ over version 2 (in staging) will not be in conflict.

However, it is possible through a number of ways for the versioning to get out of sync between multiple workareas without being quite as simple as the above -- in general though the second user should get a warning about editing a file that is already locked by another user in another workarea -- unless of course any of the editing takes place via the file system interface, in which case there is no lock placed on the file and the two workareas can become out of sync more easily.

Does that help clarify things for you?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Annad

Thanks for the clarification.

I will try to recreate the conflicts and play with it.

Tx.
Anna.