This topic has been discussed in the past, but I did not come across any closure.
Our projects require dashboard tabs to be rendered into iFrames (via direct URLs) and not be selected from a menu. We currently use the .../ui/#!/<Tab Id> URL convention, which works well. However, the id represents the tab's position in the dashboard menu, and is sensitive to editor changes (tab reorder, empty/inactive tabs etc.). It would be preferable for us to address dashboard tabs by their name.
The ui control node does allow specifying the tab name, but as far as I know it cannot render it to an iFrame nor allow adding parameters to the URL. Another thing I tried was to resolve the id via the GET/flows admin API, but the returned tab objects do not have the id property.
In a previous thread (Here), @Nxito found a nice way to query & lookup the dashboard ids, by tweaking the dashboard's io.js source file:
This solution works well, but I am reluctant about tweaking OOTB product code (and redo it upon upgrades). Hence, I am wondering if there is any other solution, e.g.:
- Providing an additional URL convention, based on tab name
- Formally adding the menu property in the io.js file
- Including the tab Id property in GET/flows
As you are the real expert here, I'm copying you on this discussion, and will be thankful for your advice.
I know the best way forward will be to use your UI Builder (and this is definitely our plan!), but for our immediate project needs, I need to decide if it would be safe/wise for me to tweak the io.js file of the standard dashboard suite, to enable direct access by name to dashboard tabs.
Thanks in advance!
Well, I am certainly not the expert on this, that would be Dave.
However, my view would be that it isn't safe or wise except as an acknowledged, cludgy, potentially fragile temporary work-around.
But if you are desperate and as long as you have control over when the Node-RED install from npm gets updated, you may be OK.
Honestly though, I'm struggling to understand why this would ever be needed/wanted.
Have you checked something like this to handle the change in the front-end?
For what it's worth, I tend to think it would be good to address tabs by their name or an ID that doesn't change. I have been working around this for a while. But every now and then I pull up a link saved to e.g. my iphone home screen to turn the hallway lights on and I'm presented with the basement light switches
Thanks for the information.
Unfortunately, in the specific project I'm referring to, we integrate our flows with an external system. We need to give them direct URLs, which they open in self-contained iFrames. these URLs include parameters such as username, role etc., which determine the enabled functionality.
Tweaking the io.js file enables me to programmatically open a tab by name, but I guess you are right: It would be a poor practice to meddle with framework source files.
Who in the Node-red dev team is in charge of dashboard feature requests?
Hi - currently that would be me.
I'm not against this idea. Not sure we need to export the whole of the menu object though ?
pushed a 3.4.0-beta to test to master branch
(not on npm)
Thanks for stepping in. I believe the best solution is to provide an additional URL convention which opens a tab directly by name.
If the direct URL today is formatted as <host>:1880/ui/#!/<tab Id>[?...], I would hope to have an additional URL option, something like <host>:1880/ui/#!/<tab name>[?...] or similar.
If not feasible any time soon, some alternatives can be:
- An admin API which lists the dashboard tab names & Ids
- Enhance ui_control to allow concatenating additional parameters at the end of the URL
see beta - exactly as you described where may need to be <tab%20name> ie url encoded for any spaces etc.
Drat, I got confused for a second when I read that as I've just implemented a fixed tab id in uibuilder - but for the BROWSER tab, not an SPA tab like Dashboard. Too many tabs!