doc/todo/web_reversion.mdwn

   1 Goal: Web interface to allow reverting of changes.
   2
   3 Interface:
   4
   5 At least at first, it will be exposed via the recentchanges
   6 page, with revert icons next to each change. We may want a dynamic
   7 per-page interface that goes back more than 100 changes later.
   8
   9 Limiting assumptions:
  10
  11 * No support for resolving conflicts in reverts; such a revert would just
  12   fail and not happen.
  13 * No support for reset-to-this-point; initially the interface would only
  14   revert a single commit, and if a bunch needed to go, the user would have
  15   to drive that one at a time.
  16
  17 Implementation plan:
  18
  19 * `rcs_revert` hook that takes a revision to revert.
  20 * CGI: `do=revert&rev=foo`
  21 * recentchanges plugin adds above to recentchanges page
  22 * prompt user to confirm (to avoid spiders doing reverts),
  23   check that user is allowed to make the change, commit reversion,
  24   and refresh site.
  25
  26 Peter Gammie has done an initial implementation of the above.
  27 [[!template id=gitbranch branch=peteg/master author="[[peteg]]"]]
  28
  29 > Review: --[[Joey]]
  30 >
  31 > The revert commit will not currently say what web user did the revert.
  32 > This could be fixed by doing a --no-commit revert first and then using
  33 > rcs_commit_staged.
  34 >
  35 > So I see one thing I completly forgot about is `check_canedit`. Avoiding users
  36 > using reverting to make changes they would normally not be allowed to do is
  37 > tricky. I guess that a easy first pass would be to only let admins do it.
  38 > That would be enough to get the feature out there..
  39 >
  40 > I'm thinking about having a `rcs_preprevert`. It would take a rev and look
  41 > at what changes reverting it would entail, and return the same data
  42 > structure that `rcs_recieve` does. This could be done by using `git revert
  43 > --no-commit`, and then examining the changes, and then `git reset` to drop
  44 > them.
  45 >
  46 > Then the code that is currently in IkiWiki/Receive.pm, that calls
  47 > `check_canedit` and `check_canremove` to test the change, can be
  48 > straightforwardly refactored out, and used for checking reverts too.
  49 >
  50 > (The data from `rcs_preprevert` could also be used for a confirmation
  51 > prompt -- it doesn't currently include enough info for diffs, but at
  52 > least could have a list of changed files.)
  53 >
  54 > Note that it's possible for a git repo to have commits that modify wiki
  55 > files in a subdir, and code files elsewhere. `rcs_preprevert` should
  56 > detect changes outside the wiki dir, and fail, like `rcs_receive` does.