Discussion for FogBugz Plugin developers
We recently switched to FB7, largely to get the benefit of the new plugins interface. I've started developing some of our in-house project management tools as plugins rather than separate apps which use the Web API or a DB connection to FB.
One of the essential tasks of our time reporting application is to send regular emails containing a copy of the time report that the plugin generates for you. I read in a thread here that FogBugz doesn't allow you to access the Mail Queue that FB uses, and also read a vague account in the documentation of what permissions might be available to the managed environment that the plugin code runs in.
My questions are these:
A) Is there a description somewhere of the exact PermissionsSet that FB runs the plugin code in? It looks like there are no SMTP permissions allowed at all (including those on port 25), but I couldn't find a definitive source describing what permissions were allowed.
B) Barring a clean way to access an SMTP client, has anyone implemented a clean workaround for SMTP outgoing service in one of their plugins? I was planning on running a separate HTTP webservice on the same server which takes in POST's from FB and translates them into SMTP outgoing messages, but was wondering if anyone else had already implemented such a tool or had a better workaround.
Thursday, September 24, 2009
The permission set is extremely minimal, something like
SecurityPermission: Assertion | Execution | ControlEvidence | RemotingConfiguration
So basically the only thing you can do directly in a plugin is hit a URL; everything else has to go through the API.
Currently there isn't an API allowing plugins to send email, though this is high on our list of priorities for enhancements to the API.
Your plan to http POST email messages to another service sounds like it would work to me, but to my knowledge nobody has done it yet.
Thanks for the heads up on the permissions. For future reference, it'd be nice for plugin devs to be able to see that permissions set definitively.
Excited for the outgoing mail API, I'll be on the lookout for plugin development updates. Until then, for posterity's sake, bridging the SMTP request to a Web Server wasn't too difficult, and I'd encourage anyone who needs email before it's part of the API to give it a shot.
Friday, September 25, 2009
This topic is archived. No further replies will be accepted.Other recent topics