2008-10-24 18:50:05 +02:00
|
|
|
|
[[!tag wishlist done]]
|
2008-07-15 13:22:55 +02:00
|
|
|
|
|
|
|
|
|
[[!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
|
|
|
|
|
==============
|
2008-10-21 00:40:30 +02:00
|
|
|
|
|
|
|
|
|
Also see [[joey]]'s idea on [[users/xma/discussion]], to allow (filtered) anonymous push to this wiki's repository.
|
2008-10-21 02:16:30 +02:00
|
|
|
|
|
|
|
|
|
> 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.
|
|
|
|
|
>
|
2008-10-21 18:18:22 +02:00
|
|
|
|
> To do that, it should first look at what unix user received the
|
2008-10-21 02:16:30 +02:00
|
|
|
|
> commit. That could be mapped directly to an ikiwiki user. This would
|
2008-10-21 18:18:22 +02:00
|
|
|
|
> 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.
|
2008-10-21 02:16:30 +02:00
|
|
|
|
>
|
|
|
|
|
> 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]]
|
2008-10-24 00:16:55 +02:00
|
|
|
|
|
|
|
|
|
>> 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]]
|
2008-10-24 18:50:05 +02:00
|
|
|
|
|
|
|
|
|
>>> 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]]
|
2008-10-24 23:16:52 +02:00
|
|
|
|
|
|
|
|
|
>>>> [[news/git_push_to_this_wiki]] gave me the answer. Well done! --[[intrigeri]]
|