Hi! I am currently creating a “Home Navigation” application for many different check sheet applications. The goal is to make it easier for assemblers to locate their check sheet application by using the home navigation application.
When creating the home navigation app, I noticed that navigation doesn’t work when the user doesn’t already have access to the app being transitioned to. It will instead send you to the change app screen.
I was hoping to remove access to each individual check sheet application and force users to go to their application via the navigation app. In that way, we can force a few logistical processes in the navigation app rather than implement the same processes in each check sheet app.
I was sure that the function worked previously, but it is currently no longer giving access to apps that are not specifically assigned to the station or station group. Is this an intended in r279? If so, is there a way to give a station/station group access to an app but keep it hidden? Or would it be possible to allow a user to access an app if directly being referenced in a transition trigger?
@dsun The easiest way to achieve this is to remove the menu button from your apps and only allow operators to navigate by using predefined buttons. This way they will never be able to see the full list of apps that they truly have access to.
I am more curious to why and when this change was made. I am more surprised and confused why station and station group app assignments are required for someone to transition to an application. Previously, there was no control on what apps users can transition to, but only what apps users can “Change App” to from the menu button.
Is this an intended change to Tulip? I couldn’t find the change in documentation. Many of our apps that were built around the idea that apps not assigned to a station can still be accessed were affected so I want to make sure that this change was intended before I make any changes.
We noticed these changes on r279.1 after it was deployed on our instance on 05/26/2024.
In general, app assignments on the station or group are intended as a control mechanism to only allow operators to run apps that are explicitly assigned to that station or group. If an app transition is allowed to switch to any arbitrary app, that sidesteps our intended control mechanism and has potential implications for compliance.
However, we plan to roll this out over time - this is a bug that is fixed in r279.2.
If the current behavior is the intended outcome of the station assignments in the future, I think we will try our best to adapt to what Tulip deems is the correct behavior rather than mechanize a function that will be discontinued.
I’d be interested to understand in more depth why adding apps to the station/station group doesn’t seem to be a sufficient solution/wouldn’t work. Are there certain users that require access/other steps that need to be completed prior to routing to another app?
In one of our departments, we have created about 100 different check sheet applications that individually do not have enough error checking to ensure they are using the correct check sheet for the type of part they are working on.
That is why we wanted to create a home navigation application to make that decision for them. If we could hide the 100 different check sheet applications from the user and force them to use the navigation application, it streamlines the training process of requiring them to use the navigation app and cuts out the possibility of a user going to the incorrect app.
There are also functions that we would want to implement in one app rather than in all apps. One example is creating option controlled check sheet applications. To create a working automated option controlled check sheet, we get all the “options” to a specific machine via SQL connector functions, but the triggers take a little longer than we would like. Therefore, we created a local cache of these option settings in Tulip. Whenever someone wants to work on a check sheet, we would like to compare the Tulip version to the SQL version and update the cache data if the versions do not match. We would like to avoid implementing this function in every application, therefore forcing a navigation application will also force this update to be done by default. If we disallow users from being able to access the check sheet applications from the menu but allow for transitions from the navigation app, we don’t have any issues with users starting an application with an old version of the option settings. This ensures that the data being worked on is always “live”. Having to implement this function across all our check sheets would be tedious.
I have the same setup that @dsun is describing in his post. We have a “menu app” call AppDock which is the only app assigned to the stations and is acting as the Change App menu for all users.
I do this as the majority of my apps require a serial number of a part to be “passed” to them as they launch. If the apps were launched directly, they would not know what part the operator is working on. As @dsun mentioned I’d much rather build all the select part logic and checks into a single app versus the 100+ process/work instructions apps.
If I’m reading this post right it appears that in r279.2 my setup will stop working as I haven’t explicitly assigned all of the apps to all of the stations. Is this correct?
@jakerigos, Oddly enough I appear to be partially affected by this now. I have a user that keep trying to open an app (via transition from AppDock) and it immediately kicks him out to the Change App screen. I was going to put in a support request but maybe its related to this update?
There is a bug in r279.1 that caused the issue in the thread - that is not the intended behavior.
Long term (6 months+ at the bare minimum), we want to move away from having stations access apps that are not explicitly assigned to them - it doesn’t make sense from a permissions perspective.
Before that happens, we need to find all the edge cases and will work with folks through this.
The takeaway: don’t worry, we aren’t changing this behavior yet and will offer options.