Priority: Urgent
Current State: Closed
Released In: 1.1.6
Target Release: patch
Applies To: Engine
Component: FoswikiForm
Branches: Release01x01 trunk
When a Foswiki::Form is constructed it is cached in the session object's forms hash ....
even though it only has been build up half way ... as a result of an access control exception.
Also: it might get cached or looked up under the wrong key.
--
MichaelDaum - 14 Jun 2012
Re-opened to fix test breakage
Re-titled for release notes
--
PaulHarvey - 16 Jun 2012
Breaks more unit tests:
# Following broken by Foswikirev:14981 - Item11945 - MichaelDaum
#../bin/TestRunner.pl -clean HTMLValidationTests::verify_switchboard_function_edit_default HTMLValidationTests::verify_switchboard_function_edit_pattern HTMLValidationTests::verify_switchboard_function_edit_plain HTMLValidationTests::verify_switchboard_function_edit_print
--
GeorgeClark - 23 Aug 2012
Not related to this checkin and fixed as part of
Item12079. This was an error in
TwistyPlugin.
--
MichaelDaum - 19 Sep 2012
this has caused
Item12228, which I'm investigating for 1.1.6
changes like this should never be made without unit tests that show the problem they are fixing. Specifically, the partially evaluated form was cached to prevent infinite recursion - and yes, that needs a unit test badly.
--
SvenDowideit - 07 Nov 2012
There've been a couple of serious programming errors fixed in
distro:2b941c92afa3. Some of them are pretty obvious, like using normalizeWebTopicName
before caching a form obj under a key constructed on the web and topic names...
--
MichaelDaum - 07 Nov 2012