Ticket #5676 (closed Bug: fixed)

Opened 8 years ago

Last modified 5 years ago

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
Priority: major Milestone: 2.1.4
Component: General Version:
Keywords: Cc:

Description

Reproduction steps:

  • 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)

Resulting Error:

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.

Change History

comment:1 Changed 8 years ago by alecm

  • Status changed from new to closed
  • Resolution set to fixed

(In [10365]) Made PloneTool.browserDefault check for a result of None from getLayout and raise a sensible error. Generally this means that the FTI is missing or otherwise incorrect. Fixes #5676

comment:2 Changed 8 years ago by hannosch

  • Milestone changed from 2.1.x to 2.1.4

comment:3 Changed 5 years ago by hannosch

  • Component changed from Content Types to Infrastructure

comment:4 Changed 22 months ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.