Enhance Share Health Status Verify/ReApply

[noah-paige]

Feature or Bugfix

• Feature

Detail

• Enhance Share UI for re-apply and verify share health status

Relates

• Enhancements related to UI for the share verify and re-apply feature #1107

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[noah-paige]

Changes:

• [1] Expose health status text + remove tooltip
  • Make health status text visible to user on ShareView to avoid confusion of icons or inconsistency in text size/font

• [2] Share item health status refreshes to PendingVerify immediately after starting verify task (and same with reApply)

  • This is the same as how it works for Share Item status as well
  • To note - there may be desire to design a way to update FE with changes to status in BE via GQL subscriptions or some type of polling logic. I am leaving this task open for a future issue if wanted since it is a more general scoped issue for how to handle a retrieving status updates that can be applied to share items, share objects, stacks, etc.

• [3] If item is not shared (['Revoke_Failed', 'Share_Succeeded']) then do not expose Item health status but instead show Item Not Shared

• [4] For Shares that are in pendingReApply - do not allow revokes until re-apply task is finished

• [5] Add Modal to navigate to Share View after verify share on dataset

[dlpzx]

nit: add some space between the tag and tooltip and the text with the verification time. At the moment it is really tight

[noah-paige]

I wrapped timestamp in parenthesis to differentiate - let me know if rather it designed some way else

[dlpzx]

Are we enforcing this in the backend?

[noah-paige]

addressed in latest commit and tested again to ensure revoke still works for healthy share item and throws error for PendingReApply item

For now only enforcing this check on revoke items - the more closer healthstatus and status get related - the more I am tempted to include transitions and such in the already existing state machine... for now I am leaving as is to not increase complexity / scope of this PR

[dlpzx]

Left some comments, but the feature looks good. I tested it locally.

[noah-paige]

@dlpzx The latest commit addressed you comments c9ccb16 - take a look and I will merge tomorrow if still all looks good