The formDataId (called form_data_id in stopadforms) is unique to all form submissions and is necessary for adding any accept/reject features. It also acts as an easy way to refer to a specific submission in the backend versus the specific submission name we generate. We should store this value in another column in both of the Synapse tables when a user comments/reviews submissions.
An example use-case: let's say a submission exists with formDataId 37, non-user-friendly name "User333333_form9838293", and user-friendly generated name "Smith - Tylenol (37)" (if user-friendly names PR is merged as is).
As the tables are now, the table would store comments and reviews under the non-user-friendly name. In order to accept/reject the submission, we would need to parse the submission name for the userId (333333) and fileHandleId (9838293), and find the submission that matches these. However, neither of these are required to be unique and the formDataId would need to be stored as the unique reference anyway.
If the user-friendly names PR is left as is and merged, the table would store comments and reviews under "Smith - Tylenol (37)". In order to accept/reject the submission, we would need to parse the submission name for the formDataId (37). We could use this directly to accept/reject.
Note: if the user-friendly names PR is changed to remove the formDataId, then we would be back to a similar problem with how the tables are now: neither the user's last name nor the compound name is required to be unique. The formDataId would need to be stored in the table.
If we store the formDataId, we would simply look up this value in the table and use it directly for accepting/rejecting, which is faster (and less error-prone) than parsing the submission name string. This also allows for ensuring that comments/reviews are attached to the correct submission in the case that the submission names are allowed to not be unique.
Aryllen
commented
4 years ago
The formDataId (called form_data_id in stopadforms) is unique to all form submissions and is necessary for adding any accept/reject features. It also acts as an easy way to refer to a specific submission in the backend versus the specific submission name we generate. We should store this value in another column in both of the Synapse tables when a user comments/reviews submissions.
An example use-case: let's say a submission exists with formDataId 37, non-user-friendly name "User333333_form9838293", and user-friendly generated name "Smith - Tylenol (37)" (if user-friendly names PR is merged as is).
As the tables are now, the table would store comments and reviews under the non-user-friendly name. In order to accept/reject the submission, we would need to parse the submission name for the userId (333333) and fileHandleId (9838293), and find the submission that matches these. However, neither of these are required to be unique and the formDataId would need to be stored as the unique reference anyway.
If the user-friendly names PR is left as is and merged, the table would store comments and reviews under "Smith - Tylenol (37)". In order to accept/reject the submission, we would need to parse the submission name for the formDataId (37). We could use this directly to accept/reject.
If we store the formDataId, we would simply look up this value in the table and use it directly for accepting/rejecting, which is faster (and less error-prone) than parsing the submission name string. This also allows for ensuring that comments/reviews are attached to the correct submission in the case that the submission names are allowed to not be unique.