|Version 6 (modified by stevegt, 10 years ago) (diff)|
Wiki Workflow Proposal
News Flash: WikiWorkflowPatch is checked into SVN now. The interface may not be stable yet; some of the following questions still apply.
As wiki SPAM gets worse, as people start using trac for more critical projects, and as I develop the plugin that implements my evil master plan for world domination, there's going to need to be a lightweight, trac-ish way of allowing plugins to do page edit workflow. I have that need right now. I want to tackle this, I plan to post the result on trac-hacks.org, but before I spend a lot of time going down a development path, I think I should get some advice as to which path I should take; it's looking more and more like trac itself will need to be patched, and I'd prefer to do this in a way that the patch will likely be accepted into mainstream.
There appear to be (at least) two parts to this problem: (1) The default viewable version of a wiki page needs to be selectable via an extension point, not hardcoded as "highest version number", and (2) the version of the page which a user edits when they hit "Edit This Page" needs to be the version they are looking at, rather than always the latest.
I see two choices here:
- Patch WikiPage, WikiModule, and WikiSystem to add an IWikiWorkflowController extension point; this extension point includes a get_default_version() function, and disables edit collision detection (as a first approximation) so edits can be based on back-level revisions. I've actually already written this patch, as well as a sample workflow controller, and both work great. All of this was surprisingly simple, thanks to trac's clean code and the component api.
- Don't patch the code; just have my own plugin do the job via overriding and subclassing WikiModule, reassigning the 'WikiPage' symbol at runtime, and/or other guerilla tactics. I don't want to resort to this.
More about edits and collision detection... In WikiModule, right now an edit is hardcoded as "latest version" in process_request. But if an IWikiWorkflowController is loaded, then you'd actually want the "Edit This Page" button to edit the version you're looking at, or maybe the currently elected version, not the latest version. Right now I just punt and, if workflow is on, then edit the version the user's looking at. This required disabling collision detection, because trac's default collision detection asserts that req.args.get('version') == "current latest version". A better alternative might be to add a hidden form variable, say, 'latest_version', and yell if req.args.get('latest_version') != "current latest version".
Does anyone have any preferences or thoughts about any of these alternatives? Feel free to edit this page...