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

I hate the new locking behaviour

System

I expected that I would like the lock not applying until the user edits the file, but that's not precisely what happens. In the case of templating, it turns out the lock isn't applied until the DCR is saved. My expectation would have been that some sort of AJAX-esque server call would happen in the background to apply the lock as soon as the form was modified (and released if cancelled). That, I could live with.

However, the bigger annoyance is that if the user edits the form entry by clicking edit on the generated file, the lock is still only applied to the DCR - not the generated file. That's leading to lots of cases where users are clicking edit on a file that appears to be unlocked, only to be presented with a lock warning because of the DCR.

I haven't delved deeply into the documentation yet. Is anyone aware of any configuration options to change the behaviour, other than setting it back to the old locking behaviour? That's seeming like the best bet at the moment.

Find more posts tagged with

Comments

Migrateduser

Am I correct that what I've described above is the behaviour that is ostensibly documented by this very cryptic known issue in the SP1 release notes?

[indent][left]45094

A user modifying a data record from the generated file may not have correct

file locking through the entire process.
[/left]
[/indent]

nipper

I expected that I would like the lock not applying until the user edits the file, but that's not precisely what happens. In the case of templating, it turns out the lock isn't applied until the DCR is saved. My expectation would have been that some sort of AJAX-esque server call would happen in the background to apply the lock as soon as the form was modified (and released if cancelled). That, I could live with.

However, the bigger annoyance is that if the user edits the form entry by clicking edit on the generated file, the lock is still only applied to the DCR - not the generated file. That's leading to lots of cases where users are clicking edit on a file that appears to be unlocked, only to be presented with a lock warning because of the DCR.

I haven't delved deeply into the documentation yet. Is anyone aware of any configuration options to change the behaviour, other than setting it back to the old locking behaviour? That's seeming like the best bet at the moment.

I have not dug into the locking very deeply, however my understanding from Sunil was that this would be done like a trigger, upon the modification of the file (thus the 1st save event). The AJAX idea is fine for templating (and one could even implement this via FormAPI, setting the lock on init and releasing it on save), but iwll not work for editing a non-template file.

The fact that the lock is not applied to a generated file to be would be a bug, if (and only if) the lock is not applied if/when the user regenerates the file.

Just my 2 cents.

Andy

drew1

... very cryptic known issue in the SP1 release notes?

45094 A user modifying a data record from the generated file may not have correct file locking through the entire process

Bug 45094 was first filed in 2003, against TS6.0. Reading the bug description, it sounds just like your complaint, but it's not new behavior, been around since 6.0 introduced Content Center.

Migrateduser

The fact that the lock is not applied to a generated file to be would be a bug, if (and only if) the lock is not applied if/when the user regenerates the file.

Just my 2 cents.

The lock is applied when the file is generated (since at that point it becomes a modified file). However, the problem that crops up is in the case where the user edits the DCR, but doesn't generate a page with it right away or submit it to a workflow that will auto-generate the page. I would agree that the behaviour is not a bug per se, but I would lump into the category that I call "broken as designed". Any behaviour that requires a receptionist to understand how the system works well enough that they understand what's going on when they click edit on an unlocked file and get an error that says "this file is already locked" is not a happy thing.

Actually, I guess one could argue that there is a bug here - the error dialog should be more verbose and explain that it's the DCR that's locked.

Migrateduser

I agree...I really dislike this locking behavior too. This was definitely introduced with SP1, and will cause no end to helpdesk calls once we roll it out to the masses.

What about following:

The readme for Patch #1 for 6.7.1 SP1 states:

* Bug ID 74518 -- In TS 6.7.1 SP1 a file gets locked only when the file''s contents are changed and saved. In earlier versions the file would be locked as soon as it was selected for editing. The fix is to provide a config option to be able to revert locking behavior to pre-TS6.7.1 SP1.

Platform(s): Generic

I can't find any reference to WHERE the above mentioned "config option" exists. Has anyone else seen such an animal?

Thanks,

Migrateduser

Solution!

A little bird passed along the undocumented configuration setting for this. Put the following into your application_custom.xml (and perform a make_toolkit.ipl per the UICG instructions). It worked like a charm for us:


<applications>

  <!--
    File locking behavior:
      "true" =  Lock a file ONLY when a modification is detected.
                WARNING: For generated pages, this will ONLY lock the
                         DCR when a change occurs.  The generated page
                         will remain unlocked until it is regenerated,
                         which can cause confusion.
      "false" = Lock a file as soon as the user clicks on "Edit".
  -->
<default-param id="iw.common.edit.lock_on_modification" value="false"/>


</applications>

Thanks to the "little bird" for this tremendously helpful bit of information!

patrickm

We are using both 6.5 and 6.7.1 SP1. We've only see this new locking behaviour in 6.7.1 SP1. Is this ui_toolkit workarea officially supported as I don't want to move to to 6.7.2 to find it's not working again.

