is there a way the DCR can automatically unlock once they are done working on it?

hi ,

we have some of our editors asking about if is there a way the DCR can automatically unlock once they are done working on it?

i wonder what is the best way to go about solving this issue.

1- i know that i can use a workflow.
2- use iwatlock.ipl command but i dont think that our admin will like or allow it using this command.

your thoughts

6.7.1 on windows 03

Find more posts tagged with

Comments

nipper

*NOTE* Just because I am answering your question, it does not imply I think it is a good idea. On the contrary, some user requests are meant to be ignored. This is one of those.

That being said. You can write a simple callserver that runs onsave and runs an unlock. This would be trivial.

LooseCannon

We handle this by registering the "Lock" event using iwat. Note that this will call the registered unlock script EVERY time a "Lock" event is triggered. You probably don't want this behavior for every file in the content store, but rather for a select few.

So, to insure that the unlock script is only executed on the desired files, we first evaluate (regex) the BRANCH or name of the file being locked.

See code below:


#!/p01/app/iw/tsite/iw-home/iw-perl/bin/iwperl -w

use strict;
use TeamSite::Config;


my $iwhome = TeamSite::Config::iwgethome();
my $area = $ARGV[4];
my $file = $ARGV[5];

if ( ($area !~ /\/default\/main\/Intranet\/HighWire\/Sites\/eClips/) &&
     ($area !~ /\/default\/main\/Intranet\/HighWire\/WebHelp/) && 
     ($area !~ /\/default\/main\/Intranet\/HighWire\/Sites\/Graduates/) ||
     ($file =~ /meta-prod\.xml/) ||
     ($file =~ /meta\.xml/) ||
     ($file =~ /categories\.xml/) ) { die }

my $fileVpath = $area . $file;

my $unlock_cmd = "$iwhome/bin/iwunlock $fileVpath";

my $rc = system("$unlock_cmd");

Adam Stoller

Oh - I can't resist:

#!/p01/app/iw/tsite/iw-home/iw-perl/bin/iwperl

use strict;
use warnings; # assumes TS 6.5+
use TeamSite::Config;

my $iwhome = TeamSite::Config::iwgethome(); # *
my $area = $ARGV[4];
my $file = $ARGV[5];

if ( ($area !~ m|/default/main/Intranet/HighWire/Sites/eClips|) &&
     ($area !~ m|/default/main/Intranet/HighWire/WebHelp|) && 
     ($area !~ m|/default/main/Intranet/HighWire/Sites/Graduates|) ||
     ($file =~ /meta-prod\.xml/) ||
     ($file =~ /meta\.xml/) ||
     ($file =~ /categories\.xml/) ) { die }

my $fileVpath = $area . $file;

my $unlock_cmd = "$iwhome/bin/iwunlock $fileVpath";

my $rc = system("$unlock_cmd");

You could collapse the first three regex's into a single one, but I think it's probably better to list them separately here for maintenance reasons.
Also - if the values of $area and $file are exact matches for those paths - I'd recommend using

rather than

(for a trigger script that gets called a lot - these little performance boosts can add up).

* I was going to recommend moving the call to iwgethome() lower down to avoid calling it until you need it - but it turns out that the path to iwhome is hard-coded in the module as part of the installation process and not the result of calling a CLT or reading the contents of a file - so it can be left where it is.

brvhrt

thanks a punch for your replies . that is a very useful script but we are not allowed to use iwat commands at all here as i mentioned in my post.

i actually solved this problem using a workflow.

by the way nipper i know this might be an easy problem , but i just needed other guys thoughts , so don't eat a lot of hot sauce it is not good for your health. lol

thanks again

Adam Stoller

thanks a punch for your replies . that is a very useful script but we are not allowed to use iwat commands at all here as i mentioned in my post.

(Ow - don't punch so hard ;-) Actually - that's not what you said - you said:

2- use iwatlock.ipl command but i dont think that our admin will like or allow it using this command.

which implies you weren't positive they wouldn't - nor whether they understood or could be made to understand the rationale for using it.

However - as you managed to resolve your issues - that's really what matters.

nipper

thanks a punch for your replies . that is a very useful script but we are not allowed to use iwat commands at all here as i mentioned in my post.

i actually solved this problem using a workflow.

by the way nipper i know this might be an easy problem , but i just needed other guys thoughts , so don't eat a lot of hot sauce it is not good for your health. lol

thanks again

You misunderstood my comment, I did not say that because it was an easy fix. Doing this is a bad idea (using iwat or a callserver). Doing it within a workflow is perfectly acceptable and using product the way it was designed. However, bypassing locks completely (which is what a callserver or iwat would accomplish) is a bad idea.

brvhrt

You misunderstood my comment, I did not say that because it was an easy fix. Doing this is a bad idea (using iwat or a callserver). Doing it within a workflow is perfectly acceptable and using product the way it was designed. However, bypassing locks completely (which is what a callserver or iwat would accomplish) is a bad idea.

i think i did misunderstand you nipper. i agree with your comment here.

by the way , thanks for the good spirit and great help specially from you , ISCboris, and goti.

LooseCannon

However, bypassing locks completely (which is what a callserver or iwat would accomplish) is a bad idea.

When the business area has a clear understanding of the locking feature and comes back with requirements to turn it off, then you turn it off.

The file locking feature isn't always required and at times becomes more of an issue than a feature. This is especially true when publishers "edit" a file in order to read it's contents. Or when publishers are in constant communication and do not require the file locking protection.

IMO bypassing locks is neither good or bad, but rather needed or not needed. The deciding factor to enable or disable locks should be based on the requirements coming from the business.