List of known limitations of TFS4JIRA

Owned by Paweł Mazur
Last updated: Oct 29, 2021
2 min read

There are 2 main groups of known limiting factors of said conversion

  1. REST API limitations. - We use REST API to communicate both with Jira and Azure DevOps. Sometimes this means of communication is having fewer options than live editing. Those limitations might be fixed by changes in Jira and ADO REST API. We have little influence over it.

  2. TFS4JIRA internal limitations. This list is constantly being built and updated as we add new fixes.

As with any known limitation list, it’s never fully complete. If you happen to encounter any problem while synchronizing please do let us know here: Support portal

REST API Limitations

Jira limitation

  1. History migration.
    History is automatically being filled by Jira and we cannot overwrite it in REST API.

  2. Empty values on select types of fields.
    There is a known limitation on the Jira side https://community.atlassian.com/t5/Jira-questions/JIRA-API-How-do-I-explicitly-set-a-custom-field-it-s-default/qaq-p/683842 TFS4JIRA creates an object and filled the field as empty. In such a case doing it via REST API breaks the sync process.
    As a workaround, we suggest creating a separate value called “None” or “Empty” and mapping it.



Azure DevOps limitation

  1. History migration.
    Same as in Jira. Cannot edit it via REST API.

  2. CreatedBy, CreateDate.
    Those fields are system fields. Only ADO can control and edit them. Automatically set up during workitem creation.

TFS4JIRA internal limitations.

Jira limitation

  1. Non-issue entities creation.
    TFS4JIRA cannot create artifacts that are not issues. This list includes components, users, sprints.

  2. Comment deletion/edition. - At this moment we do not store revision of comments and its state. Only the amount and which comment was synchronized.

  3. Meeting requirements of workflow conditions/validators.
    TFS4JIRA cannot read upfront limitations of workflow and override them. If some condition is set up on a workflow, REST API has to abide by it as well.

  4. Fill fields on transition screens.
    We use create issue screens and edit issue screens only.

Azure DevOps limitation

  1. Test cases outcomes.
    As test outcomes are not workitems and are not field values also, they are not covered by the fetching mechanism.

  2. Setting up the reason “Reason” field.
    This field is highly dependant on the workflow and preceding status.