Yes! I would love to see some code for this.
Do you have an available fork on Github? If not, could you create a gist (http://gist.github.com) showing the functionality you mentioned above.

I tried checking into github and it returned me a 403. I have it in a branch I can commit if you like?

I have added the code I ahve changed to the gist - not sure I've done it right, but I can updated if required - got to rush out atm .

Can you paste a link to the gist you created?

I have commited the code to the following fork:

https://github.com/timbrown5/parameterized-remote-trigger-plugin

Could you please submit a Pull Request on GitHub for the changes you want to see merged back into the plugin and released.

Code changed in jenkins
User: tim.brown5
Path:
src/main/java/org/jenkinsci/plugins/ParameterizedRemoteTrigger/RemoteBuildConfiguration.java
src/main/resources/org/jenkinsci/plugins/ParameterizedRemoteTrigger/RemoteBuildConfiguration/config.jelly
http://jenkins-ci.org/commit/parameterized-remote-trigger-plugin/d32c69d0033aefda382c55e9394ebab8d1da10ae
Log:
Created new fork and commit mesasges to local branch to it:

commit dab42e57ce1a1b9ca1b2f8251f2d89127cd69d04
Author: tim.brown5 <tim.brown5@hp.com>
Date: Mon Jan 27 17:40:43 2014 +0000

Added the ability to specify a PollInterval value - to stop the plugin spamming the logs. Also Fixed some typos in the field titles in config.jelly.

commit 81558c521857bea4c0d0c6c951b759f8e28bdab4
Author: brownt <tim.brown5@hp.com>
Date: Thu Jan 23 15:10:27 2014 +0000

Changed the tile of check box from 'Block execution of remote builds while other builds are running.' to 'Block triggering of remote builds while other builds are running.' to better describe what it does.

commit b78f021cd0b7ddccd3e84fc2fc2758fd8d92a092
Author: brownt <tim.brown5@hp.com>
Date: Thu Jan 23 15:08:25 2014 +0000

Added to checkBoxes to allow toggling of the following fnctionality:

• Block triggering of remote builds while other builds are running.
• Block build step until remove build is complete.

The first gets round an issue where multiple jobs are all trying to launch jobs at once and filling up the build queue on the remote server. This causes an issues because when jobs are in the queue you cannot get their status. Another way to solve this would be to assume that the job is in the build queue and 'qait' until you can access the job's build page.

The second allows the user to make the local job block until the remote job has finished (and so set the status of the local job to that of the remote job). This is a fix for issue JENKINS-20828. If you are using this feature it's best to also use the feature above, as otherwise your builds will fail when remote builds you have triggered are waiting in the build queue.

This works best if only one job is triggering builds on a remote job. This is because is two builds trigger a job at the same time it is possible for them both to think next next build is the one they triggered... A solution to this could be comparing the parameters??

commit 22983d13fc8a1b63b3686facfcd10d31d51f074a
Author: brownt <tim.brown5@hp.com>
Date: Wed Jan 22 15:37:41 2014 +0000

Added 'fix' as describe in: https://issues.jenkins-ci.org/browse/JENKINS-20828

Feel free to ignore this branch if you are working on this yourself. Also free free to use this code as you see fit.

"I have created a workaround/fix for this issue. My code does the following:
get the nextBuildNumber from the job
trigger the build
check that next build number has increased by one - this means we know that the only job triggered is the one we triggers, otherwise we error
then wait for the job with the build number above to start
then wait for the job with the build number above to finish and return the result.

I can share the code if you are interested
*I also split out the HTTPRequest code into a method, so you can call different URLs with different methods (to simplify the communication with the remote server).

I do agree however, it would be a lot easier if the trigger call returned the build number of the job it's just triggered. Could raise an issue to see if this can be done?
"

There are issues with this 'fix' when multiplem jobs are triggering the same remote job:
1. It blocks all the time - would probably need to add a toggle button to turn the blocking on/off
2. It returns failure if it tries to check on a remote job and the job has not started yet - as it goes to the job
3. If two jobs are launched at the same time they can both pickup the same job ID - so they

• These issues shouldn't affect quiet environments, but ones that kickoff a lot of the same jobs in a few seconds will see issues. There also might be issues if the remote job takes a long time. I cannot think of a way to get round these issues at the moment...

To test this I setup multiple local jobs all triggering one remote job. When running them all one at a time there were no issues, but running them all at once there were issues.

This is implemented in version 2.1, which has been published.
The changes should hit the update center with in the next 6 hours.

Marking Tim as the assignee because he's the one that implemented this feature

hi canuck1987 & morficus thank you for the feature.

i'm curious to know if the same idea be applied for post-build -> trigger job?

details: https://issues.jenkins-ci.org/browse/JENKINS-44264