firewall: automation: Explore UI possibilities (POC) #8367
Comments
…uence to auto number field and require uniqueness, split view from filter.volt to filter_rule.volt to test things without causing regressions in other controllers using the same view, construct form with almost same layout as old firewall form hiding most options under advanced that are not needed for creating basic rules, for #8367
…stination and interface. Append icon column to grid. For #8367
…me as the legacy firewall view. For #8367
…es with each other. Change position of the source and destination inversions in form. Replace Port and Sequence labels in Grid view to safe space. Ensure sequence is always ascending and cannot be sortet. For #8367
…the sequence. Animate sequence change. Display Change message on sequence change. For #8367
|
I'm not sure if it's the correct move, to switch a feature which is intended to act as an api endpoint to a UX / UI rewrite of the old rules. In complex setups you need some kind of scripting and automation like with ansible to add rules. There is no need to have a nice look at those rules on the end system, as they are managed by some other instance like ansible or puppet. It would be smarter to rewrite the old ones from scratch of clone the automation base. |
|
@mimugmail Eventually you would like to have only a single view on the rules, but adding an api layer on top of the legacy rules will have a higher regression risk and duplicates the things we already have. Which means its more practical to extend the existing api parts so they can serve the ui (in the same way all other mvc components do) |
|
@AdSchellevis the main problem is, that rewriting rules and taking automation as the base, make current external implementations and use-cases of automation useless. If I understand correctly, you want to enrich automations with (GUI) features so it can take over service at some point in favor of legacy rules. But when you already rely on automation rules, where it's totally clear that no human will ever add/remove/edit rules, this will break every logic. To me, the current state is perfect. You have interface rules which everyone can edit (like end customers), then you have automation rules on top of it, so an admin oder MSP can overrule things, but as a last resort end user can still overrule with floating. No automation tool can kill existing rules, no user can break automation. Imagine a corporate network with 1000 users and above, maybe there is a small network team inside which want to do daily tasks, but still, the network is managed by a MSP, so they can have preference while still IT stuff don't need for tickets to be done. :) |
|
@mimugmail the api part should be backwards compatible, there's already a ui on top of it, but very limited. It wasn't intended to act as an acl barrier to be honest. In most cases it doesn't make sense to have 2 components performing the same task, the current construct was always intended to replace the existing one (even by the customer paying for it at the time). Deprecating the legacy component will likely take quite some time and might be kept alive for quite time. |
|
Ok, my concern is that currently the ansible playbooks create rules with sequence numbers via automation. Maybe I'm wrong ... but from outside, reading the only the topic itself "firewall", "automation" and "explore UI possibilities" is the wrong approach. |
|
It starts with a poc, but the existing api calls and their meaning is certainly a valid concern (and something we're investigating). The acl boundary is just less of a concern, I do understand people might use the split approach, but that's less a design choice from our end. The intention to use this as our main firewall was always the case (see also the original ticket opnsense/plugins#1720) |
|
The unique constraint has been removed from the sequence field. |
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Is your feature request related to a problem? Please describe.
Since the legacy firewall UI pages are at some point, well, um, legacy, there has to be a replacement at some point. The most valid replacement right now is "Firewall: Automation: Filter", which uses the modern mvc framework to generate and display its rules.
The only issue with that, is the User Experience. 10 or 20 firewall rules should not be an issue, but if the view scales up to 100 or 1000 elements even, there could be usability issues.
Describe the solution you like
Brainstorm the possibilites of improving UX in that view to prepare for the future:
Prime directives:
General UX:
Move the current code to the reusable grid structure to expose all options
Ensure firewall rules cannot be sorted (would destroy consistent sequence)
Create custom formatters to replicate the old legacy firewall view as first step
Custom commands to change the sequence of a rule relative to the other rules, this needs some controller magic
Show change message when custom command was used.
Analyze the basic needs of a firewall rule, and selectively hide more fields in advanced view or auto collapsed headers inside the main form. For maintainability, having all fields in the same general form is the best.
Restrict size of bootgrid dropdown like here:
core/src/opnsense/mvc/app/views/OPNsense/OpenVPN/instances.volt
Line 97 in 7129728
Create AutoNumberField that automatically increases by 10, and not 1. This will help in larger rulesets where you want to set rules between other rules later on. If the sequence is always unbroken, youd need to move a rule up like 500 times or so after creation at the bottom of the ruleset. Increase allowed sequence to 99.999.Maybe increment by 100 per default and increase max sequence to 999.999 to leave more space inbetween rules.When cloning, the auto number field does not automatically take a new sequence. Add a button that will fill in the next free sequence.
Collect all fields that are marked as advanced, and if one of them is not null/empty, display a symbol in in the icons of the rule, and also show in a tooltip which option it is. Additionally trigger the advanced mode automatically.
The custom move up and down commands can also work while categories or search is used.
Implement a "move rule before other rule" button. Auto calculate the sequence so no micro management of it needs to happen.
Show Alias shortcut in grid
Show selectpicker with all interface names/ interface groups with possibility or multi selection, request handler to filter the grid based on interface selection. This selectpicker should be in the action bar, at the left side. To populate it, we need an API endpoint that collects all interfaces currently used in rules (also the automatic ones).
Change default pagination to e.g. 14 as default, 7 seems too low.
Solution for automatic rules visibility, maybe just another grid that uses a search endpoint to list them.
Solution for diagnostics per rule (hits etc... like the old Inspect button), maybe they can be collected from an endpoint and injected as additional columns via formatter.
Categories work, new ones can be added in "/ui/firewall/category".
Describe alternatives you considered
Rebuilding the current legacy firewall view as closely as possible with no further additions.
Additional context
This is a POC, nothing that is written here or investigated will be a guarantee.
The text was updated successfully, but these errors were encountered: