Subscription portlet breaks batch workflow state change

Bug #475771 reported by Lennart Regebro
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Singing & Dancing
Confirmed
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Daniel Nouri (daniel.nouri) wrote :

Patches welcome. :-)

Revision history for this message
Maurits van Rees (maurits-vanrees) wrote :

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
Revision history for this message
Maurits van Rees (maurits-vanrees) wrote :

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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.