Appreciate the detailed response Timothy - I'd be happy to show you what I've been working on. Still a bit of a work-in-progress but I do actually have it in a functional state - just some small nuggets for our non-developers I need to button-up.
Yes, very much 'rolling my own' but I learned substantial amounts from existing OEX solutions of course - refactored, cleaned up a lot of functionality that didn't fit with our desired workflows, and integrated my GitHub Enterprise private org App I created so the server can act on behalf of the user after the user authorizes it via OAuth2.Git is used on the server simply as the transport mechanism for the 'server' to talk to GitHub as the App but possibly removing that crutch as well long term.
Ben is correct that the window launch would be from SMP and that's where I've struggled a bit. The hooks are a lot friendlier within VS Code or Studio but the SMP side leaves me wanting - not just for these modal windows but also the general dynamic-ness of the menus.
e.g., early on I toyed with the idea of some 'short-lived branches' for our developers and having a menu DisplayName updated to show their current branch. This worked beautiful in VS Code/Studio but SMP just ignored any updates to the DisplayName essentially. The lack of consistency was frustrating so I just dropped that functionality for now.
In the scenario I'm referencing, the use would be inside Management Portal as our analysts do not and will likely never utilize a VS Code or even Studio IDE. They manage integration lookup tables within the Interoperability (formerly Ensemble) space and maybe a few other small items therein but therefore we must rely on the source control hooks to a degree to ensure we can capture their changes as well.
I agree, however, in principle and for our developers have another way to manage the 'backend' settings generally stored in globals with a nicer frontend. But nice to have a one-stop-shop whenever possible from a user-friendly standpoint (i.e., if it could be launched from a Source Control menu on the Production page within the Management Portal without being caught inside the iframe Dialog.Manager)
@Timothy Leavitt Does ISC have any plans to expand upon the server hooks further/modernize them a bit?Using a detached model of source control (i.e., non-isfs mode of VS Code w/ ObjectScript) for our org that revolves around traditional hospital/health-org Ensemble usage doesn't really work well, in particular with our analysts that aren't developers in any sense but still make table updates and other minor tweaks here and there within the Management Portal that fall to the source control hooks to handle.
In particular, in the UserAction space, there isn't a clean way to launch a small modal window for providing a UI to manage a user's source control settings - as the source control hooks effectively assume whatever CSP you're launching from UserAction is going to show a document that needs to be 'controlled' by wrapping it in an iframe managed by %CSP.Portal.SourceControl.Dialog.Manager or similar.
I have figured out ways around this but it's kind of clunky. So hopeful may we could launch our own Angular page from UserAction so we can control the dialog size, UI, etc. (and maybe there already is an undocumented way I just haven't dug further enough to find yet.)
Log in or create a new account to continue