add todo page for web reversion, with code review of patch

diff --git a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn
index dc2b7ca4a0fad4d35d702677c6b1fab2b2fac16d..4998c1a7575767b3131ac7f014c67705b049cb7c 100644 (file)
--- a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn
+++ b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn
@@ -36,6 +36,5 @@ Puzzled a bit :-/
 
 ---
 
 
 ---
 

-There is some work in progress on this by Peter Gammie. --[[Joey]]
-
-[[!template id=gitbranch branch=peteg/master author="[[peteg]]"]]
+Perer Gammie and I are working on reversion over at [[todo/web_reversion]].
+--[[Joey]] 

diff --git a/doc/todo/web_reversion.mdwn b/doc/todo/web_reversion.mdwn
new file mode 100644 (file)
index 0000000..50cb13f
--- /dev/null
+++ b/doc/todo/web_reversion.mdwn
@@ -0,0 +1,56 @@
+Goal: Web interface to allow reverting of changes.
+
+Interface: 
+
+At least at first, it will be exposed via the recentchanges
+page, with revert icons next to each change. We may want a dynamic 
+per-page interface that goes back more than 100 changes later.
+
+Limiting assumptions:
+
+* No support for resolving conflicts in reverts; such a revert would just
+  fail and not happen.
+* No support for reset-to-this-point; initially the interface would only
+  revert a single commit, and if a bunch needed to go, the user would have
+  to drive that one at a time.
+
+Implementation plan: 
+
+* `rcs_revert` hook that takes a revision to revert.
+* CGI: `do=revert&rev=foo`
+* recentchanges plugin adds above to recentchanges page
+* prompt user to confirm (to avoid spiders doing reverts),
+  check that user is allowed to make the change, commit reversion,
+  and refresh site.
+
+Peter Gammie has done an initial implementation of the above.
+[[!template id=gitbranch branch=peteg/master author="[[peteg]]"]]
+
+> Review: --[[Joey]] 
+> 
+> The revert commit will not currently say what web user did the revert.
+> This could be fixed by doing a --no-commit revert first and then using
+> rcs_commit_staged.
+> 
+> So I see one thing I completly forgot about is `check_canedit`. Avoiding users
+> using reverting to make changes they would normally not be allowed to do is
+> tricky. I guess that a easy first pass would be to only let admins do it.
+> That would be enough to get the feature out there..
+> 
+> I'm thinking about having a `rcs_preprevert`. It would take a rev and look
+> at what changes reverting it would entail, and return the same data
+> structure that `rcs_recieve` does. This could be done by using `git revert
+> --no-commit`, and then examining the changes, and then `git reset` to drop
+> them.
+> 
+> Then the code that is currently in IkiWiki/Receive.pm, that calls
+> `check_canedit` and `check_canremove` to test the change, can be
+> straightforwardly refactored out, and used for checking reverts too.
+> 
+> (The data from `rcs_preprevert` could also be used for a confirmation
+> prompt -- it doesn't currently include enough info for diffs, but at
+> least could have a list of changed files.)
+> 
+> Note that it's possible for a git repo to have commits that modify wiki
+> files in a subdir, and code files elsewhere. `rcs_preprevert` should
+> detect changes outside the wiki dir, and fail, like `rcs_receive` does.