Migrate to 4.3.0
Note categories are now referred to as note labels and a note can have multiple
2-factor authentication is enabled by default but a security key must be generated and added to the server configuration before it can be used. Read more here.
The category_id attribute and category relationships is still kept for backwards
compatibility but will be removed in an upcoming release. If a note has only
one label, the category and category_id will behave as in 4.2, but if there are
multiple labels only one of them will be represented by those attributes.
New relationships and schemas have been introduced to allow for transition to
the new note labels and maintain as much backwards compatibility as possible.
The NoteCategory entity still exists but should be replaced by the new NoteLabel
entity. NoteCategory inherit from NoteLabel which makes entities interchangeable.
The new NoteLabelLink entity should be used to add labels to notes. It has the
attributes label_id and note_id. Where label_id refers to the
NoteLabel/NoteCategory. The NoteLabelLink entity also has the relationships note
The Note entity has a new relationship called note_label_links which is an array
of NoteLabelLink entities.
Creating a note would previously return category_id in the response to
the create operation, it will no longer be included in the response and will
have to be queried.
Update events sent via the event hub will no longer contain a value for
categoryid, instead NoteLabelLink will be a separate entity in the update event.
Note events stored in the database that can be queried via the API as Event will
no longer contain categoryid. Instead separate events will be created for
the note with action set to db.all.notelabellink.
Migrate to 4.2.0
Users do not receive notifications if they do not have access to a project
Users without access to a project does not receive notifications for assignments / statuses on the project.
Client review collaborator interface update
The client review interface used by collaborators have been replaced by a new interface. If you encounter problems with the new interface, you can switch back to the previous interface from system settings -> Review. The old version of the review interface will be removed in a future release.
Update events for private projects
Update events will only be sent out for the projects which the user has access to. Global API keys have access to all projects with open access. If you have a script that reacts to changes in ftrack using update events, ensure it has sufficient rights to access all required projects.
Modifying UserSecurityRole deprecated
Adding and modifying
UserSecurityRole directly is no longer supported. Instead the new actions
revoke_user_security_role_project should be used.
remove_user_security_role accept user_id and role_id as parameters, while
revoke_user_security_role_project accept the additional parameters project_id or all_open_projects.
Projects relation removed from UserSecurityRole
The projects relation on
UserSecurityRole has been removed and replaced by the user_security_role_projects relation which references the new object
Adding and removing security roles using legacy API
Support for adding and removing security roles to users and granting access to projects for users using legacy API has been removed. Please use new API for these operations instead.
Migrate to 4.0.3
Version 4.0.3 enforces stricter request validation and will not allow POST requests to application or API endpoints from other sources than the configured server URL. If you are accessing the ftrack instance using another domain or IP address, please contact support before upgrading.
Migrate to 4.0.0
Developer notes: Legacy entity types in custom widget changed
When using custom dashboard widgets and triggering the event
ftrack.application.open-actions, some entity types in the event payload have
changed. Entity types with multiple words now have underscored stripped
for consistency with the sidebar.
AssetVersion will now be translated to
assetversion instead of
Migrate to 3.6.0
When upgrading to 3.6.0 the character set of the ftrack / database connection will change from latin1 to utf-8. During the 3.6.0 upgrade string characters will be converted to the utf-8 character set. This change should not be noticeable from the ftrack Connect, ftrack or the APIs.
Please make sure to read this before running the upgrade:
The upgrade may take a long time to complete, so make sure to run it in staging environment before upgrading production and plan a sufficient maintenance window. If you are using custom connections to the database you must ensure that those connections are using the utf-8 character set after the migration. If not, data read/written may be corrupted as it is interpreted using the wrong encoding.
Using ftrack's database directly is not supported or advised.