• 
      

    Disallow users from saying "Ship It!" to their own review requests.

    Review Request #14198 — Created Oct. 11, 2024 and submitted

    Information

    Review Board
    release-7.1.x

    Reviewers

    We've always taken a pretty hands-off approach, preferring to encourage
    conversation over policy. That said, one of the most requested bits of
    policy is to make it so users can't mark their own review requests as
    "Ship It". This is not only a reasonable policy ask (especially if
    people are using approval workflows that can block pushes), but should
    probably be the default.

    This change implements that. The visibility of the "Ship It" action and
    checkbox in the review dialog are now conditional on this flag, and
    reviews will refuse to publish (either via the UI or API).

    Because a big change like this may be controversial, I've added a toggle
    for it in the admin settings, under a new page titled "Review Workflow".

    While adding tests for the action, I discovered that several of our
    existing action tests were accidentally still testing the legacy
    versions of the actions (imported via the old
    reviewboard.reviews.default_actions module). I've fixed it up so we
    have separate tests for the legacy and modern versions of actions that
    exist in the unified banner.

    • Viewed a review request as both the owner and another user, and saw
      that the visibility of the action and review dialog checkbox was
      correct.
    • Toggled the setting in the admin and checked again, seeing that I
      could restore previous behavior.
    • Ran unit tests.
    Summary ID
    Disallow users from saying "Ship It!" to their own review requests.
    We've always taken a pretty hands-off approach, preferring to encourage conversation over policy. That said, one of the most requested bits of policy is to make it so users can't mark their own review requests as "Ship It". This is not only a reasonable policy ask (especially if people are using approval workflows that can block pushes), but should probably be the default. This change implements that. The visibility of the "Ship It" action and checkbox in the review dialog are now conditional on this flag, and reviews will refuse to publish (either via the UI or API). Because a big change like this may be controversial, I've added a toggle for it in the admin settings, under a new page titled "Review Workflow". While adding tests for the action, I discovered that several of our existing action tests were accidentally still testing the legacy versions of the actions (imported via the old `reviewboard.reviews.default_actions` module). I've fixed it up so we have separate tests for the legacy and modern versions of actions that exist in the unified banner. Testing Done: - Viewed a review request as both the owner and another user, and saw that the visibility of the action and review dialog checkbox was correct. - Toggled the setting in the admin and checked again, seeing that I could restore previous behavior. - Ran unit tests. Fixes bug 4984.
    a8920586607ce182e28345cad8b7c0069daeb460
    Description From Last Updated

    continuation line missing indentation or outdented Column: 17 Error code: E122

    reviewbot reviewbot

    Maybe better as JSONDict?

    maubin maubin

    This can be on one line.

    maubin maubin

    This can be on one line.

    maubin maubin

    Missing Version Added.

    chipx86 chipx86

    Missing Version Added.

    chipx86 chipx86

    Can we put the ) on the next line, so it's more akin to how we do {} and []? …

    chipx86 chipx86

    Version Added.

    chipx86 chipx86

    Should we have a trailing period?

    chipx86 chipx86

    Missing Version Added.

    chipx86 chipx86

    Can we add tests checking these conditions for this action?

    chipx86 chipx86

    These can start on the return ( line, like the others.

    chipx86 chipx86

    Single quote string here.

    chipx86 chipx86

    Single quote string here and in the test below.

    chipx86 chipx86

    Can we check against the specific error message as well? We should also compare the full rsp instead of just …

    chipx86 chipx86

    line too long (84 > 79 characters) Column: 80 Error code: E501

    reviewbot reviewbot

    continuation line unaligned for hanging indent Column: 33 Error code: E131

    reviewbot reviewbot

    We seem to be setting one request and then creating a whole separate one for the context. Is this right? …

    chipx86 chipx86

    We're fetching the user twice. Let's do it only once.

    chipx86 chipx86
    Checks run (1 failed, 1 succeeded)
    flake8 failed.
    JSHint passed.

    flake8

    david
    maubin
    1. 
        
    2. reviewboard/actions/base.py (Diff revision 2)
       
       
      Show all issues

      Maybe better as JSONDict?

      1. This is django template context, not JSON.

        We probably should create a definition for that in typelets.

    3. reviewboard/webapi/tests/test_review.py (Diff revision 2)
       
       
       
      Show all issues

      This can be on one line.

    4. reviewboard/webapi/tests/test_review.py (Diff revision 2)
       
       
       
      Show all issues

      This can be on one line.

    5. 
        
    david
    chipx86
    1. 
        
    2. Show all issues

      Missing Version Added.

    3. Show all issues

      Missing Version Added.

    4. Show all issues

      Can we put the ) on the next line, so it's more akin to how we do {} and []? Makes it easier to edit the text without shifting that around.

    5. reviewboard/reviews/actions.py (Diff revision 3)
       
       
       
       
      Show all issues

      Version Added.

    6. reviewboard/reviews/models/review.py (Diff revision 3)
       
       
      Show all issues

      Should we have a trailing period?

    7. Show all issues

      Missing Version Added.

    8. 
        
    david
    david
    chipx86
    1. 
        
    2. reviewboard/reviews/actions.py (Diff revision 5)
       
       
       
       
       
       
      Show all issues

      Can we add tests checking these conditions for this action?

    3. reviewboard/webapi/tests/test_review.py (Diff revision 5)
       
       
      Show all issues

      Single quote string here.

    4. reviewboard/webapi/tests/test_review.py (Diff revision 5)
       
       
       
      Show all issues

      Single quote string here and in the test below.

    5. reviewboard/webapi/tests/test_review.py (Diff revision 5)
       
       
      Show all issues

      Can we check against the specific error message as well?

      We should also compare the full rsp instead of just parts going forward. I found some previously-missed problems before when transitioning code to that approach.

    6. 
        
    david
    Review request changed
    Description:
       

    We've always taken a pretty hands-off approach, preferring to encourage

        conversation over policy. That said, one of the most requested bits of
        policy is to make it so users can't mark their own review requests as
        "Ship It". This is not only a reasonable policy ask (especially if
        people are using approval workflows that can block pushes), but should
        probably be the default.

       
       

    This change implements that. The visibility of the "Ship It" action and

        checkbox in the review dialog are now conditional on this flag, and
        reviews will refuse to publish (either via the UI or API).

       
       

    Because a big change like this may be controversial, I've added a toggle

        for it in the admin settings, under a new page titled "Review Workflow".

      +
      +

    While adding tests for the action, I discovered that several of our

      + existing action tests were accidentally still testing the legacy
      + versions of the actions (imported via the old
      + reviewboard.reviews.default_actions module). I've fixed it up so we
      + have separate tests for the legacy and modern versions of actions that
      + exist in the unified banner.

    Commits:
    Summary ID
    Disallow users from saying "Ship It!" to their own review requests.
    We've always taken a pretty hands-off approach, preferring to encourage conversation over policy. That said, one of the most requested bits of policy is to make it so users can't mark their own review requests as "Ship It". This is not only a reasonable policy ask (especially if people are using approval workflows that can block pushes), but should probably be the default. This change implements that. The visibility of the "Ship It" action and checkbox in the review dialog are now conditional on this flag, and reviews will refuse to publish (either via the UI or API). Because a big change like this may be controversial, I've added a toggle for it in the admin settings, under a new page titled "Review Workflow". Testing Done: - Viewed a review request as both the owner and another user, and saw that the visibility of the action and review dialog checkbox was correct. - Toggled the setting in the admin and checked again, seeing that I could restore previous behavior. - Ran unit tests. Fixes bug 4984.
    38761bb4829261a53be2d52d8584874b355e0db7
    Disallow users from saying "Ship It!" to their own review requests.
    We've always taken a pretty hands-off approach, preferring to encourage conversation over policy. That said, one of the most requested bits of policy is to make it so users can't mark their own review requests as "Ship It". This is not only a reasonable policy ask (especially if people are using approval workflows that can block pushes), but should probably be the default. This change implements that. The visibility of the "Ship It" action and checkbox in the review dialog are now conditional on this flag, and reviews will refuse to publish (either via the UI or API). Because a big change like this may be controversial, I've added a toggle for it in the admin settings, under a new page titled "Review Workflow". While adding tests for the action, I discovered that several of our existing action tests were accidentally still testing the legacy versions of the actions (imported via the old `reviewboard.reviews.default_actions` module). I've fixed it up so we have separate tests for the legacy and modern versions of actions that exist in the unified banner. Testing Done: - Viewed a review request as both the owner and another user, and saw that the visibility of the action and review dialog checkbox was correct. - Toggled the setting in the admin and checked again, seeing that I could restore previous behavior. - Ran unit tests. Fixes bug 4984.
    c5f6bf5545f12d7b84ca4d653c5ce899c80d07bf

    Checks run (1 failed, 1 succeeded)

    flake8 failed.
    JSHint passed.

    flake8

    david
    chipx86
    1. 
        
    2. reviewboard/reviews/actions.py (Diff revisions 5 - 7)
       
       
       
       
       
      Show all issues

      These can start on the return ( line, like the others.

    3. reviewboard/reviews/tests/test_actions.py (Diff revision 7)
       
       
       
       
       
       
       
      Show all issues

      We seem to be setting one request and then creating a whole separate one for the context. Is this right? If so, we should document why we're doing this.

      If it's not right, and we want to create_http_request, that will take care of creating the ResolverMatch automatically. In fact, if we want these two separate requests, we could just let it do that and then assign the result into self.request to avoid duplicating the weird ResolverMatch magic.

    4. reviewboard/reviews/tests/test_actions.py (Diff revision 7)
       
       
       
       
       
       
      Show all issues

      We're fetching the user twice. Let's do it only once.

    5. 
        
    david
    chipx86
    1. Ship It!
    2. 
        
    david
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to release-7.1.x (0ac1560)