I feel like there is an easy way to do this, and I am just simply missing it. When a user logs into the player, can we set a default app that opens instead of the list of all applications published to their station? I have a series of applications that are published to a station, with a master “navigation” app that allows the user to navigate to the application they need. I decided to manage it this way as there are two applications that I need the technicians to navigate to from a particular application.
Hey @RDuke -
This isn’t currently possible, but I will write a feature request for it-
One thing that might be important to know. If a trigger is moving users between apps, that station doesn’t need to have access to the child apps. so you could just assign the parent app (the navigation app) to each station without assigning the series of apps to each station. This would make it so users could only see the hub app within the “Change App” menu,
Does this at all help with your usecase?
Pete
2 Likes
Pete,
I didn’t realize that the station does not need access to the child applications. This solved my use case, and I will move forward with that strategy. Thanks!
I can still see a benefit to the default application for those stations that might need to access other unrelated applications but will only need one specific application for most of its uses.
Totally agreed.
This concept of parent and child apps (and potentially the ability to start a child app with parameters from the parent app) is a concept that we have been stewing on for about a year, but is something that we hope to nativly support. In your usecase you could define the child apps as exclusively apps that can be launched from the navigation app, and they wouldn’t be accessible from the player menu.
This work is still in the ideation phase, so I wouldn’t expect it anytime soon, but this is where we want to go.
Pete
Pete, quick follow-up to using the parent application to reach child applications. If we do not assign them to a station, will the default always be “most recently published version”?
A very good question! Just tested and it appears to match the version of the hub app.
So-
If the Station is assigned to the most recent published version, the spoke will also launch to the most recently published version, but if the hub is assigned to the development version, the development version of the spoke app will be used.
I wrote a feature request to make this functionality more clear, because I have been using the product for years and wasn’t sure what to expect here.
Does this make sense?
Pete
I believe so. I just want to clarify, that it will match the “latest published” and not the revision number of the hub (parent) application.
Ex: The parent application is at revision 2, and the child is at revision 4, it will launch revision 4 of the child and not revision 2 of the child.
Hey @RDuke -
Just tested this case too. If the hub is set to most recently published OR any specific published version, the spoke will go to the most recently published version.
If the Hub is set to development version, the development version of the spoke will be used.
Pete
1 Like
This is a great find! I will be using this for similar instances I have come across. Thanks for asking the question @RDuke!
1 Like
Hi All,
I have a similar use case. I essentially have a home screen that i would like to be the default running application when someone logs in. I’ve noticed a couple of things.
- it seems like there was an update between this post and now that gives an error saying that its not allow from this interface.
2) when someone logs off, it keeps the last running app assigned to the station so that the next user that logs in, opens up to that app rather than my “Home” app.
Did the feature request go through for this?
~Darin
Hi @DarinLamont,
On new Tulip instances and (soon) available as an account setting, we limit interfaces to only access apps that they are assigned to.
For the log off functionality, we offer a few options (depending on the plan that you’re on) to customize the logout behavior.
Sincerely,
Jake
Hi Jake,
I understand the app assignment to the station, but we have operators and supervisors that need to switch between apps from a singular station and when they log out, and the next user logs in, it picks up with the app that the last user left off with.
I also understand that I could remove the option to log off on the other apps and just include a “home” app button which would then have the log off off button on it. But it is a workaround rather than a long term solution.
As far as the log off behavior, we have enterprise GxP instances. Are the options you’re talking about in the SAML, the Player, or the Station configuration? I couldn’t see any useful configurations related to what happens to a running app or running a default app at login. We are not currently connected to SSO, could that be why I don’t see that configuration?
Thanks again,
Darin
Hi @DarinLamont,
For the logoff option, it would be in player settings for “cancel running apps when operator logs out”. Depending on your LTS version, this may not appear as a setting, but if you’re GxP, it should be on by default.
As part of that log off process, I would include a app cancel trigger that reroutes back to your “home screen” app.
To be clear, the error that you’ve seen “the current app is attempting to navigate to another app that this interface is not allowed to run” is not related to either of the issues you are describing. The log-off and resume behavior is different than restricting access to go to another application.
Thanks,
Jake