109 lines
4.2 KiB
Markdown
109 lines
4.2 KiB
Markdown
[[!tag wishlist done]]
|
||
|
||
[[!toc ]]
|
||
|
||
Summary
|
||
=======
|
||
|
||
Allow a user to apply an arbitrary diff, in order to modify a given
|
||
page (or, even better, a given set of pages).
|
||
|
||
Rationale
|
||
=========
|
||
|
||
To edit intensively an ikiwiki-powered website can quickly get
|
||
annoying for anybody meeting enough of the following conditions:
|
||
|
||
* living mainly offline
|
||
* having no commit access to the RCS backing up the site (BTW, please
|
||
note I can send my ssh public key to anyone who asks for, free of
|
||
charges)
|
||
* hating web-browsers and despising textareas
|
||
* loving in his/her own preferred `$EDITOR`
|
||
|
||
... and when one gathers all of these defaults, she/he is on her/his
|
||
way to get mad. Soon.
|
||
|
||
Before it's too late, some dareful ones dream of the following
|
||
playflow:
|
||
|
||
1. Go online.
|
||
1. Update local working copy.
|
||
1. Go offline.
|
||
1. `$EDITOR` : write, report, answer, propose
|
||
1. Go online.
|
||
1. Update local working copy (and optionally fix conflicts between
|
||
local changes and remote ones).
|
||
1. Generate a diff.
|
||
1. Use a web-browser to paste the diffs (or better, upload them into
|
||
a form) somewhere on the wiki, and click "Apply".
|
||
1. git pull (to reflect locally the fact that the diff has been
|
||
applied to the remote repo)
|
||
1. Go offline.
|
||
|
||
(This is for sure a bit theoretical: the ones who dream of this would
|
||
actually insert various steps about branching, merging and rebasing
|
||
random stuff.)
|
||
|
||
Design
|
||
======
|
||
|
||
This has to be thought very carefully, to avoid one to apply diffs to
|
||
pages he/she is not allowed to edit. Restricting a given diff to
|
||
modify only *one* page may be easier.
|
||
|
||
Implementation
|
||
==============
|
||
|
||
Also see [[joey]]'s idea on [[users/xma/discussion]], to allow (filtered) anonymous push to this wiki's repository.
|
||
|
||
> Ideally the filtering should apply the same constraints on what's pushed
|
||
> as are applied to web edits. So locked pages can't be changed, etc.
|
||
>
|
||
> That could be accomplished by making the git pre-receive hook be a
|
||
> ikiwiki wrapper. A new `git_receive_wrapper` config setting could cause
|
||
> the wrapper to be generated, with `$config{receive}` set to true.
|
||
>
|
||
> When run that way, ikiwiki would call `rcs_receive`. In the case of git,
|
||
> that would look at the received changes as fed into the hook on stdin,
|
||
> and use `parse_diff_tree` to get a list of the files changed. Then it
|
||
> could determine if the changes were allowed.
|
||
>
|
||
> To do that, it should first look at what unix user received the
|
||
> commit. That could be mapped directly to an ikiwiki user. This would
|
||
> typically be an unprivelidged user (that was set up just to allow
|
||
> anonymous pushes), but you might also want to set up
|
||
> separate users who have fewer limits on what they can push. And, of
|
||
> course, pushes from the main user, who owns the wiki, would not be
|
||
> checked at all. So, let's say `$config{usermap}` is a hash, something
|
||
> like `{usera => "wikiusera", userb => "wikiuserb"}`, and pushes from
|
||
> users not in the hash are not checked.
|
||
>
|
||
> Then it seems like it would want to call `check_canedit` to test if an
|
||
> edit to each changed page is allowed. Might also want to call
|
||
> `check_canattach` and `check_canremove` if the attach and remove plugins
|
||
> are enabled. All three expect to be passed a CGI and a CGI::Session
|
||
> object, which is a bit problimatic here. So dummy the objects up? (To call
|
||
> `check_canattach` the changed attachment would need to be extracted to a
|
||
> temp file for it to check..)
|
||
>
|
||
> If a change is disallowed, it would print out what was disallowed, and
|
||
> exit nonzero. I think that git then discards the pushed objects (or maybe
|
||
> they remain in the database until `git-gc` .. if so, that could be used
|
||
> to DOS by uploading junk, so need to check this point).
|
||
>
|
||
> Also, I've not verified that the objects have been recieved already when
|
||
> whe pre-receive hook is called. Although the docs seem to say that is the
|
||
> case. --[[Joey]]
|
||
|
||
>> Update: The git pre-receive hook stuff is written, and seems to work.
|
||
>> I think it makes more sense than using diffs, and so think this todo
|
||
>> could probably be closed.
|
||
>> --[[Joey]]
|
||
|
||
>>> I agree, closing this. I really prefer this solution to the one I was
|
||
>>> initially proposing.
|
||
>>> Is this pre-receive hook already enabled on ikiwiki.info?
|
||
>>> If not, do you plan to enable it at some point?
|
||
>>> --[[intrigeri]]
|