Fix EVFEVENT errors mapping to server file instead of open local document

[neerup]

Fixes #3274

Summary

When compiling a member-type action, clicking an error in the Problems
panel opened the source member on the server instead of the locally open
file.

Root cause: findExistingDocumentByName — which searches all open editor
tabs by filename — was inside the if (evfeventInfo.workspace) guard.
For member-type actions workspace is never set (only file actions
populate it), so the lookup was always skipped and errors fell through to
the server member URI.

Fix: move findExistingDocumentByName outside the workspace guard.
It needs no workspace context, so it now runs for member-type actions too,
resolving to the locally open file when one matches before falling back to
the server URI.

Test plan

• Open a source member locally in the editor
• Run a compile action that uses *EVENTF
• Verify that clicking an error in the Problems panel opens the local file, not the server member
• Verify that workspace deploy-path mapping still works for file-type actions (errors in deployed IFS files still map to local workspace files)

🤖 Generated with Claude Code

[sebjulliand]

@neerup I'm missing something here. Why should the member and streamfile actions should look for local files, since they are run on remote members /streamfile?

Workspace actions, run on local files (which are automatically uploaded before running the action), must look into the workspace, no problem. But for members and streamfiles, I don't see why they should 🤔

[neerup]

@neerup I'm missing something here. Why should the member and streamfile actions should look for local files, since they are run on remote members /streamfile?

Workspace actions, run on local files (which are automatically uploaded before running the action), must look into the workspace, no problem. But for members and streamfiles, I don't see why they should 🤔

Sorry that is Claude talking :)
We do local development and we have our own custom compile command. When we compile and the source contains errors, clicking on the error in the werrorview opens the sourcefile on the ifs instead of the local source. In our case we do alot of precompiling before the actual ibm compile, our precompile is a little dated so we copy the ifs source file to QRPGLESRC where all the processing is done and the compile is also done on that source... even if we use the &SRCFILE to have the source copied to tmp source file, it still does not open the local file when clicking on the error in the errorview...
I'm aware of the ENVFEVENT file and the record:
FILEID 0 999 000000 023 QTEMP/QSQLPRE(EG0110RA) 20260610113611 0
FILEID 0 001 000000 025 A4TTHN1/QRPGSRC(EG0110RA) 20260610113607 0
FILEID 0 002 000112 026 EYAS4SRC/QRPGSRC(CS0600RA) 20240815154742 0
The fix works and just opens the local file as expected...
Hope this clarifies...

[sebjulliand]

Oh ok, so it is related to local actions - you run them from the workspace, not the IFS/Object browser, right? 😅

[neerup]

Oh ok, so it is related to local actions - you run them from the workspace, not the IFS/Object browser, right? 😅

Exactly...