8 Mar
2010
8 Mar
'10
6:40 p.m.
On Sat, Mar 6, 2010 at 11:55 AM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
I thought that was de rigueur in Xwiki. If you
didn't import as superadmin
into a multiwiki, how could you get working any documents containing scripts
that require programming rights? If you don't import this way,
for example, you won't be able to control the openoffice importer (last I
checked, a lot has changed since too) or other such prog-right-needing
script-documents.
Correction: I got my terminology wrong here. By "superadmin" I meant the
root-wiki administrator, e.g.
xwiki:Admin who is granted programming rights and therefore can give those
rights to scripts s/he writes. (I forgot about the "superadmin" mentioned in
xwiki.cfg, which is basically a back-door xwiki:Admin that
is disabled by default. What I meant above was that for correct funtioning
of a multi-wiki setup requires importing as xwiki:Admin (root wiki owner, or
superadmin) where that user is granted programming rights. Other than
exceptions, one wouldn't usually grant programming rights to each subwiki
administrator, so I'm not sure how these admins would be able to
successfully import their own Xwiki Xar's. Wouldn't granting programming
rights to a subwiki owner essentially give them programmatic access to the
entire wiki farm (through groovy, for example).
My own terminology issues aside, however, issues still remain w/r/t
installing docs that need prog-rights out of the Xar. I guess the regression
just made it more noticeable... I still think it would be a good solution to
have a "template xar" (not in the database) where the xwiki WAR or
standalone distro would contain it's corresponding xar, exploded into
individual xml files. A new directory xwiki/resources/xar would contain the
exploded xar contents, and for certain Spaces, such as "Xwiki" and
"Main",
if the database could not find the given document in that space, the
xwiki/resources/xar (template directory) would be consulted and that
document would be returned.
This would mean a fully functioning wiki would be available on initial
deployment, without forcing an import step or needing to populate the
database. Updating a multiwiki wouldn't require the corresponding release's
Xar to be loaded into each subwiki, ( http://twitter.com/myxwiki ) and all
the potential breakage that can entail as subwiki owner's forget to maintain
and self-upgrade their Xar's... Each subwiki's document database would be a
"shadow overlay" ontop of the template xar. Modifications in the local wiki
database, e.g. of Main/WebHome would be retained across upgrades. Subwiki
owners could be automatically notified when a local document, shadowing a
document in the template wiki, may need merging due to a new source version
in the template wiki (on each upgrade).
-- Niels
http://nielsmayer