### Problem to solve <!-- What problem do we solve? --> We can simplify and remove complexity around visual review tool authorization by completely removing the need to pass identities back and forth between GitLab, the app under review, and the web browser of the user providing feedback. At the moment this creates security risk and is difficult to set up. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> [Presley (product designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> This is part of the project &960. It is a followup to gitlab-ee#10761. Some additional feedback from @sytses * Sid: Anyone should be able to leave feedback, just like service desk. No need to link to GitLab account. * Sid: Iterate through getting feedback first and then work on ironing out any security issues that might come up #### Current state The current state can be checked out at https://review-app-test.sarahghp.now.sh/ ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Instead of passing credentials back and forth, feedback will provided through a generic endpoint. The reviewer's browser will use this endpoint to provide a comment to the merge request under review. The user should be able to provide a name in addition to the comment. A side benefit of this proposal is that even users who do not have GitLab accounts can now be involved in the review process. The input filed for MR is required so the comment can get back to the right place if it was not automatically populated through the script in the review app OR hard coded. #### Flow >>> ```mermaid graph TD UOR(Open review app) IMI(Input merge request ID if needed) IF(Input feedback) IN(Optional input name or username, anonymous by default) SF(submit feedback) LTF(Link towards submitted feedback shown) UOR-->IMI IMI-->IF IF-->IN IN-->SF SF-->LTF ``` >>> #### Prototype <img alt="gif protototype" src="/uploads/28c5b742bf6fd9d81f851397486b0df2/CleanShot_2019-09-03_at_15.49.45.gif" width="400px"/> [click-through prototype](https://balsamiq.cloud/saotw6e/prh6nby/r2278?f=N4IgUiBcCMA0IDkpxAYWfAMhkAhHAsjgFo4DSUA2gLoC%2BQA%3D) #### State wireframes | Name | Mockup | | --- | --- | | Input merge request ID if needed |  | | Input feedback (anonymous selected by default) |  | | Input full name (skipped if feedback submitted anonymously) |  | | Input submitted and posted |  | #### Modal Instruction number 3 will be removed as it is no longer applicable.  #### Feedback comment posted At the top of the comment we need to post if this is posted anonymously: __This feedback has been posted anonymously__ If not anonymous: __This feedback has been posted by NAME (note that there is no guarantee this person is verified)__ ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> ### What does success look like, and how can we measure that? #### Acceptance Criteria 1. The flow can be completed as outlined above 1. The comment is posted back to the correct MR within 30 seconds of submit. #### Success Metrics Once the issue to track usage of the Visual Review Tool [#ee-11944](https://gitlab.com/gitlab-org/gitlab-ee/issues/11944) is completed we will measure success by number of users who utilize Visual Review Tools week over week. <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->