Question

I have a dexterity content type in Plone 4.2.4. The versioning works fine with the default workflow for this content type, although it is not a workflow shipped with plone, but a custom made.

However, when I enable a second workflow for the same type, everything but the versioning works fine.

  • additional permissions managed by the second workflow are working
  • The state changes are working

The difference:

  • I used different state_variable names for the workflows, which seems to make sense, to have a catalogable field for the state of the second workflow.

I've tried to use the same state variable name, but that didn't help. I have the workflow variable review_history also set in the 2nd workflow and sufficient permissions in the context. I am (mostly) shure, that I got the permission concept, but I have no clou, how permissions get calculated, when multiple workflows are involved.

Any idea, why the second workflow does not leave a trace in my content types history?

Thanks very much in advance.

Udate

I've reordered the workflows as Ida Ebkes suggested and did see, that all transitions from the 2nd workflow get stored properly. So it seems to be an issue with the historyview.

Since these workflows indeed describe concurrent behaviors of a content type, I really would like to stick with separate workflows and ideally different workflow state variables and catalog indexes.

What I now think needs to be done, is to tweak the historyview.

Was it helpful?

Solution

Here is how I did it. It works for plone 4.2.4 at least.

Since the problem was a display problem, I just had to tweak my historyviewlet. Therefore, I created a folder named viewlets in my product root and created a __init__.py and a configure.zcml file. Then i copied content_history.pt, history_view.pt, review_history.pt and content.py from plone/app/layout/viewlets/ (omelette) to the newly created folder.

The configure.zcml contains two view registrations:

<browser:view
    for="*"
    name="my-contenthistory"
    class=".content.ContentHistoryView"
    permission="zope2.View"
    />

<browser:page
    for="*"
    name="my-historyview"
    template="history_view.pt"
    permission="zope2.View"
    />

Furthermore, I copied the whole WorkflowHistoryViewlet class from content.py to a different class name. TransferHistory in this case. Then I changed mostly the part that corresponds to the workflow state variable, which was not review_state, but transfer_state. I further found that the initial usage of the 2nd workflow creates also a created entry in the history of the 2nd workflow, that I just filtered .

transfer_history = [x for x in transfer_history if x['action'] != None]

The I corrected the view name in history_view.pt to my new view name.

<div tal:replace="structure here/@@my-contenthistory">Content History</div>

Finally, I added my class as parent to the ContentHistoryViewlet class in content.py

class ContentHistoryViewlet(WorkflowHistoryViewlet, TransferHistoryViewlet):

    index = ViewPageTemplateFile("content_history.pt")

    @memoize
    def getUserInfo(self, userid):

    [...]

    def fullHistory(self):
        history = self.workflowHistory() + self.revisionHistory() + self.transferHistory()
        if len(history) == 0:
            return None
        history.sort(key=lambda x: x["time"], reverse=True)
        return history

and registered the .zcml in the products configure.zcml

 <include package=".viewlets" />

Then I modified content_history.pt and also changed the definition of action_id in the upper part of the file.

[...]
action_id python:item['action'] or item.get('review_state', False) or item.get('transfer_state', False);
[...]

After rebooting the monster and a product reinstall, all state changes from both workflows are shown in the my-historyview.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top