Content Comparison

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

Hung: There is no restriction so I think we can do for both

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?

Hung: We keep auto_increment ID on both side, and use another field “UUID” to manage the data to synchonize.

With the data save from FE, we can use library like uuidv4

WIth the data save from database, we can use function UUID() from mysql

CREATE TABLE MyTable (
    id INT AUTO_INCREMENT PRIMARY KEY,
    uuid CHAR(36) NOT NULL DEFAULT (UUID()),
    name VARCHAR(255),
    age INT
);

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?

Hung: the same answer as above

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

Hung: UUID is an option that I suggest

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

Hung: Yes, that is also a case that Francis suggest when we talk about bulk import

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

HUng: Tested on current Data Mirror function, it will save the Attachment ID with the value property

Image Added

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?

Hung: With the current behaviour, it will ignore, so do User/Multi/Single-select. But to make it more effective, we can display a #error like Excel

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?

Hung: To simplify the process, we can display a warning to notify users when the data is not synchronized correctly. Additionally, we can provide a "Re-synchronize" button, which, when clicked, will fetch all the data from the database and replace the current data in the UI grid. This approach ensures that the database acts as the primary source for synchronization.