Item12912: Add plugin component to BugsContrib

Plugin implements two functions:

• A SaveHandler that will set the Topic permissions based upon the task priority and state:
  • A new "Security" priority should restrict view of any task not in the closed state.
  • The topic should be viewable only by the original creator, and the security group.

• A RestHandler implements a transaction that can be used by a github webhook to post commit id's into tasks.

-- GeorgeClark - 23 May 2014

Setting ACLs based on formfield values is doable using SetVariablePlugin like this in a view template:

%SETVAR{field="Security" matches="on" var="ALLOWTOPICVIEW" type="Set" value="SecurityGroup"}%
%UNSETVAR{field="Security" matches="off" var="ALLOWTOPICVIEW"}%

Implementing a service handler can be done using a {Switchboard} entry and a script to call it.

-- MichaelDaum - 24 May 2014

Is there any reason not to use a rest handler? I often hear that adding switchboard scripts is not the recommended way to go now that the rest function is more usable. The Github "WebHook" issues a POST that we can configure. It's either form data, or a json body with the metadata about each push. The body of the POST is signed using a HMAC hash with a shared secret. The rest handler looks simple enough to do. It just needs the 1.2 features so we can run it without authentication. Or we remove the rest handler from auth scripts on our 1.1.9 foswiki.org system.

Regarding the ACL, I considered that. But I wanted to get a bit more thorough and make sure that the original creator remained in the ACL. Also if the task is set "Waiting for" someone, they should also be able to view it,

For now, all I've written is a rest stub that dumps the body of the json request using Data::Dumper.

-- GeorgeClark - 24 May 2014

A rest handler exposes the feature to the web as well. If you only need a scripting access as used in a cron job, a switchboard entry plus a tools/foobar script is probably easier and more secure.

Yea, if you need more func a custom impl to maintain ACLs is probably preferable. You could of course add the ReportedBy content to the %SETVAR value. Same for WaitingFor. %SETVAR is just another macro that you can combine with others.

%SETVAR{field="Security" matches="on" var="ALLOWTOPICVIEW" type="Set" value="SecurityGroup, %FORMFIELD{"ReportedBy"}%"}%

-- MichaelDaum - 24 May 2014

Replied on IRC, but the hook needs to be web accessible. Github will POST to a configured URL with either a webform or JSON encoded details about each push to the repo.

My initial thoughts are to have the webhook configured for each repo that tasks will track. When a push to that repo is made, foswiki will record the repo identity and commit hash into the tasks in the commit message. We can also use this to kick off a git pull of a local git repo on the foswiki server.

-- GeorgeClark - 24 May 2014

Commenting is disabled while not logged in