Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Revision change during Promote / Demote


New member
Hello all,

Although I have hacked my way through a few Intralink Toolkit apps at this point, I was hoping for a little insight from some fellow users on a particular problem I am having...

I am trying to make a trigger that will automatically modify an object's revision if it gets demoted from a 'released' RL. So far, I have the following below. Maybe someone can point out something I'm missing...

First, my trigger is a PrePromote trigger. Additionally, I have a Pro/Intralink Toolkit app that runs too (since the trigger can't check-out, modify rev, etc. - please tell me if I'm wrong here).

My standaolne app works fine... it checks-out a CS object, modifies it's revision by 1, and checks it back in. Running this seperately works perfectly.

At this point, all my trigger does is run my standalone app. This is where I get stuck. Passed to my trigger function in argv is a number of (so far only one) HPDMPARTICIPANTs. From here I can get the PIV of the object being demoted. What I would like, is to have my standalone app run, and then substitute the PIV passed to my trigger with the freshly checked-in PIV from my standalone app... the demotion would continue, but with the newly revised PIV instead of the one originally chosen by the user. Again, this is where I am stuck.

How do I demote the new PIV instead of the original - I want to keep the original right where it is (at the 'released' RL). I have tried playing with the argv pointer to make it point to a different HPDMPARTICIPANT in order to 'fool' Ilink, but I can't seem to get it to work. Is there some other way, or maybe I need to rethink my whole process. Any help would be greatly appreciated...

Thank you,

Even I have the same requirement but not successful in creating this application. This is the first Intralink toolkit application I am writing.

Yes, I have managed to find a good solution to this. It is a post-trigger (post Release Level Management in case there are voting procedures), and it works very well.

I allow the promotion/demotion and then check-out the original, make the revision change, check it back in, and then switch the Release Levels of the last two versions - this makes it so that the latest version is at the target Release Level, and the 2nd latest (the one originally demoted/promoted) is back at the originating Release Level. Of course, this requires locking the items to ensure no changes are made in the process, but the whole process only takes a few seconds... depending on your Intralink performance (network, server speed, etc.)

If you would like some details or would care to discuss, send me a direct email and I can go over it with you. Alternatively, if you wish, I can send you my spec document on it. Let me know.



Can you please send me your spec document.

I am trying to do the same, but get an error message saying that I am trying to call an API function that is not allowed to be called from inside a trigger.

I have created a post RL change trigger and I am trying to checkout the piv to the workspace that i created in the function. The workspace gets created but for checking out the piv the error appears.

That is because you can anly do certain things from within a trigger. Checking out items is not one of them. For this you would need a 'standalone' Intralink Toolkit application.

I have sent you the spec via email. Read it over and let me know if you have any other questions.

Thank you,