How Could the Response be None?

[href]

We sometimes have the problem that adding a new comment won't redirect to the conversation. The reason seems to be this code:

Products.Ploneboard/src/Products/Ploneboard/skins/ploneboard_scripts/comment_redirect_to_conversation.py

Line 30 in d6accf8

if response is not None:

I figure this is a long shot, but does anyone have any clue why the response could ever be None? Everything else seems to work fine. Even if the response is None, the comment is actually added.

Maybe there's a more robust way of accessing the response?

Anyway, if anyone has any clues I'll return the favor with a brew or pizza ;)

[sureshvv]

Looks bogus to me too.

Whole stuff can be replaced with:

context.REQUEST.RESPONSE.redirect(...)

IIRC, that is how it used to be when I last noticed it.

[sureshvv]

I made said change and all tests pass. This code may be hiding some other insidious error. I checked the old SVN. Looks like this code goes way back.

Can @cekk @keul @jensens @hvelarde comment?

[keul]

@sureshvv @href no bloody idea, but I think that all that stuff can be replaced as you suggested.
Mantainers of ploneboard will probably appreciate any pull request 👍

[href]

Oh good it's not just me. Unfortunately I can't reproduce this locally. This only seems to be None at times on production. For all I know this might not even be the fault of Ploneboard. Also, it does only seem to affect users with less than admin permissions, though I can't be sure that's a factor.

[jean]

For what it's worth, the response is not None arrived in this commit by @optilude: ed8e672

[jensens]

Beside the topic: First I would convert the script into a view-class. I stopped fighting with Python-Script side effects. It's impossible to debug in a good manner (yeah, I know the tools).

Checking Request for None is indeed strange. Even in async scenarios and tests the request should be mocked. So I think its save to remove the check. IMO its not the problem of the script, but of the caller, to provide an acquired request.

But all this ambiguity will go if its proper code in a view class.