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 Conflict

aces

We are running on Win2K with TS 5.5.2. There is a workflow call Submit and Deploy. Administrator use this workflow to manually submit development files to production so it can be version. The only problem is sometime when the admin submit files for developers, there would be a conflict and the file didn't get moved to production. There is no message that would let the admin knows that there is a conflict until the developers test it and find out there changes didn't get moved. Why would the conflict occur? How do I resolve the conflict? Is there a popup or something that would let the admin knows that there is a conflict? Thanks in advance.

Edited by aces on 10/12/04 08:58 AM (server time).

Find more posts tagged with

Comments

nipper

You need to view tasks. You shoudl see it there. This is a pain, but then the possibility of stepping on
someone elses code is worse.

You should consider putting update tasks in your Workflow since this often happens when
people do not do get latest.

HTH

me

Dwayne

Whichever user owns the submittask (usually the workarea owner, but not always - depends on how the workflow was coded) would have an entry in their TeamSite ToDo list which shows the conflict. This gives that user the ability to resolve the conflict

--

Current project: TS 5.5.2/6.1 W2K

Migrateduser

There is supposedly a feature request out there in the abyss somewhere that will allow a submittask to have some kind of default behavior to execute an externaltask via a successor that would kick off in the event of a conflict. The fact that IW hasn't seen fit to implement this yet kind of sucks. No one ever looks at their task list to see if maybe a conflict occurs. They only know that their files aren't in production and then they call me and I have to deal with it. If I was a contractor, I wouldn't care so much....

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

We were just discussing this very issue today. We are hoping to have most of our users do most of their work via url commands in emails, but if a conflict occurs, I think we'll be suffering.

Dwayne

I haven't actually implemented this at any of my clients, but one of the things I've thought about doing is to create a dummy task in parallel with the submit task. Set the timeout of the dummy task to be something like 10 minutes, which should, in normal cases, be more than enough time for the submit task to complete. The dummy task then transitions to an external task to send an email

When the submittask completes, it deactivates the dummy task, preventing the email from being sent out.

--

Current project: TS 5.5.2/6.1 W2K

Migrateduser

That's a good workaround, and I think Nipper has done something similar. It sure would be nice if IW spent a little time on workflow - they haven't done anything substantial (other than the wftask task), in at least 5 years - probably more. Of course there was that WFB thing that is so loved by all...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

Still it is much better to avoid the conflicts than work around them.

From my investigation almost all the conflicts I see are due to Get Latest usage, or lack there
of.

By automatically updating the WAs when new changes are submitted, you will avoid these
issues.

Andy

Dwayne

I've also noticed in iwwf.dtd for 6.1, there's been a change to <submittask>. The <successorset> is deprecated in favor of using a <success> and <failure> construct. However, I haven't been able to find any documentation on what this <failure> successor is for. It could be that this is to handle conflicts, but they just haven't documented it yet.

<updatetask> also has this element.

--

Current project: TS 5.5.2/6.1 W2K

Migrateduser

Ahhh, who needs documentation when we can all find stuff in DTDs and other files in the depths of the TeamSite filesystem? Everything IW creates is self-documenting anyway, isn't it? Sometimes I hate this stuff...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

The use of the success and failure cases is documented in the 6.0 wofkflow guides. Not only the DTD. The succ and failure states are listed in the 6.0 docs. A simple hack used in the past was to timeout the task to an external task that did the force submit ignoring the conflict.

DTD - <!ELEMENT submittask (description?, areavpath, successorset|(success,failure?),
PDF - <!ELEMENT submittask (description?,areavpath,successorset,timeout?,

Other commands that have these states are
<!ELEMENT updatetask (description?, areavpath, successorset|(success,failure?),
<!ELEMENT locktask (description?, areavpath, success, failure,

<!ELEMENT success (succ+)>
<!ELEMENT failure (succ+)>

<!ATTLIST failure firsttimeonly (t|f) "f">

Migrateduser

The only thing I see in the WF Developer's Guide 6.0 that refers to a <success> or <failure> option is on pg. 146. It refers only to the locktask. Show me where it documents it referring to the submittask and updatetask.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

wrappedlegend.zip

Migrateduser

and what is firsttimeonly?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

You could at least admit it's not in the WF Developer's Guide for submittask and updatetask. As a representative of Interwoven you should post a response and either cite the page/section it's in or say that you were mistaken. Don't just disappear.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

well Smitty, I guess you chased off another one.

How to win friends and influence people Smitty style. Asking for a page in the manual to read is just soooo unreasonable.

me

Migrateduser

Man... is that what people get like when they "make ruby"? I can understanding being so bitter from using crappy content management software (as I've done since '98). Oh... okay, I guess I answered my own question.

Instead, I guess I should be more **** off than I am.

Dave

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K

nipper

>Man... is that what people get like when they "make ruby"? I can understanding being so bitter from using crappy content management
>software (as I've done since '98). Oh... okay, I guess I answered my own question.

No, I think that is Smitty fresh out of the box. You should see him in a bad mood. Think Mount St. Helens erpution.....

Migrateduser

The dude referenced documentation that wasn't there, and I'm not sure I consider a snippet frpm a DTD as manual-worthy documentation anyway. It would be nice to see examples and explanations for what specific events cause a submittask or updatetask to go down the <success> path or the <failure> path. Interwoven just doesn't get documentation at all. And some guy comes in here and pompously cites wrong info. I call BS on that every time...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

You don't want to be around when my magma starts flowing. Just ask my wife...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

>You don't want to be around when my magma starts flowing. Just ask my wife...

You mean the saint ?

Saint Mrs. Smitty, I am certain she has earned that.

Migrateduser

I was actually using a crude bathroom reference...but she's a saint for putting up with that, too...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com