Conversation
… Sample and Source delete cases
|
|
||
| var confirmPage = _confirmationSynchronizationFunction.apply(() -> this.dismiss("Yes, Delete", waitSeconds)); | ||
|
|
||
| if (!skipAuditEventCheck && count != null && auditEventName != null) |
There was a problem hiding this comment.
I'm a little worried about unknowingly losing this coverage if our count or eventName calculations start failing at some point.
We should be strict when we're know we can be. Maybe make an EntityDeleteConfirmationDialog subclass that throws an error if getCountFromTitle or getAuditEventNameFromURL are null. Then switch as many places as possible to use that instead.
There was a problem hiding this comment.
I agreed. I had similar thoughts. I was hoping to put the verifyAuditEvents checks into the SampleDeleteDialog and SourceDeleteDialog for this reason but there are so many usages of DeleteConfirmationDialog directly that don't use those subclasses. Maybe we can sync to discuss this part.
There was a problem hiding this comment.
As a starting point, I added a null check to the SampleDeleteDialog and SourceDeleteDialog with this commit:
https://github.com/LabKey/limsModules/pull/1461/commits/9a0712d69e990ecb8e688e86b573d6f5d022e581
Rationale
Expanding on recent AuditLogHelper checks for audit event row/diff counts on actions like sample/source bulk update and details update, this PR adds similar checks within the test components for deleting and moving samples and sources.
Related Pull Requests
Changes
ModalDialog: Added a new methodgetCountFromTitle(String prefix)to extract a numeric count from the dialog's title based on a given prefix. This method handles potential parsing errors gracefully by returningnullif the number cannot be parsed.DeleteConfirmationDialog: Modified theconfirmDelete()method to include an overloaded version that accepts askipAuditEventCheckparameter, allowing optional verification of audit events during delete confirmation.DeleteConfirmationDialog: Added a static helper methodverifyAuditEvents()to validate audit event counts for the last transaction, ensuring consistency between the expected and actual audit log entries. This method handles exceptions and throws a runtime error if validation fails.