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

iwdiff

aces

In my template, it allows the user to upload files to the server. When the user edit the datacapture and submit to production, the uploaded file get submit again because the path is in the datacapture. How do I compare the difference between WORKAREAand STAGING file so when they do an edit on the template, the file do not deploy to production again?

Find more posts tagged with

Comments

jbonifaci

Didn't you answer your own question in your subject? iwdiff --help

Also, files will only be submitted to staging if they have changed and (depending on how you have it configured) OD will only deploy files that have their timestamp changed or filesize changed. See the OD manual for further details.

XMLIN Message ID error.png

aces

I'm not really sure how you would implement this. Is this done on the dcrCreation or the template? Plus, how do I use iwdiff?

How to send response to SOAP request.png

jbonifaci

Well, from the sounds of it, you have a dcr that has a link to other files and those files are somehow being deployed, correct? This is definitely not built in. Something like this is a customization, and how to implement this depends on that customization.

iwdiff --help

But the simple answer is:

iwdiff workareapath stagingpath

nipper

Don't think you will be able to do that programmatically. I tried but failed.

Since it is a DCR, you can grab the DCR, and then grab the previous version (I assume this is after a submit) like this:
my $cmd = "iwattrib ".$iwmount.$workarea."/".$file." prevversion";
@rc=`$cmd`;
my $oid=@rc[0];
chomp ($oid);
my $newcmd = "iwcat -o ".$oid." ".$iwmount.$workarea."/".$file;
foreach $line (@newrc) {
$DCR.=$line;
}
my $oldparser = TeamSite: Smiley Very Happy

CRparser->new(); # create a DCRparser
my $oldrootnode = $oldparser->parse($DCR); # get root DCRnode object

Then compare appropriate DCR fields.

HTH

Andy
@newrc = `$newcmd`;

aces

Where would you put this is? Datacapture form?

nipper

What I sent was perl that will allow you to diff fields of the current and previous versions of a DCR. How you want to use it is up to you. I use this in the deployment piece of a WF, after the DCR has been sent to staging, I look at a couple fields to determine if other systems need to be updated.

Where would you WANT to use it ?

Andy

aces

I want to clear the value of the upload fields(replicant) in the DCR after deployment or after the fields are attached to the workflow. This way, if the user edit the page, those files will not be upload again.

nipper

Then you will need to put code like this in a perl script and run that in an external task before the submit task. You will also need to code to blank those fields, not too tough.

Andy

aces

Do you have examples or any one have done this before?

Adam Stoller

I want to clear the value of the upload fields(replicant) in the DCR after deployment or after the [files] are attached to the workflow. This way, if the user edit the page, those files will not be upload[ed] again.

There are two things here:

http://www.quotient-inc.com

aces

"because the file should only get deployed when it has been modified - the value within the DCR probably shouldn't have any effect on the file being deployed (what happens when the file is re-edited? Does the user have to manually change that field again in order for it to be deployed?)."

Once the file is re-edited and user did not manually delete the value in the field (upload), those files (image) will be upload again. I don't want the image to be deployed again. For example, if the user is making changes to the image and is not read to deploy, since the path exist in the template, the unfinished work will be deployed.

Windows_Server_2008_x64_Standard-2015-08-13-11-10-31.png

Adam Stoller

Well it sounds like whatever you do, you need a script front-end to the deployment process which will find only the files with metadata set to indicate that they *should* be deployed, modify the metadata, re-submit the files, and then deploy those files to thier intended target.

I won't pretend to understand all the rationale behind this design, and therefore won't bother to offer any suggestions for implementing it beyond the above. The rest is in your hands.

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

aces

It seems like my explanation is not clear. Here’s an example of a user case:

DCR-A has an upload field (replicate)
User fills out the field with ABC.gif and submits it for approval
Job is approved by manager
ABC.gif and A file is deploy to production
User goes back to DCR and makes changes to the title field and didn’t touch the upload field
User send it for approval
Job is approved by manager
ABC.gif and A file is deploy to production again

Issue:
User did not want ABC.gif file to be deploy since it is already deployed to production

nipper

Much better,

We do something very similar to this.

Here is how we do it. First we have a java callout in the DCR that will upload the image and drop it into a directory for the user. This simplifies it for the end user. When an upload is done, we increment a hidden field for revision level.

When the WF runs, in the beginning it reads the revison level of the image, from the DCR, it gets the image name, and the revision level of the DCR from the Staging area. This allows us to compare them, if different, then we add the image to the workflow.

You can also just check to see if the image is marked as modified & include that if it is modified.

HTH

ANdy

Adam Stoller

That's definitely clearer. Presumably you're using a filelist deployment (otherwise the files wouldn't be re-deployed unless changed). Presumably also, you are parsing the DCR somewhere, in order to obtain the file names to put into the filelist - yes?
In the code that parses the DCR - you want to check *both* the filename entry (ABC.gif) *and* the upload checkbox associated with that entry, and only add that entry to the filelist iff the checkbox is checked.

Does that help?

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