We use TS 6.7.1 SP1 on Linux. We use submit locking. When users create or modify files they are locked in a workarea. The files don't exist in any other workarea. No user other than the person who owns the lock is able to edit these files. When a user tries to edit a file that they don't own the lock on the message, "File is already locked by USER in this workarea.".This is not how submit locking should behave - correct? Are other having this problem?
Yeah...correct!!Submit Locking is the least restrictive followed by Optional Write Lock and Mandatory Write Lock.But it also depends of the user's role. You should check the user's role that might have different locking role on a given branch.HTH,
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta name="ProgId" content="Word.Document" /><meta name="Generator" content="Microsoft Word 11" /><meta name="Originator" content="Microsoft Word 11" /> &amp;amp;lt;!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} span.EmailStyle15 {mso-style-typeersonal; mso-style-noshow:yes; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Arial; mso-ascii-font-family:Arial; mso-hansi-font-family:Arial; mso-bidi-font-family:Arial; color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {pageection1;} --&amp;amp;gt; Submit. Enables users to ensure that their changes are submitted before others can submit theirs. When a file is locked, users in different workareas can edit their version of the file, but cannot submit it until the owner of the lock submits his work or manually releases the lock. This option is selected by default, and is well-suited for environments where parallel development is desired.
We are using submit locking everywhere. Below is the definition of submit locking. It doesn't say anything about not being able edit a file that is locked in the same workarea.Is there a more complete definition or explanation of the correct behavior anywhere.
Actually, if you're sharing a workarea (which I believe to be a good model) - this is, I believe, the correct behavior.Think of the scenarios: Multiple Workareas User-A edits File-X in Workarea-AUser-B attempts to edit File-X in Workarea-BUser-B is told the file is locked, but has the option to continue editing anywayIf User-B decided to continue, they will have to deal with merging their changes after User-A submits their changesSingle Workarea User-A edits File-XUser-B attempts to edit File-XIf User-B is allowed to continue, who knows what the end-result of File-X is?Ergo, User-B is prevented from editing File-X in the same workarea as User-A until the lock is removed (usually be submitting)Makes sense to me.
I didn't see this response before I responded to the other. This makes sense to me too although it doesn't aggree explanations from IWOV from people who should be "in the know". I can imagin having to manage one workara per user. I would take you up on your offer to call IWOV but every day I come to realize that they have way too many problems to fix in their products to worry about the "little things". Don't get me wrong I still thing IWOV has the best enterprise CMS going.
