In fact, these simple things make the use of the resource completely unfeasible. It completely loses its usefulness.
That is why I suggested that you submit an issue.
It does not completely lose its usefulness, it does disable or hide the page when accessed via the navigation panel, which is enough for many users.
3 Likes
Just to add to Colin's explanation here - we've migrated this behaviour from Dashboard 1.0. This is the first time I've seen this requested, so will bare it in mind.
Generally the "disabled" and "visible" states refer to the side navigation for a page.
1 Like
This is a classic example of the consequences of facilitatory factors. When did you modify the links to be simpler and not big, undecorable numbers. They opened up the possibility of being remembered and accessed directly. I understand how 1.0 works, but I set up these panels for hotels, stores, hospitals and when you put the curious user to use them, they always thought more maliciously than the developers. There are many more things that I haven't listed here that are points for improvement. I'm not going to upload 1000 requests at once, I asked for one that focuses on creating several addressable outputs in the ui-template as we do in functions, this will greatly improve the flexibility and professionalism of the node. Here's a tip.
As a commercial offering to your customers, relying on incomprehensible URL's does not seem like a very safe approach. After all, you don't have to remember a URL, your browser will do that for you as will any number of other systems.
Defensive programming would be the correct approach here. Such that any attempt to reach a page that shouldn't be reachable is automatically redirected. Relying on a framework to do this seems doomed to failure at some point.
But does giving the option to disable a page and keep the URL active make any sense? Even more meaningless is enabling the page when you access the URL with it disabled. Frankly, I have no reason to cut a resource in half. The feature should be called "Hide page in bar" and not "Disable page".
It's a fair assessment - although I do want to check on your solution - how does disabling the page resolve your problem? If it's disabled, then nobody can access it?
Considering practicality, disabling a page's visibility should be intrinsically linked to deactivating the page itself, just like deactivating a group or any other aspect. When a user wishes to hide a resource, it is essential that there be no alternative way to access it, except through logical means. Therefore, I propose eliminating the term "visibility" and consolidating all options into "enable" or "disable".
It's worth noting that, like myself, many developers may incorporate functionalities into elements that need to remain operational. In this regard, I suggest integrating the option to enable or disable access, rather than focusing on the internal processing of the element.
In the case of disabling a page, the corresponding link becomes inactive, redirecting to the first option in the selection list if accessed. Upon reactivating the page, the link's functionality is restored.
Another important detail is that this functionality should be able to update the page immediately. If I disable a page in the editor in any way, it should immediately disappear from the frontend and redirect to the first page in the page selection list.
It's also important to provide instructions on how to reactivate the page. I suggest that, instead of directing to the first page in order, the reactivated page should appear in the sidebar, and a notification should be displayed on the current page, similar to what happens when the system goes offline.
It's crucial to remember this point. In the old version 1.0, when the server was offline, the page remained visually intact, with just a simple background notification of connection loss. In version 2.0, it completely loses its characterization, giving a sense of chaos in the system.
You haven't answered my question here though, what is the value of hiding/disabling a page if nobody can then access it?
Can you expand here please - Dashboard 2.0 behaves exactly the same as Dashboard 1.0 in this regard.
Ao implementar qualquer tipo de controle de acesso hierárquico no Node-RED, é essencial que o gestor tenha controle total sobre ele.
Durante esse processo, os grupos funcionam bem quando estão ocultos, mas uma página invisível com acesso via URL não tem sentido.
Se desejo criar uma automação para que uma página seja acessível apenas das 12:00 às 14:00, como posso fazer isso utilizando o Node-RED 2.0, considerando que o link está ativo o tempo todo?
Embora seja possível ocultar o grupo, a presença de uma brecha de acesso na página torna inútil desativá-la ou ocultá-la.
Quanto ao comportamento quando o sistema fica offline, está longe de ser o mesmo do antigo. No Node-RED 1.0, quando o sistema está offline, o fundo muda imediatamente e um aviso aparece no canto superior direito. No entanto, no Node-RED 2.0, quando o sistema está offline, o fundo retorna à matriz ou ao tema inicial sem título, sem grupos, apenas com cores primárias, como se estivesse carregando e não apresentasse erro.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
