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.