Since the default command plugin requires commands to be on the first line of the message body, I'm considering writing a custom plugin. Do command plugins actually affect the message body as it moves from one to the next, or does that happen later in the process?
I'd like to create a plugin that strips everything below a specific line of text ("Please enter your reply above this line"), and that parses the subject line for a specific value (a References value in my use case). But will the standard plugins change the data before it gets to mine? And what is the proper procedure for getting a value from my plugin to the mapping page?
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | add weights to command plugins-1265818-13.patch | 1.95 KB | narayanis |
Comments
Comment #1
danepowell commentedTo answer your question: yes, plugins are called sequentially and do modify the message properties as they are called. I don't think there's currently any way to change the order in which plugins are called.
As to the rest of your post- it sounds like you are trying to take replies and post them as comments... if that's the case, have you tried Mail Comment?
To get data to the mapper, you just need to implement process() and getMappingSources() (see how MailhandlerCommandsFiles.class.php does it- notice how the mapping source key 'attachments' matches the key for the data that gets appended to the message, e.g. $message['attachments'])
Comment #2
narayanis commentedI've used Mailcomment the past for projects; it's good as what it does, but doesn't work in this use case. My goal is to post replies as external notes on a support ticket via node reference. By using nodes instead of comments, I get all the goodness of content type access control and other features that come with being a real node, in order to differentiate external notes and internal-only notes, and view the whole ticket chronologically.
We're building this to move our nonprofit IT helpdesk (http://palmettotechnologyhub.org) from osTicket to something decent, without resorting to a proprietary system. If I can come up with a way to solve this last step, it will make a good install profile or distro; given the existing distro naming conventions, we'd call it something like OpenHelpdesk.
Comment #3
danepowell commentedYou know, thinking about it some more... I'm not sure that there's anything about Mail Comment that actually limits you to creating comments. Have you tried enabling and configuring Mail Comment like normal and simply using the Feeds Node Processor instead of Feeds Comment Processor?
Sounds like a cool project!
Comment #4
narayanis commentedEmails are fired by a rule when a volunteer logs a note on the ticket (an External Note content type). It looks like I can't get the needed info for Mailcomment to link to the original ticket, since they do some kind of linking via custom headers, which Rules doesn't provide access to modify when sending emails.
Are there any simple examples of command plugins documented somewhere? Perhaps something that would show grabbing a single field (fromaddress, subject, whatever), adding it to $message, and providing the key/value to the feeds mapping? If not, I'll see if I can replicate the concept from your note about the file handler, as that seems pretty straightforward.
Comment #5
narayanis commentedI realize it was a bit lazy to ask for the work to be handed to me. I've created a simple command plugin, tested, and it works great! Would this be useful for the docs page? If so, I'll find a good spot for it on there.
Comment #6
danepowell commentedGlad you got it working! Feel free to post it in the documentation as an example of how to implement a custom commands parser.
Comment #7
narayanis commentedI have a final question related to this thread. For my testing I dropped my two custom plugin files into the sites/all/modules/mailhandler/plugins/commands_plugin folder. That's great for now, but when a new release comes out, I don't want my command to be overwritten. Is it possible to store these files elsewhere, that still makes them available to Mailhandler but doesn't live in its folder? Or is there a Mailhandler hook I can use to provide my commands via a custom module?
EDIT: I'm asking this for the purposes of the screencast I'm making that walks a user through creating a plugin, which will be part of the page I'm adding to the documentation.
Comment #8
danepowell commentedCreating your own module is definitely the way to go. I think all you need to do is implement hook_ctools_plugin_directory(), like in mailhandler.module (assuming your command plugin is stored in MailhandlerCommandsHelpdesk.class.php and described in MailhandlerCommandsHelpdesk.inc).
Comment #9
narayanis commentedI'm getting there! I don't see where in the Mailhandler module that it determines the loading order of plugins, and mine is now loading before the standard ones (which means the message hasn't been exploded, parsed, split up, etc). I've set system.weight for my module higher than Mailhandler's, and ran a 'drush cc all' a couple times, so it should be loading afterwards. Any advice on how to set the processing order of command plugins?
Edit: well poo, I just realized you said at the beginning of the issue that plugins are possibly not orderable. I'll check the Ctools queue for info on this.
Comment #10
danepowell commentedYeah, I never really considered how that might be an issue... one possible solution: if you look at the parent commands class, you'll see that there are actually two functions that get called, parse() and then process(). The default commands handler first (in parse()) puts the commands in $this->commands, and then (in process()) assigns individual properties to the message. So if your implementation of process() is getting called before the default command handler, theoretically you could pull all of the info you need out of $this->commands or go fishing in $message.
However, the better solution would really be to be able to control weight. If that's not based on the system table, I have no idea how ctools determines what order plugins are loaded in. If you find out, please do let me know.
Comment #11
narayanis commentedmerlinofchaos said this about plugin weight:
The order plugins are loaded has nothing to do with the order plugins are processed. That's up to the module implementing the plugin type. You will need to ask there, which I guess is the mailhandler module?
http://drupal.org/node/1267338#comment-4937660
Any thoughts of a patch to add a weight property to mailhander plugins? If you think that's interesting, I'm willing to give it a shot. I'm not a PHP expert though, so it may take me a while to figure out.
Comment #12
danepowell commentedWell... that's true and not true. The order that plugins are loaded in doesn't necessarily have anything to do with the order they are processed in. But in Mailhandler's case, the two are one and the same- the parser config form calls ctools_get_plugins, and then during parsing simply loops through the plugins.
At any rate, I'd happily review a patch that implements weights. I'd suggest making them hardcoded (by plugin developers, not user-configurable), and modifying mailhandler_get_plugins to reorder plugins by weight upon load.
Comment #13
narayanis commentedHere goes nothing. My patch works, but it does give a warnings because not all plugin types have weight. I get Warning: array_multisort() [function.array-multisort]: Array sizes are inconsistent.
I've never done a Git patch before, so hopefully I did it correctly.
Comment #14
narayanis commentedComment #15
danepowell commentedI committed #13 with some modifications:
https://drupal.org/commitlog/commit/96/64c9748003f6db46a389a5fe8822ca1f2...
https://drupal.org/commitlog/commit/96/dcb6091a0c81fd56abc7168465faf8f64...