Ticket #5676 (closed Bug: fixed)
looking at a folderish DynamicFTI object when its FTI has been deleted from portal_types causes obscure and hard to debug error (TypeError: iteration over non-sequence)
|Reported by:||rochael||Owned by:||alecm|
- go to portal_types in ZMI
- clone Folder (ATFolder) into, say AltFolder
- go to the Plone ui and create an !ATFolder instance (say aFolder)
- remove the AltFolder FTI from portal_types
- visit aFolder directly (i.e. with no method after it in the URL)
Traceback (innermost last): Module ZPublisher.Publish, line 105, in publish Module Products.Challenger.challenge, line 27, in traverse Module Products.Challenger.wrap, line 20, in call Module ZPublisher.BaseRequest, line 308, in traverse Module urllib, line 1153, in quote Module urllib, line 1123, in _fast_quote TypeError: iteration over non-sequence
This is what happens: ATContentTypes/content/base.py:ATCTFolderFolderMixin.__browser_default__() blindly returs whatever CMFPLone/PloneTool.py:PloneTool.browserDefault() returns and PloneTool.browserDefault() blindly returns whatever obj.getDefaultPage() returns if obj is an IBrowserDefault. However IBrowserDefault.getDefaultPage() explicitly claims it can return None which neither of first two methods above are prepared to handle. ZPublisher can't be expected to handle a path like [None] :-)
This bug happens as of Plone 2.1.3 and Plone 2.5.
I consider it moderately serious as it is easy to cause (an accidentaly removed portal_type or an uninstalled product) and very hard to diagnose (generic TypeError with very small traceback and no indication of the causes).
I don't expect content to function properly when its FTI has been deleted, but I expect this condition to be easy to detect and to understand.
I don't have a preference over whether the above methods inside Plone should raise an error themselves or return a valid fallback result (with sufficient logging at WARN or ERROR level), as long as the error messages are sufficiently clear as to what is happening.