Feature Proposal: The Sandbox Web name should be mapped through a config variable

Motivation

The installers for Extensions assume that all of the standard webs exist and will expand files into these directories, creating them as needed. If a site has renamed their Sandbox web, this can result in invalid configuration.

Description and Documentation

See Tasks.Item8744

• Add an expert config variable SandboxWebName - to the Foswiki.spec - Default = Sandbox
• Add mapping of Sandbox web name to Configure::Util::mapTarget
• Add %SANDBOXWEB% macro to Foswiki.pm

Examples

Impact

Should be minimal impact, and will prevent some installation issues of Extensions that assume the Sandbox web exists.

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: GeorgeClark - 22 Mar 2010

Discussion

Note that we are in practical sense on feature freeze already now. There is less than 14 days till the 31st which is the deadline for checking in the new features.

This proposal may seem simple but it requires actual code for the installers so I would like this feature deferred till after 1.1 is branched off so it enters 2.0

It is not an essential feature that we need here and now. I will not raise concern against the feature. Just say the scope should be 2.0

We branch off end of April according to the ReleasePlan. Then the trunk is open again for features for 2.0

-- KennethLavrsen - 22 Mar 2010

Refactored code for the installers is actually all written and checked in as part of Tasks:Item8640, along with a complete set of unit tests. So adding a Sandbox map to the mapped Webnames and paths was very straightforward and I have it ready to commit, along with a unit test. There are no code changes required to any installers. The manifest is automatically mapped against alternate Web, Topic and path names by the package installer.

See http://trac.foswiki.org/changeset/6610

In the original code, extender.pl and EXTEND.pm each did their own mapping - in a different way, and had issues. This completes a refactoring to a common utility used by both routines - but in the process I found the Sandbox hole.

I can hold off the checkin, but I believe this is fairly low risk.

-- GeorgeClark - 22 Mar 2010

Accepted by 14-day rule but for 2.0.

Wait checking in on trunk till after we branch off Release01x01

-- KennethLavrsen - 08 Apr 2010

This ended up partially merged into 1.1.4. and completed in upcoming 1.1.5.

-- GeorgeClark - 12 Feb 2012