We make use of the special .sysconfig files to open specific forms and records. This works fine on some PCs; Double-click the first .sysconfig file and epicor opens with a login prompt. Users logs in and the form and records is opened. Double-click the second file and on some PCs the required form opens and displays the record. No login prompt. Only one Epicor.exe process running.
On other PCs this doesn’t work. Epicor prompts to login again on the second shortcut.
We use sysconfig shortcut files in a similar way to open specific records. We are having the same issue where sometimes the shortcut opens in the current session and sometimes it opens a new session.
I’ve done some testing and from what I can tell if the user has Epicor open with the classic menu or shell menu then the sysconfig shortcut opens using the current session (desired behavior). If they checked the kinetic home page box when logging in to Epicor then a sysconfig shortcut will always open a new session (not desired). If they are not allowed to have multiple sessions then they are kicked out of the original session when the new session opens (potential for data loss). Here’s the error that comes up when they get kicked out of the previous session:
I’m still relatively new to the app, and really have a user-based knowledge of web architecture…my way of thinking would be that .sysconfig files go away, and all that should need to be shared would be a parameter-based URL to take you to the page (and force a login if you’re not already in.)
Where I get lost is Epicor’s object model in a web world. Now that we’re spoiled with ‘open with’, my teams would not accept a web-based application that didn’t allow separate open (but linked) browsers; all ‘open with’ clicks would need to open a new browser, but remain tied to the originators and auto-refresh on changes. Would this be some type of local cookie chaining, or would it need to be handled and maintained by session server-side?
