Can WikiForms trigger an external process.

[David.Byrne@…]

I was curious as to whether the WikiForms plugin could trigger an external process when a form is updated. We are looking at using WikiForms to create a sign-off form that will be attached to milestones. Using the permissions, we can limit the users that can sign-off. What I would like to have happen is that when the final sign-off occurs, an external process would be triggered that would queue a buildbot build (actually the process is a migration). I can create the external script for handling the build, but I wasn't sure how to trigger it. Would this be an extension to WikiForms, or would I look at changes in the underlying table that holds the WikiForms values?

[asic_druide]

...could be done. Effort seems, on the first glance, limited. The security aspects are not yet clear to me. The triggered command or script will run as the same user on the same server as the trac/apache instance. I personally (as the admin) would not want/allow/accept this.

[David.Byrne@…]

But wouldn't it depend on how you set up the external process? If it was done outside of the plugin directly, couldn't it run as any user? I guess what I'm thinking is that an external process could be run on a semi-regular basis looking for updates to the wikiforms_fields table to find specific fields that were updated_on within a given range. If it finds those fields, it could trigger a specific event. For my sign-off situation, I am putting permissions around the wiki update access as well as the form fields in the wiki forms. I may have to use something like the PrivateWikiPlugin where I can restrict access to the Forms pages. It could be nice to have the process run directly from the WikiForms code, but I can see the security issue there -- especially if access is given to a large group to update/create wiki pages.

[asic_druide]

One extreme is directly running a script/program on the server.

The other extreme is an external application looking into the tables (db-backend dependent)

An intermediate way would be to allow the plug-in to write to a certain file/socket and another server process (running as another user) listening on the file/socket and running the defined (and not web accessible) actions. Drawback is that administration is than not purely web based anymore and that somebody has to start the external-actions server.

[asic_druide]

...after reading a little more about sockets in python they seem to me to be the right answer to the problem. The server process actually executing the external actions might run on another machine as another user listing on a certain port for commands send by the WikiFormsPlugin.

For the WikiFormsPlugin this means that the form-element-name and value and server-url, port and command to be send needs to be configurable, right?

[anonymous]

+1

In this case, if the action was "send the form via xmlrpc to...", then the OP could listen for that in buildbot and initiate the process from there.

Other users could do similar actions - the "modern" equivalent of the old form-to-email perl cgi scripts.

[Steffen Hoffmann]

As this has been requested for TracFormsPlugin in #8715 I came here to read previous discussions.

I wonder why nobody thought about an IFormChangeListener interface. Actually this is already halfway implemented for TracFormsPlugin these days. Only I saw no real application other than change announcements via AnnouncerPlugin so I didn't push it much for now.

It can't be hard to be done for WikiFormsPlugin as well. And I guess this is the best way to just scan changes when they happen and act, if the expected thing just has happened. Polling and XML-RPC might be too much, but I may have overlooked something, so think it twice and discuss, please.

[asic_druide]

trigger via mail implemented in r10651