[Feature Request] Favorite Functionality for navigation items

Started by binaryanomaly, April 26, 2020, 10:35:21 PM

Previous topic - Next topic
Hi,

Fortigate and other firewalls have a favorite navigation functionality that allows you to favorite navigation items that are often used which then appear on top of the navigation in your favorites section for quick access. This is very convenient and efficient.

As far as I know there isn't something like that available for OPNsense? (Aware of the search functionality)
Could this be a usability and efficiency improvement?

Cheers

It's possible to alter the menu locally by adding XML files -- adding new sections or moving entries. As far as complexity goes the concept of "just a favourites menu" does not hold up to the UX standards pretty quickly with duplicated entries being opened on the menu side because the URLs opened are the same or wether to move entries or have them duplicated, which means it is a user property which means it may clash with ACL settings as well or at least obscure them.

Apart from the feature itself, would you mind going a step back and letting us know your motivation, i.e. the pages that you browse frequently and why.


Cheers,
Franco

Not sure I understand why there should be a problem with ACLs it would only be a reference to the original page/URL in a different navigation section that is sticky at the very top.

The motivation is that I'm currently changing a lot between different pages I need often and are nested on 3rd level of the navigation for example Firewall -> Rules -> Interface Group Rules and then switching to Firewall -> Log Files -> Live View. Every time I switch the former 3rd level nav is collapse and I end up clicking a lot when this could be solved very conveniently by marking the pages as favorites and having them always displayed in a top favorite setcion.

> Not sure I understand why there should be a problem with ACLs it would only be a reference to the original page/URL in a different navigation section that is sticky at the very top.

My point exactly. Unfortunately, the programmer will have to deal with the complexity out of sight because of being "locked" into a certain way to fix the problem, even if not 100% adequate. Mind you, Fortigate et al have a number of programmers and steady sales to deal with the complexity relatively easy. For open source and volunteers this is a real world issue.

Would a link from the rules page to the firewall live log filtering for the interface only be an alternative to improving your work flow?

Also, it sounds like you don't use forward / back buttons in your browser or tabs for that matter. Is that correct?


Cheers,
Franco

After thinking about it. What I probably would want is only a way to create/edit that additional xml for the Menu System.
I'd just create a favorite Section containing links to the pages I use most frequently and place it on the very top. I can do that manually, no problem. Is there a way to access this xml from the web ui or do i need to ssh in and create/edit it from cli?

A link from the FW page to the live log would certainly be convenient but only solving that particular problem.
No I don't use browser back and forward in general anymore as it often breaks the use of many web apps.

https://docs.opnsense.org/development/components/menusystem.html

Needs to be created from the CLI, but can be packaged as a plugin for further deployment.

Base menu file:

/usr/local/opnsense/mvc/app/models/OPNsense/Core/Menu/Menu.xml

Other core menu files currently in use:

/usr/local/opnsense/mvc/app/models/OPNsense/CaptivePortal/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Cron/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Diagnostics/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Dnsmasq/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/IDS/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/IPsec/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Interfaces/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Monit/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Ntpd/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Proxy/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Syslog/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/TrafficShaper/Menu/Menu.xml
/usr/local/opnsense/mvc/app/models/OPNsense/Unbound/Menu/Menu.xml

Create your own, e.g.:

/usr/local/opnsense/mvc/app/models/OPNsense/CustomMenu/Menu/Menu.xml

Render changes after edit:

/usr/local/etc/rc.configure_firmware


Cheers,
Franco

Thanks. I created now .../Favorites/Menu.xml which kind of works.

Unfortunately every time I click an entry the menu structure below opens as well where the corresponding item is. Is there a way to prevent that?

<menu>
    <Favorites order="1" cssClass="fa fa-star">
        <FW-Aliases order="10" VisibleName="FW Aliases" url="/ui/firewall/alias" cssClass="fa fa-list-alt fa-fw">
            <Edit url="/ui/firewall/alias/*" visibility="hidden"/>
        </FW-Aliases>
        <LAN_IFG-FW_Rules order="20" VisibleName="FW LAN-IFG Rules" url="/firewall_rules.php?if=LAN_IFG" cssClass="glyphicon glyphicon-fire"/>
        <Live order="30" VisibleName="FW Live Log" url="/ui/diagnostics/firewall/log" cssClass="fa-eye"/>
        <Leases order="90" url="/status_dhcp_leases.php" cssClass="fa fa-bullseye fa-fw">
            <Details url="/status_dhcp_leases.php?*" visibility="hidden"/>
        </Leases>
    </Favorites>
</menu>


Just to quote myself from initial response: "duplicated entries being opened on the menu side because the URLs opened are the same".

You can't solve this the way the menu is built.

You can maybe stuff GET parameters into the URL to make it unique, e.g. ?favourite=yes but that will trigger implications about ACL depending on the requirements of the page. Something I noted as well.


Cheers,
Franco

Sorry must have overlooked that.

Parameters do not seem to have an effect from a first test.

Would there be a way to create/edit such an xml from the UI instead of cli?
The duplicate entry opening would probably require a functionality/parameter to suppress this behavior I guess.