Cross Client Task Locks

[former_member221827]

Hi all,

I'll preface this with the fact that I'm an abap developer and not too familiar with basis processes.

My company is in the process of upgrading from NW 7.02 to 7.40.  When creating development tasks we create them in D20 client 10.  Previously we were then able to go to D20 client 30 and edit the same object there after the object was locked to the task in the other client.  This behavior is no longer being allowed and an error of "Object is Locked in inconsistent task" is popped up when trying.

It's a small team and our Basis admins are uncertain on the issue.  Can anyone point me in the right direction for what would need to be changed to regain the previous behavior?

Thanks much,

-Chris

[Sandra_Rossi]

Based on the correspoding error message number (TK582), I found this note, maybe it corrects your problem

2164918 - Missing client check in change interface

Symptom

The change interface checks whether an object is already locked in another request. In this case, the object can be changed only if the user has or can create a task in this request.

A prerequisite for this is that the user is in the same client as the locking request.

However, if the object is already locked in a task of the user in a different client, the client is not checked and changes are still possible.

Reason and Prerequisites

There is a program error.

The check of the client is executed only if a new task is created or selected. However, if the object is already in a task of the user, these steps are not required and the check does not take place.

The error can occur only if the same user exists in several clients.

Solution

Implement the attached correction instructions or import the relevant Support Package.

[former_member221827]

If I'm understanding that note correctly it sounds as if the behavior we had before was incorrect and that note would change it to how our system behaves currently.

[former_member221827]

After some digging, this note was applied to our system.  Removing the note changed the behavior back to what we expected.  Thanks a ton Sandra.