ftw.upgrade 1.18.0

Installing ftw.upgrade’s console script

If you include ftw.upgrade in the list of eggs of a plone.recipe.zope2instance based section, the bin/upgrade script should be generated automatically for you (that is, if you haven’t limited or suppressed script generation via the scripts option).

Otherwise, installing the console script bin/upgrade can be done with an additional buildout part:

[buildout]
parts += upgrade

[upgrade]
recipe = zc.recipe.egg:scripts
eggs = ftw.upgrade

Compatibility

Plone 4.1

Plone 4.2

Plone 4.3

Fallback view

The @@manage-upgrades-plain view acts as a fallback view for @@manage-upgrades. It does not include plone`s main template and thus might be able to render when the default view fails for some reason.

Updating objects with progress logging

Since an upgrade step often updates a set of objects indexed in the catalog, there is a useful helper method combining querying the catalog with the ProgressLogger (see below). The catalog is queried unrestricted so that we handle all the objects.

Here is an example for updating all objects of a particular type:

from ftw.upgrade import ProgressLogger
from ftw.upgrade import UpgradeStep

class ExcludeFilesFromNavigation(UpgradeStep):

   def __call__(self):
       for obj in self.objects({'portal_type': 'File'},
                               'Enable exclude from navigation for files'):
           obj.setExcludeFromNav(True)

When running the upgrade step you’ll have a progress log:

INFO ftw.upgrade STARTING Enable exclude from navigation for files
INFO ftw.upgrade 1 of 10 (10%): Enable exclude from navigation for files
INFO ftw.upgrade 5 of 50 (50%): Enable exclude from navigation for files
INFO ftw.upgrade 10 of 10 (100%): Enable exclude from navigation for files
INFO ftw.upgrade DONE: Enable exclude from navigation for files

Methods

The UpgradeStep class has various helper functions:

self.getToolByName(tool_name)

Returns the tool with the name tool_name of the upgraded site.

self.objects(catalog_query, message, logger=None, savepoints=None)

Queries the catalog (unrestricted) and an iterator with full objects. The iterator configures and calls a ProgressLogger with the passed message.

If set to a non-zero value, the savepoints argument causes a transaction savepoint to be created every n items. This can be used to keep memory usage in check when creating large transactions.

self.catalog_rebuild_index(name)

Reindex the portal_catalog index identified by name.

self.catalog_reindex_objects(query, idxs=None, savepoints=None)

Reindex all objects found in the catalog with query. A list of indexes can be passed as idxs for limiting the indexed indexes. The savepoints argument will be passed to self.objects().

self.catalog_has_index(name)

Returns whether there is a catalog index name.

self.catalog_add_index(name, type_, extra=None)

Adds a new index to the portal_catalog tool.

self.catalog_remove_index(name)

Removes an index to from portal_catalog tool.

self.actions_remove_action(category, action_id)

Removes an action identified by action_id from the portal_actions tool from a particulary category.

self.catalog_unrestricted_get_object(brain)

Returns the unrestricted object of a brain.

self.catalog_unrestricted_search(query, full_objects=False)

Searches the catalog without checking security. When full_objects is True, unrestricted objects are returned instead of brains. Upgrade steps should generally use unrestricted catalog access since all objects should be upgraded - even if the manager running the upgrades has no access on the objects.

self.actions_add_type_action(self, portal_type, after, action_id, **kwargs)

Add a portal_types action from the type identified by portal_type, the position can be defined by the after attribute. If the after action can not be found, the action will be inserted at the end of the list.

self.actions_remove_type_action(portal_type, action_id)

Removes a portal_types action from the type identified by portal_type with the action id action_id.

self.set_property(context, key, value, data_type='string')

Set a property with the key value and the value value on the context safely. The property is created with the type data_type if it does not exist.

self.add_lines_to_property(context, key, lines)

Updates a property with key key on the object context adding lines. The property is expected to by of type “lines”. If the property does not exist it is created.

self.setup_install_profile(profileid, steps=None)

Installs the generic setup profile identified by profileid. If a list step names is passed with steps (e.g. [‘actions’]), only those steps are installed. All steps are installed by default.

self.install_upgrade_profile(steps=None)

Installs the generic setup profile associated with this upgrade step. Profile may be associated to upgrade steps by using either the upgrade-step:importProfile or the upgrade-step:directory directive.

self.uninstall_product(product_name)

Uninstalls a product using the quick installer.

self.migrate_class(obj, new_class)

Changes the class of an object. It has a special handling for BTreeFolder2Base based containers.

self.remove_broken_browserlayer(name, dottedname)

Removes a browser layer registration whose interface can’t be imported any more from the persistent registry. Messages like these on instance boot time can be an indication for this problem: WARNING OFS.Uninstalled Could not import class 'IMyProductSpecific' from module 'my.product.interfaces'

self.update_security(obj, reindex_security=True)

Update the security of a single object (checkboxes in manage_access). This is usefuly in combination with the ProgressLogger. It is possible to not reindex the object security in the catalog (allowedRolesAndUsers). This speeds up the update but should only be disabled when there are no changes for the View permission.

self.update_workflow_security(workflow_names, reindex_security=True)

Update all objects which have one of a list of workflows. This is useful when updating a bunch of workflows and you want to make sure that the object security is updated properly.

The update is done by doing as few as possibly by only searching for types which might have this workflow. It does support placeful workflow policies.

For speeding up you can pass reindex_security=False, but you need to make sure you did not change any security relevant permissions (only View needs reindex_security=True for default Plone).

self.base_profile

The attribute base_profile contains the profile name of the upgraded profile including the profile- prefix. Example: u"profile-the.package:default". This information is only available when using the upgrade-step:directory directive.

self.target_version

The attribute target_version contains the target version of the upgrade step as a bytestring. Example with upgrade step directory: "20110101000000". This information is only available when using the upgrade-step:directory directive.

Progress logger

When an upgrade step is taking a long time to complete (e.g. while performing a data migration), the administrator needs to have information about the progress of the update. It is also important to have continuous output for avoiding proxy timeouts when accessing Zope through a webserver / proxy.

With the ProgressLogger it is very easy to log the progress:

from ftw.upgrade import ProgressLogger
from ftw.upgrade import UpgradeStep

class MyUpgrade(UpgradeStep):

   def __call__(self):
       objects = self.catalog_unrestricted_search(
           {'portal_type': 'MyType'}, full_objects=True)

       for obj in ProgressLogger('Migrate my type', objects):
           self.upgrade_obj(obj)

   def upgrade_obj(self, obj):
       do_something_with(obj)

The logger will log the current progress every 5 seconds (default). Example log output:

INFO ftw.upgrade STARTING Migrate MyType
INFO ftw.upgrade 1 of 10 (10%): Migrate MyType
INFO ftw.upgrade 5 of 50 (50%): Migrate MyType
INFO ftw.upgrade 10 of 10 (100%): Migrate MyType
INFO ftw.upgrade DONE: Migrate MyType

Workflow Chain Updater

When the workflow is changed for a content type, the workflow state is reset to the init state of new workflow for every existing object of this type. This can be really annoying.

The WorkflowChainUpdater takes care of setting every object to the right state after changing the chain (the workflow for the type):

from ftw.upgrade.workflow import WorkflowChainUpdater
from ftw.upgrade import UpgradeStep

class UpdateWorkflowChains(UpgradeStep):

    def __call__(self):
        query = {'portal_type': ['Document', 'Folder']}
        objects = self.catalog_unrestricted_search(
            query, full_objects=True)

        review_state_mapping={
            ('intranet_workflow', 'plone_workflow'): {
                'external': 'published',
                'pending': 'pending'}}

        with WorkflowChainUpdater(objects, review_state_mapping):
            # assume that the profile 1002 does install a new workflow
            # chain for Document and Folder.
            self.setup_install_profile('profile-my.package.upgrades:1002')

The workflow chain updater migrates the workflow history by default. The workflow history migration can be disabled by setting migrate_workflow_history to False:

with WorkflowChainUpdater(objects, review_state_mapping,
                          migrate_workflow_history=False):
    # code

If a transition mapping is provided, the actions in the workflow history entries are migrated according to the mapping so that the translations work for the new workflow:

transition_mapping = {
    ('intranet_workflow', 'new_workflow'): {
        'submit': 'submit-for-approval'}}

with WorkflowChainUpdater(objects, review_state_mapping,
                          transition_mapping=transition_mapping):
    # code

Placeful Workflow Policy Activator

When manually activating a placeful workflow policy all objects with a new workflow might be reset to the initial state of the new workflow.

ftw.upgrade has a tool for enabling placeful workflow policies without breaking the review state by mapping it from the old to the new workflows:

from ftw.upgrade.placefulworkflow import PlacefulWorkflowPolicyActivator
from ftw.upgrade import UpgradeStep

class ActivatePlacefulWorkflowPolicy(UpgradeStep):

    def __call__(self):
        portal_url = self.getToolByName('portal_url')
        portal = portal_url.getPortalObject()

        context = portal.unrestrictedTraverse('path/to/object')

        activator = PlacefulWorkflowPolicyActivator(context)
        activator.activate_policy(
            'local_policy',
            review_state_mapping={
                ('intranet_workflow', 'plone_workflow'): {
                    'external': 'published',
                    'pending': 'pending'}})

The above example activates a placeful workflow policy recursively on the object under “path/to/object”, enabling the placeful workflow policy “local_policy”.

The mapping then maps the “intranet_workflow” to the “plone_workflow” by defining which old states (key, intranet_workflow) should be changed to the new states (value, plone_workflow).

Options

• activate_in: Activates the placeful workflow policy for the passed in object (True by default).

• activate_below: Activates the placeful workflow policy for the children of the passed in object, recursively (True by default).

• update_security: Update object security and reindex allowedRolesAndUsers (True by default).

Setting up an upgrade directory

• Register an upgrade directory for your profile (e.g. my/package/configure.zcml):

<configure
    xmlns="http://namespaces.zope.org/zope"
    xmlns:upgrade-step="http://namespaces.zope.org/ftw.upgrade"
    i18n_domain="my.package">

    <include package="ftw.upgrade" file="meta.zcml" />

    <upgrade-step:directory
        profile="my.package:default"
        directory="./upgrades"
        />

</configure>

• Create the configured upgrade step directory (e.g. my/package/upgrades) and put an empty __init__.py in this directory (prevents some python import warnings).

• Remove the version from the metadata.xml of the profile for which the upgrade step directory is configured (e.g. my/package/profiles/default/metadata.xml):

<?xml version="1.0"?>
<metadata>
    <dependencies>
        <dependency>profile-other.package:default</dependency>
    </dependencies>
</metadata>

Creating an upgrade step

Upgrade steps can be generated with ftw.upgrade’s bin/upgrade console script. The idea is to install this script with buildout using zc.recipe.egg.

Once installed, upgrade steps can simply be scaffolded with the script:

$ bin/upgrade create AddControlpanelAction

The create command searches for your upgrades directory by resolving the *.egg-info/top_level.txt file. If you have no egg-infos or your upgrades directory is named differently the automatic discovery does not work and you can provide the path to the upgrades directory using the --path argument.

If you would like to have colorized output in the terminal, you can install the colors extras (ftw.upgrade[colors]).

Reordering upgrade steps

The bin/upgrade console script provides a touch for reordering generated upgrade steps. With the optional arguments --before and --after upgrade steps can be moved to a specific position. When the optional arguments are omitted, the upgrade step timestamp is set to the current time.

Examples:

$ bin/upgrade touch upgrades/20141218093045_add_controlpanel_action
$ bin/upgrade touch 20141218093045_add_controlpanel_action --before 20141220181500_update_registry
$ bin/upgrade touch 20141218093045_add_controlpanel_action --after 20141220181500_update_registry

Creating an upgrade step manually

• Create a directory for the upgrade step in the upgrades directory. The directory name must contain a timestamp and a description, concatenated by an underscore, e.g. YYYYMMDDHHMMII_description_of_what_is_done:

$ mkdir my/package/upgrades/20141218093045_add_controlpanel_action

• Next, create the upgrade step code in an upgrade.py in the just created directory. This file needs to be created, otherwise the upgrade step is not registered.

# my/package/upgrades/20141218093045_add_controlpanel_action/upgrade.py

from ftw.upgrade import UpgradeStep

class AddControlPanelAction(UpgradeStep):
    """Adds a new control panel action for the package.
    """
    def __call__(self):
        # maybe do something
        self.install_upgrade_profile()
        # maybe do something

• You must inherit from UpgradeStep.

• Give your class a proper name, although it does not show up anywhere.

• Add a descriptive docstring to the class, the first consecutive lines are used as upgrade step description.

• Do not forget to execute self.install_upgrade_profile() if you have Generic Setup based changes in your upgrade.

• Put Generic Setup files in the same upgrade step directory, it automatically acts as a Generic Setup profile just for this upgrade step. The install_upgrade_profile knows what to import.

  For our example this means we put a file at my/package/upgrades/20141218093045_add_controlpanel_action/controlpanel.xml which adds the new control panel action.

The resulting directory structure should be something like this:

my/
  package/
    configure.zcml                              # registers the profile and the upgrade directory
    upgrades/                                   # contains the upgrade steps
      __init__.py                               # prevents python import warnings
      20141218093045_add_controlpanel_action/   # our first upgrade step
        upgrade.py                              # should contain an ``UpgradeStep`` subclass
        controlpanel.xml                        # Generic Setup data to import
      20141220181500_update_registry/           # another upgrade step
        upgrade.py
        *.xml
    profiles/
      default/                                  # the default Generic Setup profile
        metadata.xml

Authentication and authorization

The API is available for users with the “cmf.ManagePortal” permission, usually the “Manager” role is required.

Versioning

A specific API version can be requested by adding the version to the URL. Example:

$ curl -uadmin:admin http://localhost:8080/upgrades-api/v1/list_plone_sites

API Discovery

The API is discoverable and self descriptive. The API description is returned when the API action is omitted:

$ curl -uadmin:admin http://localhost:8080/upgrades-api/
{
    "api_version": "v1",
    "actions": [
        {
            "request_method": "GET",
            "required_params": [],
            "name": "current_user",
            "description": "Return the current user when authenticated properly. This can be used for testing authentication."
        },
        {
            "request_method": "GET",
            "required_params": [],
            "name": "list_plone_sites",
            "description": "Returns a list of Plone sites."
        }
    ]
}

$ curl -uadmin:admin http://localhost:8080/Plone/upgrades-api/
...

Listing Plone sites:

$ curl -uadmin:admin http://localhost:8080/upgrades-api/list_plone_sites
[
    {
        "path": "/Plone",
        "id": "Plone",
        "title": "Website"
    }
]

Listing profiles and upgrades

$ curl -uadmin:admin http://localhost:8080/Plone/upgrades-api/list_profiles
[
    {
        "id": "Products.CMFEditions:CMFEditions",
        "db_version": "4",
        "product": "Products.CMFEditions",
        "title": "CMFEditions",
        "outdated_fs_version": false,
        "fs_version": "4",
        "upgrades": [
            {
                "proposed": false,
                "title": "Fix portal_historyidhandler",
                "outdated_fs_version": false,
                "orphan": false,
                "dest": "3",
                "done": true,
                "source": "2.0",
                "id": "3@Products.CMFEditions:CMFEditions"
            },

...

$ curl -uadmin:admin "http://localhost:8080/Plone/upgrades-api/get_profile?profileid=Products.TinyMCE:TinyMCE"
{
    "id": "Products.TinyMCE:TinyMCE",
    "db_version": "7",
    "product": "Products.TinyMCE",
    "title": "TinyMCE Editor Support",
    "outdated_fs_version": false,
    "fs_version": "7",
    "upgrades": [
        {
            "proposed": false,
            "title": "Upgrade TinyMCE",
            "outdated_fs_version": false,
            "orphan": false,
            "dest": "1.1",
            "done": true,
            "source": "1.0",
            "id": "1.1@Products.TinyMCE:TinyMCE"
        },
...

$ curl -uadmin:admin http://localhost:8080/Plone/upgrades-api/list_profiles_proposing_upgrades
...

$ curl -uadmin:admin http://localhost:8080/Plone/upgrades-api/list_proposed_upgrades
[
    {
        "proposed": true,
        "title": "Foo.",
        "outdated_fs_version": false,
        "orphan": true,
        "dest": "20150114104527",
        "done": false,
        "source": "10000000000000",
        "id": "20150114104527@ftw.upgrade:default"
    }
]

Executing upgrades

When executing upgrades the response is not of type JSON but a streamed upgrade log. If the request is correct, the response status will always be 200 OK, no matter whether the upgrades will install correctly or not. If an upgrade fails, the request and the transaction is aborted and the response content will end with “Result: FAILUREn”. If the upgrade succeeds, the response content will end with “Result: SUCCESSn”.

$ curl -uadmin:admin -X POST "http://localhost:8080/Plone/upgrades-api/execute_upgrades?upgrades:list=7@Products.TinyMCE:TinyMCE&upgrades:list=20150114104527@ftw.upgrade:default"
2015-01-14 11:16:14 INFO ftw.upgrade ______________________________________________________________________
2015-01-14 11:16:14 INFO ftw.upgrade UPGRADE STEP Products.TinyMCE:TinyMCE: Upgrade TinyMCE 1.3.4 to 1.3.5
2015-01-14 11:16:14 INFO ftw.upgrade Ran upgrade step Upgrade TinyMCE 1.3.4 to 1.3.5 for profile Products.TinyMCE:TinyMCE
2015-01-14 11:16:14 INFO ftw.upgrade Upgrade step duration: 1 second
2015-01-14 11:16:14 INFO ftw.upgrade ______________________________________________________________________
2015-01-14 11:16:14 INFO ftw.upgrade UPGRADE STEP ftw.upgrade:default: Foo.
2015-01-14 11:16:14 INFO GenericSetup.rolemap Role / permission map imported.
2015-01-14 11:16:14 INFO GenericSetup.archetypetool Archetype tool imported.
2015-01-14 11:16:14 INFO ftw.upgrade Ran upgrade step Foo. for profile ftw.upgrade:default
2015-01-14 11:16:14 INFO ftw.upgrade Upgrade step duration: 1 second
Result: SUCCESS

$ curl -uadmin:admin -X POST http://localhost:8080/Plone/upgrades-api/execute_proposed_upgrades
2015-01-14 11:17:34 INFO ftw.upgrade ______________________________________________________________________
2015-01-14 11:17:34 INFO ftw.upgrade UPGRADE STEP ftw.upgrade:default: Bar.
2015-01-14 11:17:35 INFO GenericSetup.rolemap Role / permission map imported.
2015-01-14 11:17:35 INFO GenericSetup.archetypetool Archetype tool imported.
2015-01-14 11:17:35 INFO ftw.upgrade Ran upgrade step Bar. for profile ftw.upgrade:default
2015-01-14 11:17:35 INFO ftw.upgrade Upgrade step duration: 1 second
Result: SUCCESS

$ curl -uadmin:admin -X POST "http://localhost:8080/Plone/upgrades-api/execute_profiles?profiles:list=Products.PloneFormGen:default&profiles:list=ftw.upgrade:default"
2016-01-05 13:09:46 INFO ftw.upgrade Installing profile Products.PloneFormGen:default.
2016-01-05 13:09:46 INFO GenericSetup.rolemap Role / permission map imported.
...
2016-01-05 13:09:48 INFO GenericSetup.types 'FieldsetEnd' type info imported.
2016-01-05 13:09:48 INFO GenericSetup.factorytool FactoryTool settings imported.
2016-01-05 13:09:48 INFO ftw.upgrade Done installing profile Products.PloneFormGen:default.
2016-01-05 13:09:48 INFO ftw.upgrade Ignoring already installed profile ftw.upgrade:default.
Result: SUCCESS

$ curl -uadmin:admin -X POST "http://localhost:8080/test/upgrades-api/plone_upgrade"
"Plone Site has been updated."

$ curl -uadmin:admin -X POST "http://localhost:8080/test/upgrades-api/plone_upgrade"
"Plone Site was already up to date."

$ curl -uadmin:admin -X POST "http://localhost:8080/test/upgrades-api/plone_upgrade_needed"

Recook resources

CSS and JavaScript resource bundles can be recooked:

$ curl -uadmin:admin -X POST http://localhost:8080/Plone/upgrades-api/recook_resources
"OK"

1.18.0 (2016-02-16)

• Provide the attributes base_profile and target_version on upgrade steps when using the upgrade-step:directory directive. [jone]

• Fix profile version when using upgrade-step:directory and having old upgrade steps but no new ones. [jone]

1.17.0 (2016-01-22)

• Add bin/upgrade plone_upgrade_needed command. [jone]

1.16.3 (2016-01-22)

• Fix upgrade scaffolding when having dots or other non-alphanumeric characters. [jone]

1.16.2 (2016-01-15)

• Actually the same as 1.16.1, but pypi was broken when I released it and now it does not let me use the same version number. :-( [jone]

1.16.1 (2016-01-13)

• Added documentation for the additions of the previous release. [maurits]

1.16.0 (2016-01-05)

• Added --all-sites option. This iterates over all sites and performs the specified command on each of them. A failing command for one site will stop the entire command. [maurits]

• Configure logging for the command line utility. By default print only our own logging, on info level or higher. With the new --verbose option print all loggers (so also from other packages like requests) at debug level and higher. [maurits]

• Added plone_upgrade command to upgrade a Plone Site. This is what you would manually do in the @@plone-upgrade view. [maurits]

• Added support for installing profiles. Profiles are only applied once. Example command line: bin/upgrade install --site Plone --profiles Products.PloneFormGen:default. [maurits]

• Prevented UnicodeEncodeError when piping output of bin/upgrade sites. This would fail when a site had non-ascii characters in its title. [maurits]

1.15.1 (2015-11-11)

• Change instance detection to support any name. Before only “instance*” was supported. [jone]

1.15.0 (2015-10-30)

• Make “blessed” dependency optional in the “colors” extras. [jone]

• Update references to class-migrated objects in the intid utility. [deiferni]

1.14.8 (2015-09-21)

• Migrate workflow states with wfhistory migration and do not set state manually unless necessary. [tschanzt]

1.14.7 (2015-08-27)

• Add an afterCommitHook that notifies about the transaction having been committed (or aborted) after installing upgrades. [lgraf]

• Fix authentication problem with bin/upgrade command. [jone]

1.14.6 (2015-07-22)

• Return context manager to allow “as” statements. [lknoepfel]

1.14.5 (2015-05-20)

• Update quickinstaller product version when upgrading a package. [jone]

1.14.4 (2015-04-09)

• Fix post upgrade ordering which was broken since 1.11.0. [jone]

1.14.3 (2015-03-29)

• Fix error in upgrade-step:directory directive. The error occured when the directory was a subdirectory relative to the ZCML directory, causing the package module to be replaced with the upgrades package directory in sys.modules. [jone]

• Fix issue with transaction note length when a large not already exists. When the transaction note already has maximum length (e.g. with Archetypes notes), nothing more should be added. Also increased the threshold back (reduced in 1.14.2). [jone]

1.14.2 (2015-03-25)

• Reduce maximum transaction note length used by ftw.upgrade. [jone]

1.14.1 (2015-03-18)

• Command: fix instance discover when bound to public interface. [jone]

1.14.0 (2015-02-24)

• Command: add fake terminal fallback when blessed cannot be loaded. This can happen for example when Python is built without curses support. [jone]

• bin/upgrade recook command for recooking resources. [jone]

• Recook resources after installing upgrades. [jone]

• plone.reload support for upgrade step directory. [jone]

1.13.0 (2015-02-20)

• bin/upgrade: automatically authenticate with a tempfile negotiation mechanism when no other authentication information is provided. [jone]

• New bin/upgrade user command for testing authentication. [jone]

1.12.0 (2015-02-16)

• Add bin/upgrade commands sites, list and install. This makes it possible to install upgrades from the console. [jone]

• Update upgrade step scaffold to support plone.reload. [jone]

• New JSON API implemented, accessible with /upgrades-api. [jone]

• Executioner: install_upgrades_by_api_ids was added, allowing to install a selection of upgrades identified by API ugprade ids. [jone]

• Gatherer: get_upgrades_by_api_ids was added, returning upgrade infos for a selection of API upgrade ids. [jone]

• Gatherer: get_upgrades is deprecated and replaced by get_profiles. get_profiles now has a proposed_only flag. [jone]

1.11.0 (2015-01-08)

• Reverse post upgrade adapter ordering. The order was reversed, it should execute dependencies first. [jone]

• create-upgrade: Make sure to quote argument passed to bin/upgrade. [lgraf]

• Add a create-upgrade script which can be installed globally. [jone]

• Create a bin/upgrade script:

  • the create command creates a upgrade step in the “upgrades” directory.

  • the touch command can be used for reordering upgrade steps.

  [jone]

• New upgrade-step:directory directive for registering a directory with upgrade steps which are automatically detected and registered. [jone]

• Extend the importProfile directive so that a handler can be defined. The handler may import the associated upgrade step profile with the new method self.install_upgrade_profile(). [jone]

1.10.2 (2014-11-19)

• Exclude uninstalled products from upgrades view. [jone]

• Make upgrades appear in undo form again. The transaction note fix in 1.7.4 caused upgrade transaction to not appear in the undo form. [jone]

1.10.1 (2014-10-27)

• Update upgrade view ordering for root nodes. The dependency graph does not define any order for root profiles (e.g. included in buildout directly), which causes random sorting in the upgrade view for those profiles. This change sorts those root profiles by name without changing the order of profiles which is depended on. [jone]

1.10.0 (2014-08-28)

• Wrap step.objects in a SavepointIterator that creates a savepoint every n items. [lgraf]

1.9.0 (2014-08-27)

• Add @@manage-upgrades-plain fallback view for @@manage-upgrades. It does not include plone`s main template and thus might be able to render when the default view fails for some reason. [deiferni]

