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
• Edit and Submission buttons call the Modal window for share editing. User can save share as a draft or submit it.
• When request is created from Catalog, the modal window give user the form for share editing and submission (or draft).

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)

[SofiaSazonova]

• Share View page is reorganised. Now all important info is on one screen.
• Red reminder to submit the draft
• Edit and Submission buttons call the Modal window for share editing. User can save share as a draft or submit it.
• When request is created from Catalog, the modal window give user the form for share editing and submission (or draft).

[SofiaSazonova]

[SofiaSazonova]

@zsaltys

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

Long role names will be croped by the width of the line and "..." will be added. Full name will be available in the tooltip.

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

"Revoke" is now shown only in Edit window. Verify and Reapply are still useful in drafts: share could be previously approved and processed. Then, it was drafted again, but previously shared items still can be diagnosed and reapplied if needed.

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

There are some 'backend strings' that I would love to rename as well, but I will keep for separate PR

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

Good Idea

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.

Now the share can be submitted as soon as it's edited, so usually the user won't have to use this modal. I keep it as it is for now.

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.

Now the status is shown, because we have one editing table for all items

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

Good Idea

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..

I keep it now in both places, for i don't want to break the already established ways users can be accustomed to.

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..

In current workflow, user will see right away, what is selected.

[SofiaSazonova]

@TejasRGitHub

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.

Now, it's there

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

It's not really a UI change, but more the workflow change as well. We can discuss it separately and create a separate issue

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.

Now we can do the whole share submission from catalog page in modal window.

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 )

Good suggestion. I don't want to overcomplicate this PR, but this option definitely needs some clarification in UI

[noah-paige]

Hi @SofiaSazonova - think we are getting there but found a couple issues when playing around with the UI and testing locally:

[1] Does this work for Dashboard Shares via requestAccessModal?

[2] If already have a share and open a share request from catalog for another item via RequestAccessModal

• Issues
  • Updating request purpose of first step (i.e. step 0) does nothing (maybe remove?)
  • If Share Status is Submitted and then I “Include” a new Item
    • The Share status remains “Submitted” after I add the item
    • But when I click “View Share” it is actually of state “Draft” (a similar finding is below with editing directly via ShareView)

[3] When I have a share in submitted state with 1+ items

• I then click on edit from ShareView and add another item
• Issues
  • When I add a new item my options are then only to “Cancel” (no functional issue but a bit confusing that no other button)
  • When I click out via “Cancel” - ShareView is not updated with latest status (would be changed from Submitted to Draft because I added a new item)
    • Additionally should we have a way to add items and immediately re-submit (i.e. no draft) from the ShareView Edit Modal?
  • I can not edit purpose because the only button shown for this share edit view is “Cancel”

[4] From ShareEditForm opened via ShareView

• If status Share_Rejected - it says “Wait until this item is processed”
• But I can delete from Shared Items table in Share View which I believe is correct since this is separate from a revoke of an existing share

[5] From ShareEditForm opened via ShareView

• When Revoke there is no loading view from UI after first click of Revoke
  • I can keep spamming Revoke button and likely break something (no way to know something is happening)

[6] From ShareEditForm opened via ShareView

• Pagination does not work if over 10 items

[SofiaSazonova]

@noah-paige

1. About Dashboard Shares. It should be the same as it was before. Isn't it?
   2, 3. I must have missed something and share is not reloaded.

About this

But when I click “View Share” it is actually of state “Draft” (a similar finding is below with editing directly via ShareView)

It actually the way it was before. If share is already exist, we don't change the request, just load the old one. I'll think. how to let user know, why is that so.

Also, I will rename “Cancel” -> "Close"

4. Hm, I was overwhelmed with the state machine))) I'll fix it.
5. Acknowledged. I'll fix
6. Hm...Does it work in Share View? I'll create so many items to test it's better.

[SofiaSazonova]

