96 lines
3.7 KiB
Markdown
96 lines
3.7 KiB
Markdown
[[!tag wishlist]]
|
|
|
|
[[!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 perhaps 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, but you might also want to set up
|
|
> separate users who have fewer limits on what they can push. OTOH, I'm not
|
|
> sure how to get this info in an ikiwiki wrapper.. the real and effective
|
|
> gid are already trampled. So maybe leave this out and always treat it as
|
|
> an anonymous edit from a non-logged in user?
|
|
>
|
|
> 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]]
|