Rule Separators

[mimugmail]

Referring to what bimbar wrote, what do u guys think of this:

Instead of having the small dots, maybe the category colors could instead be used as background color shades in their respective rows? I haven't looked at any of the code yet, but i (perhaps naively) assume that's not a big change, with very little additional risk of maintenance required down the road.
This might already give a big boost to visibility, don't u think?

/e: rough idea just quickly F12ed together. Please ignore that i messed up source/destination settings in some my example rules :-D


/e: and here's the same with some readability improvements around the first icons just to demonstrate how this problem from the 1st screenshot could be circumvented:


If there's enough positive feedback, and perhaps a hint from the core team whether they would be willing to pull such a change in, i'll try to craft a PR

The problem with this is that a rule can have multiple categories. Still, only being able to have one category would be a worthwhile tradeoff, I think.

I also like the idea with the hierarchical rule groups.

Thats exactly the reason why there are colored dot's to have more categories for one rule:

[mimugmail]

Sophos UTM has the groups with the background which does a good enough job of separating the rule groups.

The small dots in opnsense don't quite do it as well.

Above all rules there's a dropdown (multiselect) for categories which does the same as UTM.

[Fright]

I’m not sure that I understood correctly and whether there is a benefit in this (in my opinion, the existing filters are more than useful), but are we talking about something like that?
https://user-images.githubusercontent.com/36099472/151666001-dc546b80-dde4-4976-9cce-8c4bd9c71133.mp4

[mimugmail]

This looks beautiful

[marcquark]

This looks beautiful

Agreed, BUT it might cause confusion because a single rule can appear more than once.

The fact that categories aren't a 1:1 relation (didn't know that before :-D) makes it somewhat difficult to visualize them in an intuitive way, the coloured dots are accounting for that fact, the other solutions aren't.

Guess this is a never-ending dilemma?

[mimugmail]

I only see progress here but the fact that it can appear more than once might confuse, yes

[Fright]

@mimugmail thanks!!    (you dragged me into it  it's fun, thanks)
@marcquark yep, but I like the idea of multiple categories per rule and in this case I think it's more correct to display the rule in each group. but that's why I suggested it for discussion (maybe someone will suggest another way to display)

[marcquark]

You're absolutely right, not displaying them under each category would add even more layers of indirection between what the eye sees and what the packetfilter actually does - they should definitely be displayed under every category.
I like your solution visually, and in the end it's up to the user how they choose to use categories. Maybe it's best to display a "here be dragons" warning when the view is opened for the first time or so?

There's another thing that springs to mind though; your representation mixes up the rule order visually doesn't it? Because it first "sorts" by category and then by actual rule order. That's something that would probably need some more thought aswell

[franco]

Well, rule reorder does have to be disabled for this to make sense. Whether or not categories/tags are given on overlapping rules is up to the user.

This is smart use of what we have already built in. This might be more of an UX issue than technical after all and depending on the technical approach all have their upsides and downsides so it looks like it comes down to preference on which side of "rule separators are what we need" one might settle.


Cheers,
Franco

[chropnsense]

My 2c goes to copy how Fortigate or Forcepoint have tackled the "presentation layer issue":





Able to hide/expand and group rules as above is extremely helpful when you have plenty of rules (example you have many VLANs and "zero thrust" approach between the VLANs and servers/services)

I usually "design the rules sections" per VLAN (ex VLAN for OfficePCs, ProdPCs, Printers, MGMT, IoT, RnD, WiFi, Automation etc) and then quite often a own rules section per server. And if the firewall allows it, also different IPS per VLAN or server depending on its function.

HTH

[Fright]

@franco

Well, rule reorder does have to be disabled for this to make sense

sounds logical, thanks! if it develops, I will definitely take into account

variant with movement buttons disabled and rule numbers added to reduce confusion with duplicate rules:

[marcquark]

@Fright is it strictly frontend work that you're doing to achieve this?

I'm wondering because, since there are clearly good arguments both for and against change to the product in this regard, wouldn't it also be an option to make a browser extension that handles it? That way it's decoupled from core development, and there's room for creativity.
One user might use categories strictly 1:1, in which case a colorization like mine could work really well. Another will be happy with your solution, and a third will want to keep things as they are. Putting all the different options into Core and making it configurable is probably too much. Choosing one option over the other will only satisfy a portion of the users. A plugin with different modes of operation can serve everyone, can be maintained independently by the community and the devs won't have to bother with compatibility at all

If you feel like that's a viable option HMU with a PN, i want to contribute

[Fright]

@marcquark
this can definitely be done entirely on the frontend (all the necessary data is already on the page) imho. but to reduce the DOM manipulation, I made small changes on the backend (added a hidden column, attached category data to the category filter select). the rest on the jQuery.
the full solution will require some additional work to make it work on the NAT rules pages as well (haven't looked at any other backend changes yet).
I don’t know about the browser extension, I’m unlikely to find time for this. if the proposed idea is developed, I will post the code on github for discussion

[bimbar]

I’m not sure that I understood correctly and whether there is a benefit in this (in my opinion, the existing filters are more than useful), but are we talking about something like that?
https://user-images.githubusercontent.com/36099472/151666001-dc546b80-dde4-4976-9cce-8c4bd9c71133.mp4

This is very nice. I want it.

[chropnsense]

@marcquark

the full solution will require some additional work to make it work on the NAT rules pages as well (haven't looked at any other backend changes yet).

If much trouble, adding this to NAT section is not IMHO necessarily. Usually NAT rules are not that many so a rules list straight up and down is OK.