Using WF on file or images tries to take action on the file/image

I've found an interesting issue with Plone 5.0.6.

With all content types expect file and image, the workdlow works as advertised.

However, with file types, when WF to another state, it tries to download the file. I've tried several WFs and always acts the same. see below.

For images, when WF invoked, the image is opened.

Note: in both cases, once you download the file and refresh the screen, the WF transition has occurred.

Any ideas how to stop this?

1 Like

I am guessing: After the workflow change, the UI likely wants to revisit the object (now in the new state). I assume, it is using a (HTTP) redirect for this and uses a less than optimal url (the download rather than the view url).

At your place, I would verify whether the guess is correct -- looking at the "Z2.log" (= ZServer) log file. If so, I would try to find out where the redirect url is determined and check how to change it.

Note that the download url for "File" and "Image" likely is "<url_to_the_object>", while the view url likely is "<url_to_the_object>/view". For most object types, "<url_to_the object>" is also the view url.

1 Like

The empty "" 's above should in fact read "<url_to_the_object>". Apparently, this forum's editor is not WYSWYG but interprets some HTML markup.

Hi Dieter,

thanks for your ideas.

Luke Brannon found the solution for me.

portal_types/Link go to "Actions" tab , the "view" is missing from the view string. adding this fixes the issue

Note: this WF behavior also happened for documents and it also was missing the 'view'

It fixes the issue, however, I find it strange that something deep in the bowels of Zope caused the issue. Either the WF behavior had never been noticed (hard to believe) or this was a bug introduced somewhere along the line. Can't understand why.

Comments from anyone?

1 Like

do you mind opening an issue in the Plone issue tracker?

I think Luke Brannon already has... and made a PR

Likely a not very relevant remark: it is not "something deep in the bowels of Zope". It is quite natural that a workflow wants to revisit the object once the object's state has been changed. Some objects have several "standard" views; e.g. for a file, you may want to view its content (or "download it") or its metadata (where the metadata view may contain a preview or even the complete content). For those objects, the wrong url may quite easily be used in some situations (e.g. for the workflow).

File and Image content type items have no workflow by default, and that's probably why this issue has never been noticed.

1 Like

Hi Yes, Luke said he has made a PR