File blob page: Disable Replace/Delete actions on default branch for locked file/directory

Lock feature context

In the industry there's a concept of hard locks vs. soft locks:

• Hard locks help prevent merge conflicts, but can be restrictive and potentially block team member work if files cannot be unlocked easily by the locker.
• Soft locks allow users to work while providing visibility into who has ownership of a locked file, but are not the most preventative of merge conflicts.

Our implementation of File Locking is representative of soft locks. Users are not able to merge changes into the default branch if a file/directory is locked. Users on non-default branches can still make changes to the locked file/directory on non-default branches.

This implementation is a good balance of preventing merge conflicts where it matters (the default branch), while also not blocking work on non-default branches and providing a non-blocking signal of work in flight. The restrictiveness of hard locks can be a pain point.

Problem

When a file is locked by another user, the Unlock action is not available to other users on the default branch, and non-default branches. The Replace and Delete actions are still available to users on the default branch, even though file modification is restricted to the user who has permission to unlock the file or Maintainers. It's possible to go through replacing and deleting flow, which eventually returns an error from the backend when submitting the change. This is not user-friendly.

UI state	screenshot
the unlock is disabled while other actions still available
error return on trying to update a file

Design Proposal

We should indicate the user that they cannot perform the action earlier and prevent them into running to an error. On the default branch:

Design change	Issue
Default branch updates Default branch Disable the Replace and Delete buttons for users who do not have permission to unlock a file	#516868 (closed) (this)
Commit changes modal updates Non-default branches Update the commit changes modal in the Replace Delete Edit flows to inform users of locking status when they do not have permission to unlock a file	#521439
Edit page updates Update the Edit page or related flows to inform users of locking status when they do not have permission to unlock a file	#521831

Update the File Locking docs

• Make it clear what restrictions apply to default branches vs. non-default branches. We have a lot of language that implies hard restrictions on modification of a locked file, but this is not really the case on non-default branches.
  • "When a file is locked, only the user who locked the file may modify it." This is only true if users are on the default branch.
  • "Only the user who locked the file or directory can edit locked files. Other users are prevented from modifying locked files by pushing, merging, or any other means, and are shown an error like." This is only true if users are on the default branch.
  • In the "Default branch file and directory locks" section, it may be helpful to note that users can still modify the file locally, and on other branches.
  • In "View and remove existing locks" section, it would be helpful to start this section by reiterating who can unlock a file.
• Context
  • #516868 (comment 2367468840)
  • #516868 (comment 2365137855)

Additional context

@jwoodwardgl I'm wondering if it's enabled because we allow deleting or replacing in a non-default branch. This is a bit strange though. If the file is locked then it indicates someone is working on that file, so deleting in a non-default branch still feels wrong.

I am able to delete/replace and commit to a different branch:

If this is the case, then we should probably disable the commit to {default_branch} option:

However, I personally think that we should just disable outright.