I was going to have an onsave event fire when a form is loaded to ensure the file is always locked.

Does anyone know if making the ui_toolkit change also affects the locking behaviour on downloaded files, i.e. downloading a file doesn't lock it, only modifying it does etc.

Pat

patrickm

Replying to my own post, yes I see this is now documented in ref_teamsite_application. Good Good. But still not sure if this is limited to DCR and/or all files.

ccprofessional

I have overcome this locking issue to some extent by adding an external task that unlocks the dcrs along with the html file in the Submit WF.

I also modified the Submit wf so that it always unlocks the file being submitted.

Lil Birdie's tip is helpful though. Kudos to the lil bird Smiley Happy

smenon

The Lil Birdies tip is a supported configuration change. The fact that the documentation did not explicitly call it out is a documentation issue and I'll send a note to the doc team about it..

This configuration file should have modified only the behavior of files being uploaded and downloaded via Launchpad. I dont believe that we changed the behavior of FormsPub with this configuration change.

Funnily enough, we implemented this change because we had a number of teamsite admins complain that they were stuck with trying to unlock files for users who downloaded files for review purposes and never modified them. TeamSite used to lock the files even if that scenario and the reviewers had no privileges to unlock files and so they had to call their admins to do it for them.

If you still think that the changed behavior might be useful if we addressed some of your concerns, then let us know and we can file defects against the new behavior and address those in the next release.

thanks

Adam Stoller

The Lil Birdies tip is a supported configuration change. The fact that the documentation did not explicitly call it out is a documentation issue and I'll send a note to the doc team about it..

This configuration file should have modified only the behavior of files being uploaded and downloaded via Launchpad. I dont believe that we changed the behavior of FormsPub with this configuration change.

Funnily enough, we implemented this change because we had a number of teamsite admins complain that they were stuck with trying to unlock files for users who downloaded files for review purposes and never modified them. TeamSite used to lock the files even if that scenario and the reviewers had no privileges to unlock files and so they had to call their admins to do it for them.

If you still think that the changed behavior might be useful if we addressed some of your concerns, then let us know and we can file defects against the new behavior and address those in the next release.

thanks

I think it's a case of "can't please everyone" - but that Interwoven has, on a few occasions at least, made changes that either weren't backwards-compatible, or that were - but required obscure or obscurely documented changes to achieve the pre-existing behavior -- instead of providing well documented procedures for achieving the new behavior.

patrickm

This configuration file should have modified only the behavior of files being uploaded and downloaded via Launchpad. I dont believe that we changed the behavior of FormsPub with this configuration change.

Hey Sunil,

was aware of the launchpad change and very much so welcome this, but it's also the same for formspub. Opening a form does not lock it unless an explicit save unless this customisation is made. We've opted to resolve our own issues via this customisation as it's easily supported as opposed to a formApi onload save event. Would be ideal if the uitoolkit supported modification lock controls for both launchpad and formsPub going forward.

P

sandy123

Hi All,

It might be late to post reply on this thread but since I am facing almost similar problem, i thought i can post my query on this thread.

I am using Teamsite 6.7.1 sp1 Windows 2003 SE
The problem is when users are editing their generated files attached to their job, they get error message as " The file ..... is locked by you in the workarea ..... ".

I was wondering that the users should be able to edit the files which are locked by themselves.

Does anybody seen this error before ?

Any pointers will help.

Thanks,
Sandeep

nipper

That can happen if the file is locked in a different workarea, which is a different issue than what Rob was talking about.

sandy123

Thanks for the reply Nipper.

But this error says that file is locked by YOU and I have only one workarea per branch or sub branch.
Even the file is locked by myself it should not say that File is locked. Temasite does allow to edit the files locked by ourselves.

nipper

that is strange, TS should always allow you to edit a file that is locked by you (in the same workarea). What happens if you find the file and view properties ? Anything strange ? Unlock it and lock it again, still fail ?

sandy123

It happens intermittently.. there is nothing weired on the Properties of files.

This problem happens very rarely for some users.. not sure what is the root cause of it. If i unlock it and lock it again, it will not happen.

Did any one faced this issue before ?

Migrateduser

has this feature been added to 6.72 sp1 or sp2? users are complaining and they want the old behaviour (lock file on launching edit) restored - thanks

namithapai

Hi All,

I know this is an old thread, but we have upgraded from old old old v 5.5 to 6.7.1 SP1 and the new locking mechanism is causing a lot of grief.

We have the remote setup on launchpad and work directly off the Y drive. I have updated application_custom.xml with


default-param id="iw.common.edit.submit_lock_model.lock_on_edit" value="true"

but that seems to work on Ccstd only.

Does anybody have a solution to make lock on edit work in CCPro?