On Sat, Mar 6, 2010 at 11:55 AM, Niels Mayer <[email protected]> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
