Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-9521

Allow plugins to perform commit message and file content checks when editing a file in the browser

    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      The 'File Edit' feature was introduced in 4.13.0 and allows plugins to prevent a file edit from being committed by raising the cancelable FileEditRequestedEvent.

      The event in it's current form provides the repository, branch and the affected path, which is fine for permission-based checks. It does not however include the commit message or the new file content, which makes the event insufficient for plugin-proved checks that enforce commit message standards, or do content checks.

      Adding the following fields to the event would make the event more useful:

      • commit message
      • updated file content

      Workaround

       The File Edit feature can be globally disabled by adding the following setting to BITBUCKET_HOME/shared/bitbucket.properties and restarting:

      feature.in.browser.editing=false
      feature.file.editor=false

            [BSERV-9521] Allow plugins to perform commit message and file content checks when editing a file in the browser

            YACC receives the event, but only applies its checks when the "request.getTrigger()" equals StandardRepositoryHookTrigger.REPO_PUSH or StandardRepositoryHookTrigger.BRANCH_CREATE.

            This means YACC ignores events (even though it receives them) where the trigger equals StandardRepositoryHookTrigger.FILE_EDIT.

            Consider opening a bug in the YACC bug tracker.

            (p.s. I'm with Bit-Booster, and our competing free commit checker, Control Freak, properly checks file edits.  But we're not DC certified yet - hopefully soon.)

            Julius Davies [bit-booster.com] added a comment - - edited YACC receives the event, but only applies its checks when the "request.getTrigger()" equals StandardRepositoryHookTrigger.REPO_PUSH or StandardRepositoryHookTrigger.BRANCH_CREATE. This means YACC ignores events (even though it receives them) where the trigger equals StandardRepositoryHookTrigger.FILE_EDIT. Consider opening a bug in the YACC bug tracker. (p.s. I'm with Bit-Booster, and our competing free commit checker, Control Freak , properly checks file edits.  But we're not DC certified yet - hopefully soon.)

            So the problem already exists? Because we seee in Version 516.6 that the YACC hooks are not fired!

            Thomas Beck added a comment - So the problem already exists? Because we seee in Version 516.6 that the YACC hooks are not fired!

            Most of the changes for the new repository-hook API is included in the 5.0.0 EAP-2 release, but unfortunately the trigger for 'edit-file' is not yet included in that EAP release.

            See https://community.developer.atlassian.com/t/announcement-bitbucket-server-5-0-early-access-program-eap-release/1913 for instructions on how to access the eap2 release.

            Michael Heemskerk (Inactive) added a comment - Most of the changes for the new repository-hook API is included in the 5.0.0 EAP-2 release, but unfortunately the trigger for 'edit-file' is not yet included in that EAP release. See https://community.developer.atlassian.com/t/announcement-bitbucket-server-5-0-early-access-program-eap-release/1913 for instructions on how to access the eap2 release.

            Thanks so much for fixing this. We might finally be able to update to the new version, this Issues was the only thing blocking us from updating.

            Is there a possibility to preview the API changes in order to prepare for the release of the new version?

            Florian Peschka added a comment - Thanks so much for fixing this. We might finally be able to update to the new version, this Issues was the only thing blocking us from updating. Is there a possibility to preview the API changes in order to prepare for the release of the new version?

            In 5.0, the file content and commit message have been made available to the FileEditRequestedEvent. In addition, a new unified repository-hooks API has been added that allow plugins to provide hooks that get called before refs are updated, whenever these updates can be vetoed. The new hooks API also invokes hooks when a file is edited or created in the browser.

            Michael Heemskerk (Inactive) added a comment - In 5.0, the file content and commit message have been made available to the FileEditRequestedEvent . In addition, a new unified repository-hooks API has been added that allow plugins to provide hooks that get called before refs are updated, whenever these updates can be vetoed. The new hooks API also invokes hooks when a file is edited or created in the browser.

            I agree with Florian above – this feature needs to be integrated with existing hooks, otherwise it's nearly impossible to ensure the same workflow is enforced for inline editor commits as well as regular pushes. As far as I'm concerned the inline editing as implemented is unsuitable for anything but toy uses.

            John Jacobson added a comment - I agree with Florian above – this feature needs to be integrated with existing hooks, otherwise it's nearly impossible to ensure the same workflow is enforced for inline editor commits as well as regular pushes. As far as I'm concerned the inline editing as implemented is unsuitable for anything but toy uses.

            I would argue that the Edit in Browser feature should be treated exactly like any push to the server, invoking both pre-receive and post-receive checks as well as any restrictions applied on the repository about commits, etc - if at all possible.

            Like this, the feature enables working around existing restrictions that are there for a good reason, especially in a more tightly controlled corporate environment, where you want the luxruy of editing files in the browser but also need control over who can do what and in what way.

            Florian Peschka added a comment - I would argue that the Edit in Browser feature should be treated exactly like any push to the server, invoking both pre-receive and post-receive checks as well as any restrictions applied on the repository about commits, etc - if at all possible. Like this, the feature enables working around existing restrictions that are there for a good reason, especially in a more tightly controlled corporate environment, where you want the luxruy of editing files in the browser but also need control over who can do what and in what way.

            TLDR: It would be really nice if existing pre-receive hooks could check the commits created through direct inline editing.

             

            I really like the way this feature works with the "this branch always requires pull-requests" branch permission:

            The warning message is clear and the "[x] Create a pull request for this change" on the commit dialog becomes grayed out and forcibly checked.  It's really nice!

             

            And so I wonder if you could do something similar to simulate a push and invoke all the pre-receive-hooks, and if any fail put up a similar warning.

             

             

            Julius Davies [bit-booster.com] added a comment - - edited TLDR: It would be really nice if existing pre-receive hooks could check the commits created through direct inline editing.   I really like the way this feature works with the "this branch always requires pull-requests" branch permission: The warning message is clear and the " [x] Create a pull request for this change" on the commit dialog becomes grayed out and forcibly checked.  It's really nice!   And so I wonder if you could do something similar to simulate a push and invoke all the pre-receive-hooks, and if any fail put up a similar warning.    

            Michael Heemskerk (Inactive) added a comment - Raised in response to  https://answers.atlassian.com/questions/46812276

              mheemskerk Michael Heemskerk (Inactive)
              mheemskerk Michael Heemskerk (Inactive)
              Votes:
              12 Vote for this issue
              Watchers:
              19 Start watching this issue

                Created:
                Updated:
                Resolved: