TaskAdapter 3 development

A new major release of TaskAdapter is in the works. It will be released as version 3 and it will have the following highly requested changes:

1. Transfer any fields, including custom ones

The current production version of TaskAdapter (2.x) supports a limited set of fields with a pre-defined mapping schema, which can only be tweaked for a few Microsoft Project-specific fields. There is some rudimentary support for custom fields when saving tasks to JIRA, but that is it.

The new version will allow using any field, including custom ones.

v3-many-fields

Initial focus is on Atlassian JIRA with most common field types at first, like “multi-values labels” and such. Next versions will add support for other systems and custom field types.

2. Map any field to any field

The current TaskAdapter 2.x can only transfer data between a set of known fields. E.g. its mapping between “Description” in JIRA and “Notes” in Microsoft Project is set in stone and can only be skipped but not edited:

taskadapter-2-mapings-JIRA-MSP

With TaskAdapter 3 you can map “Description” in JIRA to any field in your other system - e.g. to “Notes” in Microsoft Project or to “my_custom_field” in your Basecamp installation.
taskadapter-3-mapings-JIRA-MSP

Any number of mapping rows is possible, including duplicates. You want to map the same field S1 to both fields T1 and T2 in the target system? That is possible too.

For now it is up to the user to make sure field mappings make sense. The current prototype only performs a few sanity checks. Next versions will generate better mapping suggestions for new synchronization configs.

3. One-side mappings with defaults

When you have a required custom field X in your JIRA (say, “environment”) and you don’t have a corresponding field in your Redmine server, you can set “environment” as the JIRA field and omit setting field for the second system (Redmine in this example), while providing a default value instead - e.g. “Windows”. This way “Windows” will be set as “environment” when creating tasks in JIRA (since there is no such field/concept in your other system).

v3-one-side-mappings-with-default

The same default value can also be used if this field does exist in your other system, but it is empty in the task currently being processed.

4. Two-way update

Two-way update between task management systems is now possible. E.g. you can load tasks from Redmine, save them to JIRA, then later reload their current state from Redmine and send updates to JIRA.

5. Scheduled synchronization

(Coming soon). Once you set up a synchronization config for two systems, you can set a schedule for your synchronization to work in the background. E.g. once an hour.

This is not included in the current dev build. Will be added soon.

Try it

A dev build is available to gather early feedback. It is fairly functional but is not recommended for production usage until at least a beta version is released.

Download it here.

Known limitations in the current dev build

These issues will be addressed soon:

  • Core: Tasks cache (mapping for tasks in source-target systems) is erased when there is an error during one of export operations for that config. This means if you copied tasks from one JIRA to another (for example), with the cache erased the next export will not be able to understand that the tasks need to be updated rather than created again. You will get duplicate tasks in your target system.

  • UI: There is no UI to edit saved server setups (e.g. JIRA url and credentials). As a workaround, you can edit json-based config files directly.

  • UI: Edit Config page does not make it clear which of the saved setups is used (e.g. “my JIRA with login A” vs. “my other JIRA install with login B”)

  • UI: cannot login to app if at least one config is broken. Workaround: delete broken configs in home_folder/.taskadapter/user/ folder

  • Connectors: only Atlassian JIRA, Microsoft Project and Redmine are included in this build. MantisBT, GitHub, Basecamp and Basecamp Classic will be added soon, once the new architecture is stable enough.

Updates

See these new release notes since this blog post was first published: