ShareView remake

[SofiaSazonova]

Feature or Bugfix

• Feature

Detail

• Share View page is reorganised. Now all important info is on one screen.
• Red reminder to submit the draft
• Upon submission, the modal window is shown, where user can revisit the share

Relates

• Refactor access request UI flow to avoid draft shares #1009

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.

[SofiaSazonova]

[SofiaSazonova]

@dlpzx @zsaltys have a look

[zsaltys]

@SofiaSazonova @dlpzx @noah-paige I think perhaps this is an improvement but I think we could do better...

I think draft shares should not exist at all. A share either exists as submitted or doesn't exist at all. I don't see any value in draft shares and I think they they just serve to add confusion. I think we should rework the graphql endpoints to allow to submit a share together with all the items selected. This would be more work and you couldn't reuse likely the existing UI components but it solves a lot of problems we're trying to work around: putting reminders in red text, adding more modals and buttons to click. I see this modal + red text as bandaging over symptoms vs solving the core problem.

if you really insist to keep drafts:

1. Please make role name LONG so you can see how it affects the UI.

2. Revoke/Verify/Re-Apply should not show on draft shares.

3. It would be nice to remap Your Role to Approver and Requester and not ApproverAndRequester

4. Put on the title Draft share object... as one more cue visual reminder this is a draft.

5. Rename the Submit Share in the modal to Review Share... I really don't like this modal because it feels an annoyance to the user who knows what they are doing and now has to click more buttons.. It's not a nice experience.

6. Showing status the submit modal only makes sense for drafts.. but it makes no sense to show status on the modal because the status can only be PENDINGAPPROVAL... we can show it but there's little value for it.

7. Change the button on the Request Access modal to "Create Draft Share"

8. Remove the request purpose on the request access modal and then it makes more sense to set it on the submit modal and it will be a bit more clear why the submit modal exists..

9. When creating a share from a TABLE item in the catalog do not automatically preselect the table but leave no items selected to force users to think through what they need to select on the share items..

[anushka-singh]

I agree with Zi. It would be preferable not to encounter an additional page after navigating through the request access modal. I suggest that upon clicking the lock button on a dataset, the user should be directed either to a request access modal or a share page. Here, they should be prompted to fill out all the details from the original request access modal along with the current share page options, such as selecting share items. Having two pages solely for submitting a share request seems unnecessary.

Additionally, if we opt to retain the draft stage page, we should implement the steps outlined by Zi. I particularly emphasize step 7, where instead of a submit button, we should display a "Create Draft Share" button. Subsequently, upon someone clicking on this button, a red pop-up notification should appear at the top right, indicating that the draft request has been submitted and prompting the user to complete the rest of the form to finalize their share request."

[TejasRGitHub]

Hi @SofiaSazonova , the sleek UI looks nicer than the earlier one.

Adding to the comments from @anushka-singh and @zsaltys ,

1. I would suggest having the submit button at the end of the UI ( like how it is when we create an IAM role, etc in AWS) . This way the user goes from top to bottom and also ( hopefully 😄 ) sees the share items section.
2. Just above the submit button, there can be a small banner which provides a note about how the user should proceed with with this share. Maybe here we can mention that the user needs to select atleast one share item and then submit the share request.
3. If possible ( as a stretch ) if the user is a requestor , we can show another banner telling the user about how the share request will be approved by someone from the approvers team. If the user is an approver, then we can display something like , Next Steps : by clicking on approve, you would create a share for items {} , if you do not wish to share then you can reject the share request
4. I really liked the way which Anushka described of how after clicking the Catalog's lock icon , the user is taken to the shares page. Additionally , I would suggest that we should replace the lock icon with some text maybe or a better way to let the user know about how the share request should be created.
5. During the share creation process, as the consumption role is an optional field, it creates confusion amongst first time users. Maybe we could design that modal such that after selecting the environment, they could take action as to if they want to create a share on the team role or want to select a consumption role ( if its available in that environment )

[SofiaSazonova]

@zsaltys @anushka-singh @TejasRGitHub Thanks for the feedback!
I will review the workflow once again and will try to fulfil you requirements without dramatic changes to the current procedures.

[dlpzx]

In addition to the above comments:

• The main downside to keep an eye on when simplifying the workflow and avoiding the draft state is the triggering of the shares tasks. Requester submits item1, then item2, then item3. Approver approves the share request right after item2 --> we need to ensure that item3 is not shared. I have not looked at the code but we do queries based on the item status so I guess we could run into that situation
• Small thing: when submitting a share already SHARE_SUCCEEDED items do not matter. In the case of having many many tables showing already shared items can be confusing
• Do we need to show consumption details in any way? For the work in Create generic shares_base and s3_datasets_shares modules from current dataset_sharing #1283 it is better to encapsulate any detail in the item table (e.g. for Tables we show target db name/tablename, for Folders the s3 access point name)