No Event trigger for Remove lock (break lock notification

[ssaul]

Hi,

we have set up a script that is triggered by the Member.unlockRevision.post event.

It should send a mail if a user's lock is broken by admin.

This works for "downgrade lock" from the sandbox and member history view, but not for the "Member/Locks/Find all locks for a certain user" view - the script is simply not triggered (we have no log output).

So this is only triggered when downgrading an exclusive lock - all other actions have to be done via "Member/Locks/Find all locks for a certain user" view.

We are on Integrity 10.5.

Is this known, corrected in a later version and is there a workaround?

[awalsh]

The default breakLockNotification.js script does not write anything to the server.log file.

I've tested with 10.5 and a modified script to write to the log. My script ran on the Member.unlockRevision.post event for both Downgrade Lock and Remove Lock. 

Can you double check your global.events file and try adding a couple lines in the breakLockNotification.js file to output to the server.log.  E.g. :

environmentBean.setMessageCategory("GENERAL");
environmentBean.print(environmentBean.getEventName(), 0 );
environmentBean.print("Lock by user " + lockOwner + " is " + actionString + " by user " + userBean.getUsername(), 0); 

If it's still not working, I suggest opening a ticket with support.

[ssaul]

We are using a modified breakLockNotification.js script, too. It writes to a separate logfile.

During downgrade, we get a log output.

During "Remove My lock" for our own user, we get a log output.

Direct "Remove lock" is not possible (MKS124814: Cannot show view information: MKS125606: "Remove Lock" command can only be called from the "Find Locks" view. Use "Downgrade lock" or "Remove My Lock" instead.).

We first have to search locks for the user and then "remove lock" in the result window.

When doing "remove lock" or "downgrade lock" or "Remove my lock" from the result window, we get no log output -> trigger does not seem to be called.

The global event correctly contains

Member.unlockRevision.post=breakLockNotification_adapted.js

So it seems that the problem is with the "Find locks" result window which does not trigger the "Member.unlockRevision.post" event.

[awalsh]

That's odd. I'm doing the same thing you are (testing with 10.5 and removing or downgrading the lock from the Find Locks window) and the event is definitely being triggered in my test environment.

Can you attach your javascript for me to test with?  Do you have any hotfixes installed? 

[ssaul]

Really strange.

There are no hotfixes installed.

I sent you the script via personal message.

[awalsh]

I noticed you have with opened a case with Nicolae in Technical Support. If you would prefer working through the case, I've let Nicolae know that I've been working with you here on the issue. 

I've tested with your script with no problems. I commented out the mail lines and hard-coded the myFilename variable rather than using the env.properties file, but neither of those changes makes a difference in whether the script runs.  

Maybe the problem is with the events files. Do you have the script set on the global.events file or a project events file? What do you have set for the mksis.si.triggers.resolution and mksis.si.triggers.resolutionOrder properties (you can see these in the Admin GUI  under Configuration Management > Configuration > Properties.

DEBUG logging doesn't help unfortunately, but TRIGGER logging will show the context resolved if there's more than one *.events file, and whether a script is being added to run. For example:

2018-02-26 13:26:28,639 INFO [mksis.IntegrityServer] TRIGGER(5): TriggerGroupsManager.resolveEvent: context: UID: /ALM105/project.pj Context Name: project: adding script TriggerScriptCollection, size : 1

2018-02-26 13:26:43,727 INFO [mksis.IntegrityServer] TRIGGER(5): TriggerGroupsManager.resolveEvent: global context: adding script: TriggerScriptCollection, size : 1

[ssaul]

Yes, I have opened a case as you suggested in the second post.

The script is setup via global.events file.

There is no project.events file that has an entry for the Member.unlockRevision.post event.

The mksis.si.triggers.resolution and mksis.si.triggers.resolutionOrder properties are on default (chained and global;project).

I have set up trigger logging via

si logging --on --category=TRIGGER

and will send you the server.log.

[ssaul]

Now I have tested with different projects and on different projects, the trigger works.

The first tested project (the one with non-working trigger) is somehow strange.

The Server location is

MKS_Project_Name         = d:/MKS_Archive/mks_firsttest/ordner2/ordner3/project.pj

but the member location is

MKS_Archive_Name         = d:/MKS_Archive/mks_firsttest/unterordner/ordner2/ordner3/MyFile.h

Maybe that confuses the trigger manager somehow?

[kthierer]

I dont know know if this could help you with your script

but if subprojects are moved

the Repository Location

and Project Name will differ.

d:\PtcTest\sub1_moved\sub2\sub3\sub4\sub5>si projectinfo
Project Name: d:/Clients/PtcTest/sub1_moved/project.pj
Repository Location: d:/Clients/PtcTest/sub1/project.pj
...

HTH Juergen

[ssaul]

Juergen,

that's true, but since it is a global trigger, that should not make any difference, right?

The first thing the script does is output to a logfile, so even if something went wrong inside the script, I would see this output.

[kthierer]

If I do projectinfo on the repository location I get the following

d:\PtcTest\sub1_moved\sub2\sub3\sub4\sub5>si projectinfo -P d:/Clients/PtcTest/sub1/project.pj
*** The project d:/Clients/PtcTest/sub1/project.pj could not be located on the server PTC:7001: MKS125211: The project file d:/Clients/PtcTest/sub1/project.pj is not registered with the current server.

I dont know much about server side triggers, but if they use rather Repository Location or Archive Name

internally

...???

[ssaul]

We'll see what awalsh can say about this.

[awalsh]

Triggers for shared and moved subproject follow their current project configuration, including any scripts defined on the original location up until the shared point.

For example:

/Project1
     /subA
          /subB
               /subC
/Project2
     /sharedsubB ==> shared from /Project/subA/subB/project.pj
          /subC

/Project3
     /sharedsubC ==> shared from /Project/subA/subB/subC/project.pj

Project specific event triggers are defined for /Project1/project.pj, /Project2/project.pj, and /Project1/subA/subB/project.pj and default properties set for event triggers.

Then:
for /Project1/subA/subB, triggers for Project1 and subB will run
for /Project2/sharedsubB, or /Project2/sharedsubB/subC triggers for Project2 and subB will run
for Project3/sharedsubC, nothing runs.

Caveat: a project specific events file only loads if the project is currently registered. So in the case of a moved subproject, the events defined for the original location work only until a server restart. If an events file isn't loaded, you will see ERRORs in the server.log file:

2018-03-01 09:11:29,428 ERROR [mksis.IntegrityServer] * * * * ERROR * * * * (5): Delayed transition to Operating: Could not determine trigger context. Reason: MKS125211: The project file /locktest/sub1/project.pj is not registered with the current server.
2018-03-01 09:11:29,428 ERROR [mksis.IntegrityServer] * * * * ERROR * * * * (5): Delayed transition to Operating: Failed to load trigger group. The project : /locktest/sub1/project.pj could not be found in the registered projects list. Check your specification of this project.

[awalsh]

Since you have it on the global.events, it shouldn't matter where the archive is located.  

I'll set up a test today with moved members and subprojects.

Could you attach a support package to the TS case?

[ssaul]

Okay, done.

[awalsh]

It's a defect with a moved subprojects. There's a DEBUG message in the server.log file that the project is not registered and even though the lock is removed, no events are firing.

I also found that in this case, using "downgrade lock" removed the lock entirely.

I've reproduced in 11.2 as well. I'll post an SPR for this.

[awalsh · Accepted solution]

Posted SPR 7315020 

I've attached the article to your support case. 

[ssaul]

Great, thanks!