Versions Compared

Version Old Version 1 New Version 2
Changes made by

Sofie Rosinska

Hung Techlead

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Requirements:

  1. Be able to assign an SQL DataSource Table as the primary source of truth (source of most up-to-date TGNG data)

    1. Update the Jira CUSTOMFIELDTABLE DB value according to the DB Table value (On Issue load and API access event)

      1. check if JQL search and Jira Issue Export trigger any of our methods (pull data periodically to keep the Jira version fresh?)

  2. The feature should be an extension of the Data Mirror functionality

    1. Add a button to allow users to pick whether they want the Data Mirror table to be the source of truth

    2. Add a checkbox labelled “Treat DataSource value as primary during sync (overwrites Jira value)” (or other wording that would sound better)

Use Case (Data Flow):

  1. The user defines an SQL data source

  2. In the Grid config, the user sets up Data Mirror and checks the box to make it the primary storage

    1. An info panel with table handling restrictions is displayed (Do not change the table schema or it will break)

    2. A checkbox is presented labelled something like “Treat DataSource value as primary during sync (overwrites Jira value)”

  3. Any pre-existing data is mirrored to the DB Table (as in Data Mirror)

  4. Any changes in the DB Table after that are reflected on Issue View and when REST API is called

    1. If an error occurs because of DB Table data type incompatibility (or any other SQL-related data), the error message should include that information

  5. Any changes by the user (on issue or via REST/Java API) are first reflected in the table and then saved to the default Jira storage

    1. If the save is not possible due to the change in the DB Table, an error should be displayed detailing the cause

  6. The JQL search is using the most up-to-date values that are taken from the DB Table

Plan of action:

  1. Check how TGE handles a similar functionality

  2. Implement a naїve version of the functionality (always overwrites on sync, doesn’t handle getCustomfieldValue, etc.)

  3. Validate whether all of the points in the Questions are relevant to the actual behaviour of the Grid in that basic implementation version.

  4. Write potential answers/suggestions to the questions with some detail on the implementation.

  5. Get approval on the clarifications from Questions

  6. Agree and document the timescale of the full implementation, and add it to the overall roadmap.

  7. Implement a more thorough version of the functionality

Questions:

Question

Does this functionality need to be present on Cloud as well as on Server

How the TGE manages the getCustomfieldValue call from Jira’s own API? Do we provide the data pulled from the table on that call? Is it a Service that TGE exports?

How will the Row ID be handled when new rows are added on the DB side and not through the regular means (manual, API)? Does the ID get generated when the data is loaded into the Jira Grid view? Does it get generated automatically?

Does the DB data overwrite default rows automatically on issue-create if the user enters a non-existent Issue ID first and then an Issue with that ID is created?

If the DB Table sourced rows contain non-standard Row IDs, do they get transformed and re-inserted? Can we make the correct format of the Row ID be populated on the SQL side?

Should we use a different format for Row IDs that are primarily stored in a remote DB?

Should the case of initialising TGNG from a pre-existing table be supported?

Do we handle Attachment columns by just storing the Attachment ID?

Do wrong/non-existing Attachment ID values get ignored or do we add a custom error? Does the same behaviour apply to wrong/non-existing values on User/Multi/Single-select?

If the connection to the DB is lost temporarily, do we lock the Grid from being edited? Do we block it from being viewed?

If the Grid remains editable, do we sync the data after the connection with the DB is restored? How is that handled given that the normal behaviour in this case is that DB data overrides Jira data, since DB is the primary storage?