I'm looking at the URLTrigger plugin page and wondering how it would be used. Probably because I don't really understand exactly what it does. What are some potential uses?
|
7
2
|
|
|||
|
|
|
2
|
URLTrigger allows for a sort of event-driven behavior. Although you can use the FogBugz API to retrieve basically all of the same information which URLTrigger can provide you, your external app would be polling for information from FogBugz. URLTrigger allows you to essentially subscribe to FogBugz events, and thus your external app can have an event-driven architecture rather than a polling-based one. Further, on the Poor-Man's Plugin note, there already exist many applications which you can interact with merely by firing GET requests at them. URLTrigger can talk to a text messaging service to allow FogBugz to send text messages to a project lead whenever a priority-1 case is opened in a given project, for instance. |
|||
|
|
|
1
|
You can use it as sort of a generic plug-in so that you can do work outside FogBugz, and in the language you want. Here's a recent example: Customer wanted to automatically set their engineers' chat status lines based on what case they were working on currently. We helped them figure out that the TimeInterval event could be the trigger here. When working on changed, the URL Trigger plug-in would fire off a GET to their script, which was written in some other language (Ruby, Python, PHP, whatever). The query string would provide the person ID and the bug ID. The script would use the Jabber protocol to set that user's status line. Pretty inventive. Not sure if this is typical, but it seems like a valid and useful usage scenario. You can also use the URL Trigger plug-in as sort of a poor man's FogBugz plug-in. You mark certain events to kick off scripts that then use the FogBugz API to make changes in FogBugz. This allows you to use the language you want to parse the URL and kick off a FogBugz API call, and you don't need to develop your own plug-in. |
||
|
|
