Review user-facing error messages to distinguish cases where it's helpful to "see Error Log for details".

We have plenty of error messages surfaced to the user in error dialog boxes that provide complete-enough descriptions w/o needing to reference the error log.

E.g.

"The start in container request was already issued on project intro. Use the stop action prior to selecting the start action.
See Error Log for details."

But there's nothing helpful to be gained from referencing the error log. It's a waste of time.

It'd really only be helpful if something truly unexpected happened..in which case someone could grab and share the stack trace.

Maybe our: ErrorHandler.processErrorMessage() function should have another flag or new method to distinguish cases where the error log isn't likely to be helpful.

Start with ErrorHandler.processErrorMessage() and trace the error dialog callers that append “See Error Log for details.” Review the user-facing messages for cases where the existing description is sufficient, then verify that the log guidance is reserved for genuinely unexpected errors and that the affected dialogs show the intended wording.