eXtremeManagement on Plone 3.0
Part of my big final assignment of my study Informatics is getting eXtremeManagement to run on Plone 3.0 (beta). That is functioning nicely now. Some remarks about what I needed to do for that.
eXtremeManagement used to be fit for Plone versions 2.1 and 2.5. We want it working with Plone 3.0 too (well, trunk should work on 2.5 and 3.0), as that is expected to be released in spring or summer 2007. At the time of writing (halfway through June) Plone 3.0 is in beta status. So some things may still change that eXtremeManagement needs to react to. But currently all automatic tests of the eXtremeManagement pass for Plone 2.5 and 3.0. Plus: a test of migrating the current database of the Zest projects site to Plone 3.0 worked fine. So what was done to reach that point?
General actions
The general steps that every product needs while upgrading from Plone 2.5 to Plone 3.0 are described in the Upgrade guide on plone.org.
Some steps were already taken for Plone 2.5, like setting up the workflows with GenericSetup. Some steps are very simple. An example is that this:
get_transaction().commit(1)
needs to be replaced with:
transaction.commit(1)
The other ones that needed checking in eXtremeManagement were:
Searching users/groups via the Membership tool is deprecated; it turns out eXtremeManagement does not use any of the deprecated methods, so fifteen minutes of checking was all that was needed here.
Portlets have a new infrastructure. Needed action: check that our classic portlets still work in Plone 3.0. They turn out to work fine. In the future we may want to investigate what the benefits of switching to the new portlet system are. A downside is that this would be incompatible with Plone 2.5, so it would require a separate branch.
main_template.pt now uses Zope 3 viewlets. eXtremeManagement is not using an own version of that template, so no action was needed. In fact, we were not even using that template, which does not sound like the best idea. So I changed our templates to use the page layout as given by the main_template.
The "Sharing" tab is now a global action. In previous Plone versions you had to explicitly add a Sharing action to your content type if you wanted to see the sharing tab when viewing that content in the Plone user interface. On the sharing tab you can share this content with others. Specifically in the case of eXtremeManagement: we have this tab on Projects, so we can give developers the Employee role and assign Tasks to them.
On Plone 3.0 this action is now always available. This means that currently some of our content types actually list this tab twice, as they explicitly add it to themselves already. The problem now is that you cannot actually do this correctly on Plone 2.5 and 3.0 at the same time: either you have no sharing tab in 2.5 or you have two sharing tabs in 3.0. Since 3.0 is beta still, I opted to have it working correctly in Plone 2.5 only. Once Plone 3.0 is officially released, we can easily fix this on a branch. Or probably: at that point we can move 2.5 compatibility to its own branch and have trunk specifically for 3.0 support.
More fixes
There were some other steps that needed to be taken before eXtremeManagement would work on Plone 3.0. Some might need to be added to the general list and some may be specific for eXtremeManagement.
Viewing content
When you have a Content Management System like Plone it is nice if you can actually see some content. At first try after migrating the current Zest database to Plone 3.0 on a local test instance, none of our content types were actually visible. Change set 43353 lists the changes that were done to make ProjectFolders viewable again. (Change set 43354 has the changes to the other content types.) Some lines could be removed from content/ProjectFolder.py as they were already in the GenericSetup profile. That profile needed some changes too, in this case the file profiles/default/types/ProjectFolder.xml. The most important are the additions of the aliases. Those lines should now look like this:
It could be that this is only needed because our types inherit from OrderedBaseFolder and not from e.g. ATFolder. If your own content type is also not visible on Plone 3.0, I would advise you to add these aliases as a first try.
Actually, the properties alias is superfluous on Plone 3.0 (but not on 2.5, so we will keep it for now). On 3.0 the properties of content can be reached via the normal edit form.
Portlet classes
Some html classes have been deprecated, so you should not use them in your templates anymore. Specifically, get rid of portletItemLast and lastItem in portlets. See change sets 43533 and 43987. And get rid of portletDetails in favour of portletItemDetails. See change set 43555. Adding a header and footer like in 43535 is also nice:
Workflow actions
The general list of things to do when preparing your product for Plone 3.0 already mentions workflows: they need to be done in GenericSetup. That was already done for eXtremeManagement. But this turned out not to be enough. Our content types had a drop down list with workflow actions, but they were not clickable. So you could not do any workflow actions, at least not from the usual drop down workflow menu. This has been put right in change set 43600 by adding a url to the workflow action, instead of having it empty (which worked fine in Plone 2.5). This is the change for profiles/default/workflows/eXtreme_Iteration_Workflow/definition.xml:
- Finish + Finish
But this means that most add-on Products for Plone have no functioning workflow in Plone 3.0, assuming that most Products have an empty url for that action. This also means that when you change the id of a transition id, you also need to remember to change the url, else the old transition is still done or at least tried. In fact, did you notice that exact mistake in the code above? Probably not. I know I did not. :) The transition id is complete, so the action url should have ended with that as well and not with finish.
Can we make this simpler? Yes. I provided a fix for core Plone so it would accept the empty urls that most workflows have. I only just got commit privileges to core Plone, partly based on this proposed fix probably, so change set 15335 is my first actual commit there. This meant that I could revert my earlier change to eXtremeManagement.