1. Purpose texfield moved to second step of edit form
2. Request purpose can't be edited, when request is already processed or approved. This button also disabled in ShareView
3. Reject Purpose can be edited only in statuses Submitted or Draft
4. Share_Failed added to possible statuses for deletion of item
5. Submit button is disabled if there is no items
6. Button to Save&Close when it's not draft. When the request is saved, the share is reloaded, edits are saved

[noah-paige]

Thank you @SofiaSazonova for all of your work iterating on this PR

---

Overall - the process of opening up a new share request is much approved with these changes and will become a more streamlined process.

An Important Remark(!):
With this PR it will not be possible to revoke a list of items in a share object but rather revokes will happen one at a time per share item

• Enhancements we can look into for future releases include - (1) adding search / filters to make finding objects to add or to revoke simpler, (2) enabling revoke on a list of items, or other ideas as well

---

Please take a look at the latest and if no additional concerns I will work with Sofia to get this PR approved and merged in the next day or two
cc: @dlpzx @petrkalos @zsaltys @TejasRGitHub @anushka-singh

[anushka-singh]

Thanks @SofiaSazonova for all the work on this PR!
The changes already look much more user friendly. I found no issues in the code, but I was just wondering if it would be possible to get newer screenshots after the final changes have been made so we can review it easily?

[SofiaSazonova]

@anushka-singh here you go!

[anushka-singh]

Originally, the Request Purpose box used to be on the "Request Access" page. I see now it has moved to Share status page. Is there a reason for that? I think it made sense to have it on the "Request Access" Page along with the other fields that needed to be filled out.

[noah-paige]

Originally, the Request Purpose box used to be on the "Request Access" page. I see now it has moved to Share status page. Is there a reason for that? I think it made sense to have it on the "Request Access" Page along with the other fields that needed to be filled out.

Before we had the Request Purpose box on both the Request Access initial page (opened from Catalog) and the Share Edit page (opened as second page from Catalog or from Edit button on ShareView)

IMO - It felt less intuitive to have the edit on both pages and I thought it would be best to keep the text box in on ShareEditForm because that UI view is used in both places making it far more accessible for a user to edit this field

Also the Share Object gets created on the first "Request Access" page (opened from Catalog) but if the share object already exists it just gets redirected to re-use the existing share object. Currently the logic we have in backend would just return the existing share object as is and not update the request purpose if one provided as well. Instead of adding more one-off logic to backend and additional conditions, it seemed best to clean up frontend views in this case

Let me know if I missed anything in the above rationale @SofiaSazonova

++ If we can merge latest from OS main to resolve the issue with npm-audit GH Workflow check

[SofiaSazonova]

@noah-paige done)

[anushka-singh]

@noah-paige
Thanks for addressing this. I like that we modified the frontend instead of adding more clunky code in the backend.
IMO I would still like having request purpose on Request Access page.
As a user, when I create a share request, I can put in my reasoning for requesting resources and the approver will be able to see my reason. However, with the latest change it sounds like the user will have to first create a share request and then go to edit the share request and only then put a reason for requesting the resources. IMO, it should be in request access page. But its not a blocker, we can discuss it further or slate the change for later if we decide to go ahead with it. But otherwise you have my approval to merge.

[SofiaSazonova]

@anushka-singh

user will have to first create a share request and then go to edit the share request and only then put a reason for requesting the resources.

It's not quite right. The edit page (screenshot 3) appears immediately after the share created. So, just consider Request Access as step 1 and then Share fill in/edit form as step 2. No additional actions needed

[anushka-singh]

Okay! That makes sense.
Thanks for clarifying that for me @SofiaSazonova.
Let's merge it in!

[TejasRGitHub]

Hi @SofiaSazonova , The changes look really good. I was able to pull in your changes and checked the UI. The UI experience is really nice and I like that the user can create a share request on the same request modal itself.

[noah-paige]

approving and will merge - thanks again @SofiaSazonova