Thanks Paul, I'll record on GH, can reproduce my end - issue
Fixed in this PR, ~pushing 0.0.9 now~ shipped 0.0.9
2 Likes
Hi everyone. Just like to say thanks for trying this out and finding issues.
It is very early days and we don't yet have tests in place to capture regressions like these so we greatly appreciate your patience and perseverance. This is a conscious choice that we have discussed. Once we reach a good level of features, we will switch track to getting a good bunch of unit and e2e tests in place.
And if you all want to see this move even faster, PRs are welcome 
3 Likes
Another small issue. The link in the Dashboard 2 sidebar is not correct. It assumes that the root url hasn't been changed. I always make sure that I've changed httpNodeRoot and httpAdminRoot on my test machine to pick up issues like that.
The link needs to take into account httpNodeRoot.
And I'm still getting the blue screen with the console error:
Thanks for the info Julian. I suspect the blue screen problem is being caused by the change of domain youve referenced for the side menu too. The UI just seeks to connect to the same domain with /dashboard/socket.io appended
v0.0.9 Thanks Joe, working now.
Just noticed that the widget size is missing from the dropdown node.
1 Like
I miss the little bubbles of content in the new slider. See picture 000
The new slider doesn't like 0. It sends "No Message Received" See image 001
Thanks @Frida. Can you open GH issues for both of those please?
For the bubbles, was definitely a plan to add it back in, still in the process of porting over all features.
For the 0, I know the problem, can get a fix in next week.
Opening GH issues for both, just makes sure it doesn't fall off my radar.
2 Likes
Any plan on the use of a different port so as to not expose the designer unnecessarily.
You can change the port from within your NR settings file to something not commonly used.
However any change will also affect your editor access (both dashboard and editor always use the same port).
That's what I'm saying. Why can't they use different ports? So as to expose the dashboard but NOT the editor. That would be the simplest way to improve security significantly.
You can't have a different port without creating another ExpressJS instance in Node-RED. While this is possible. uibuilder, for example, has an option to create its own instance so that you can have it on a separate port with separate settings. But that is an option because it does have additional overheads.
If you want to add further security, the best approach by far is to run Node-RED behind a proxy. Which is easy to do even on a limited Pi (I've done it on Pi2's and 3's). Then you can properly apply authentication and do authorisation per URL as needed.
2 Likes
I know there is very little layout code implemented so far, but can I somehow control the order of the widgets in a page?
Colin, I think if you use node-red move to front/back you can affect layout ordering however, due to the dynamic nature of node and flow deploy, the ordering gets messed up until a full deploy.
In the mean time, visual layout is something @joepavitt already has on the backlog: Visual Layout Editor Ā· Issue #30 Ā· flowforge/flowforge-nr-dashboard Ā· GitHub
I know there is very little layout code implemented so far, but can I somehow control the order of the widgets in a page?
Unfortunately not at the moment, but something I am prioritising (possibly this week) as the base is already there from Dashboard 1.0. With the addition of the Dashboard 2.0 side menu, this also gives an easy to use canvas for such control too.
This is exciting.
Could the following two issues be addressed in Dashboard 2.0?
-
Muti-user login. It will be great to be able to assign different user roles, and which tabs an user level can access.
-
Performance. Charts become very slow when data are updated more frequently due to the outdated Chartjs version (1.xx or 2.xx). Chart.js has a huge performance boost at 3.xx. Unfortunately 3.xx is not integrated into the current dashboard.
We use "template" node and ECharts to resolve the performance issue. But it would be great to use the native dashboard charts to achieve similar performance.
1 Like
1 Like
Pretty sure they are refering to original dashboard using old chart.js. that's how I read it.
Then I'm not sure what point the OP is making?
Especially when asking for it to be addressed...
If there is an effort to make the new dashboard multi-user, then an additional improvement can be made along with that. I think for that to work, each front end widget loaded would have to send a subscribe request to the backend, which would have to make some type of auth verification, and then the backend could add that to the list of subs waiting for data. Since socket-io is being used, this would not be impossible.
If that works, then there can also be a focus on only sending data to visible widgets and tabs using IntersectionObserver. i have had success using that with my dashboard ui widget to load/unload video that goes in and out of view.
I haven't looked at the new source code to see how it is structured. Forgive me if i have stated things that are already cared for. 
