Menu
▾
▴
#271 Login changes for Apps interface
This commit allows use of standard scripts in standalone mode (App). We find it useful in extending emr functionality to tablets and smartphones using sencha and other frameworks while retaining standard login mechanism. If the list entries are not released, login screen will remain unaffected.
First thought is this will bypass the warnings to users that their password are about to expire if they login directly to the calendar (skip main_screen.php)
Second thought is what happens if you actually start trying to click on calendar UI elements on the standalone app? Are there no errors from missing the top elements like restoreSession?
Since there is no easy way for an standalone application to authenticate an user and inherit settings from globals.php, this provides a convenient entry point without breaking the security. From that perspective, all relevant user warnings and messages of the standard application will be handled by that app.
You are correct in pointing out that many links in calendar that reference frames and menu title etc will break as expected of an integrated module. True to javascript behaviour, broken links simply don't do anything. For standard release, we could provide invalid script paths as placeholders which will skip the App selection option on the login screen. Or... if someone can figure out correct way to call phpMyAdmin, that will perfect example of what an 'App' is expected to be.
Our experience for last few months:
If modules like calendar are tweaked, they are great productivity booster. One example - our users can now click on appt time to get pop up menu to set appt status and several workflow triggers through json call without a full page refresh. Another superbill app for providers allows update of codes for unbilled encounters on any device of their choice - authorizing billing of an rouinte encounter is a swipe and click operation.
Not sure I understand. If this commit is just one of many tweaks to be made in support of a new framework, I think we first need a discussion at the forest level and perhaps some refactoring of code into an object model. Otherwise it's gonna be a mess.
Rod
http://www.sunsetsystems.com/