Subscription portlet breaks batch workflow state change

Reported by Lennart Regebro on 2009-11-05
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Singing & Dancing
Undecided
Unassigned

Bug Description

If you go to a folder_contents page, check a content and click "Change state", you'll get a traversal error. This is because having the Subscription portlet in the site will change the request.form['paths'] variable from a list of strings to a list of unicode struings, and unrestrictedTraverse can't handle unicode.

The change happens somewhere within collective.dancing.browser.portlets.channelsubscribe.Renderer.setup_form()
A quick test seems to confirm that doing setup_form not in the __init__ but in the render of the portlet improves the situation. Possibly that's not a complete fix, but it's a start. Best of all would of course be if setup_form keeps it's fingers away from request.form. It seems like something there goes through everything in request.form and validates it or something. It's all very strange.

Daniel Nouri (daniel.nouri) wrote :

Hint: It's Products.Five.browser.decode.processInputs that's changing request.form (via plone.z3cform.z2.switch_on). I think what you're seeing is a general problem with all views or portlets that use processInputs. processInputs will change items in the form to unicode so that form libraries like formlib and z3c.form can work on request.form.

Lennart Regebro (regebro-gmail) wrote :

processInputs should in that case only be called when the z3c.form form has been submitted, and only modify the form entries in the form.

Daniel Nouri (daniel.nouri) wrote :

Patches welcome. :-)

Lennert, your suggestion to move the setup_form from the init to to render method fixes the problem. I do not see it introducing other problems. And the tests still pass. So I committed it on trunk in http://dev.plone.org/collective/changeset/118701

Changed in singing-dancing:
status: New → Fix Committed
Changed in singing-dancing:
status: Fix Committed → Fix Released

Errrr.... the applied patch fixes the problem when the portlet is added in the right column. When the portlet is added in the left column, the error surfaces again...?!??!?

BTW, this bug was marked by me as 'fix released'. This apparently means that the bug is not listed anywhere anymore on launchpad. You can view it, but only if you know the direct url. Does anyone know if there is a setting for this in launchpad? Meanwhile, I will reopen the bug.

Changed in singing-dancing:
status: Fix Released → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers