Script Runner File Locks Not Respected if File Opened Via URL

[shonigmann]

Describe the bug

We noticed that file locks are not respected if a user accesses a script file directly via a URL rather than through the built-in File -> Open dialog

Claude dispositioning below:

  File → Open (via FileOpenSaveDialog):
  - openSuccess() calls Api.get('/script-api/scripts/${file}') → server auto-locks
  - Emits 'file' event → ScriptRunner calls setFile(data) with local = false (default)
  - In setFile with local = false: lockedBy is updated from the response → UI shows lock warning
  URL open (?file=...):
  - mounted() sets this.filename then calls reloadFile()
  - reloadFile() calls Api.get(...) → server auto-locks
  - Then calls setFile(data, true) with local = true ← this is the problem
  - In setFile, the if (local === false) block is entirely skipped → lockedBy is never updated
  - UI shows no lock warning even if another user holds the lock
  This is a real bug. reloadFile() always passes local = true to setFile, which was intended to mean "don't unlock the old file before switching" (since it's reloading the same file), but the side effect is that lock state from the
  response is silently discarded.

To Reproduce

1. Enable script file locks in the admin console
2. Open a script via the file open dialog in one window
3. In a new window, reopen that script via the file open dialog, confirm it is locked
4. Copy the URL for the script (e.g. https://.com/tools/scriptrunner?file=) In a new window. The file does not appear locked

Expected behavior

The file is locked by the original user

Screenshots

No response

OS

No response

OpenC3 COSMOS Version

7.2.0

Browser

Chrome

[crawlchat]

The bug is confirmed. The diagnosis is accurate. Here's a clear breakdown and a suggested fix:

---

🐛 Bug Confirmed: URL-based file open skips lock state

Root cause is in ScriptRunner.vue at line 2747 and 2766.

When reloadFile() fetches a file (used for URL-based opens), it always calls:

this.setFile({ file, locked, breakpoints }, true)  // local = true

But inside setFile, the lockedBy update is gated behind if (local === false):

if (local === false) {
  if (this.filename !== newFilename) {
    this.unlockFile()
    this.lockedBy = locked  // ← never reached when local = true
  }
}

So even though the server correctly returns locked in response.data.locked, it's silently discarded when loading via URL.

---

Suggested Fix:

The local = true flag was intended to mean "don't unlock the current file" (since we're reloading the same file). The lockedBy update should happen independently of whether we need to call unlockFile().

In setFile, separate the two concerns:

setFile({ file, locked, breakpoints }, local = false) {
  this.files = {}
  let newFilename = file.name.split('*')[0]
  if (local === false) {
    if (this.filename !== newFilename) {
      this.unlockFile()
    }
  }
  // Always update lockedBy from the server response
  this.lockedBy = locked  // ← moved outside the local === false block
  this.filename = newFilename
  // ...

This ensures lockedBy (and thus the read-only lock warning) is always set from the server's response, regardless of how the file was opened, while still preserving the original intent of not unlocking when reloading the same file.

---

Could one of the engineers confirm this is the intended behavior of the local flag and verify the fix doesn't regress any other reloadFile() call sites (there are several at lines 1436, 1443, 1452, 1924, 2691)?