Item11945: Log when missing/invalid formfield types are used, make dataform object cache more robust
Current State: Closed
Released In: 1.1.6
Target Release: patch
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.
- 14 Jun 2012
Re-opened to fix test breakage
Re-titled for release notes
- 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
- 23 Aug 2012
Not related to this checkin and fixed as part of Item12079
. This was an error in TwistyPlugin
- 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.
- 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...
- 07 Nov 2012