1.8.0 (2014-08-11)

• Prevent portal_quickinstaller from picking upgrade-steps instead of the default-profile by prefixing the profile-id with upgrade_to_ (fix #45) [pbauer]

• Flag profiles whose filesystem version is outdated. Highlights profiles with upgrades that lead to a destination version that is higher than the corresponding profile’s current filesystem version. This usually means someone forgot to update the version in metadata.xml of the corresponding profile. [lgraf]

1.7.4 (2014-05-12)

• Extend workflow updater to migrate workflow history. [jone]

• Fix workflow updater to always update objects. The objects are updated even when it seems that the object was not update or has no longer a workflow. This fixes issues when updating a workflow, in which case the old workflow and the new workflow has the same ID. [jone]

• Make sure the transaction note does not get too long. Zope limits the transaction note length. By actively managing the transaction note we can provide fallbacks for when it gets too long because a lot of upgrade steps are installed at the same time. [jone]

1.7.3 (2014-04-30)

• Add uninstall_product method to upgrade step class. [jone]

1.7.2 (2014-02-28)

• Update provided interfaces when migrating objects to new class. [jone]

1.7.1 (2014-01-09)

• Fix LocationError on manage-ugprades view on cyclic dependencies. [jone]

1.7.0 (2013-09-24)

• Add a update_workflow_security helper function to the upgrade step. [jone]

1.6.0 (2013-08-30)

• Fix inplace modification bug when updating the catalog while iterating over a catalog result. [jone]

• Implement new importProfile directive for creating upgrade steps that just import a specific upgrade step generic setup profile. [jone]

1.5 (2013-08-16)

• Add a WorkflowChainUpdater for changing workflow chains without resetting existing objects to the initial review state of the new workflow. [jone]

1.4.0 (2013-07-18)

• Added helper for adding a type_action. [phgross]

• Add objects method to UpgradeStep for easy querying the catalog and doing stuff with progress logging combined. [jone]

• Make ProgressLogger an iterator too, because it is easier to use. [jone]

• Improve logging while installing upgrade steps. Show duration for installing. [jone]

• Fix upgrade step icons for Plone 4.3. [jone]

• Add update_security helper. [jone]

• Fix incomplete status info entry prodcued by placeful workflow policy activator. [jone]

1.3 (2013-06-13)

• Implement a placeful workflow policy activator. [jone]

• Added remove_broken_browserlayer method to step class. [lgraf]

1.2.1 (2013-04-23)

• Keep modification date on reindexObject wihtout idxs. [mathias.leimgruber]

1.2 (2013-01-24)

• onegov.ch approved: add badge to readme. [jone]

• Remove ‘step’ and ‘for’ values from internal data structure. This is needed for allowing us to serialize the data (json). [jone]

• Add IPostUpgrade adapter hook. [jone]

• Refactor dependency sorting into seperate function. [jone]

• Add security declarations. [jone]

• Fix wrong tool usage when installing a profile in step class. [jone]

1.1 (2012-10-08)

• Add catalog_unrestricted_get_object and catalog_unrestricted_search methods to step class. [jone]

• Handle profiles of packages which were removed but have leftover generic setup entries. [jone]

1.0 (2012-08-13)

• Add installed upgrades to transaction note. Closes #7 [jone]

• Add migrate_class helper with _p_changed implementation supporting BTreeFolder2Base containers. [jone]

• Remove purge_resource_registries() helper because it does not behave as expected. [jone]

• Set min-height of upgrade output frame to 500px. [jone]

• Print exceptions to browser log stream. [jone]

1.0b2 (2012-07-04)

• Fix the upgrade registration problem (using a classmethod does not work since registration fails). [jone]

• Let @@manage-upgrade be usable without actually installing the GS profile. [maethu]

1.0b1 (2012-06-27)

• First implementation. [jone]