Unsticky separators
-
My info:
2.3-BETA (amd64)
built on Wed Jan 27 02:51:46 CST 2016
FreeBSD 10.3-PRERELEASEI just noticed this minor separator issue today on the latest snapshot, and I couldn't find anyone reporting it.
I think the idea of separators are a huge visual improvement and makes it so much easier to organize rules and find them quickly. Great job!
Another similar idea I had would be to be able to group rules together in order to move/enable/disable etc. them.
Anyway, the problem I found:
I created a single separator toward the end of my LAN rules, there were 4 rules after the separator (to which the separator was referring) and about 10 above the separator.
I deleted a rule from directly above the separator and clicked yes that I wanted to delete it.
The separator moved down one rule. Now there are 3 rules after the separator and one above it that used to be below it.
I clicked apply and the situation stayed the same.I then had to move the separator up one rule to its previous position and click save then apply.
I wanted to test this again, so I duplicated the rule directly above the separator (so I could later delete it)
Instead of the duplicated rule being above the separator like it's parent, it is now below the separator. I had to now move the duplicate rule to above the separator and click save then apply.
-
Yes. This is a known limitation, and one of those things that will take a lot of thought. Currently I record the row number at which the rule was inserted. If you inset or delete a rule above the separator, the numbering is off and you have to move the separator back where it belongs before saving.
An alternative is to attach the separator to a rule, then the separator will move with that rule. - But what if you delete the rule to which the separator is attached? And if you drag that rule to a new position, somehow you would need to know that it has a separator attached and drag them together.
Things are complicated by the fact that all rules are rendered on all firewall pages, but only the ones you are interested in (WAN/LAN/Floating etc) are NOT hidden.
I'm still thinking about this. I'm sure a suitable solution will come to mind eventually :)
-
I did have an idea :)
The separators are now automatically adjusted when you move, delete, ad, or multi-delete rules.
-
I just updated tested a bit and it looks like you did it!
The separators now behave like I would think they should, they don't move around anymore when deleting or adding/copying etc. rules.
Thanks!
-
Same on firewall_nat.php now.
-
I'm on the latest build, also GitSynced just now. If I copy a rule all my separators above move down one row.
-
Just pushed a fix for that. You should now be able to duplicate (clone) a rule without the separators moving.
-
Great, did a quick test and it seems to work now. Thanks!
-
With the latest version (also gitsynced) separators can't be sorted anymore. Everytime I move one the others move, too. Plus the one I initially moved always shifts by one line after pressing save.
-
-
Reboot
-
Clear browser cache. At very least Ctrl-F5.
The firewall rules page, including separators, has undergone major change. Including config version rev. that re-indexes the separators. In my testing a reboot was imperative. Likewise browser cache refresh.
-
-
Thanks, works now.
-
I just found all my separators had grouped the,selves at the top. Had to realign all of them.
-
If you obtained the latest code via gitsync, a reboot would have restored correct separator position.
-
A follow on to what Steve said.
If you realigned the separators prior to doing a post gitsync reboot, you can expect them to be out of order again after the next reboot (I think, maybe).
-
I've been updating from the web gui when I notice a new update. Sometimes I skip it and do it the next day rather than updating two or three times a day.
-
I have just completed another round of testing on the rules and separators and all seems to be well.
We did discover that the upgrade script could break things under certain circumstances, and I have just pushed a fix for that.
(NOYB: If all separators on a tab are removed, then <separators><tab>is no longer an array, so foreach() barfs)
If you continue to have a problem and are comfortable editing the config.xml file, I would completely remove both <separator>sections from that file (nat and filter)</separator></tab></separators>
-
Great. Thanks for the fix.
By the way is it normal expected behavior to require a reboot after gitsync in order for the config rev to take effect?
I get this in syslog as expected.
pfSsh.php: Start Configuration upgrade at 17:24:13, set execution timeout to 15 minutesbut only on very rare occasion it is followed by this:
pfSsh.php: Ended Configuration upgrade at 17:24:13
-
All separator issues seem fixed for me now, except one case where if I add two separators and move them into place before clicking save (before apply), only one is retained and I think it moves the remaining separator down one rule as well.
I also note for the first time that moving rules/separators around the page is very snappy now on OSX Firefox 44.0.1 which is great!
Thanks for the help!
-
… if I add two separators and move them into place before clicking save (before apply), only one is retained and I think it moves the remaining separator down one rule as well.
Earlier I was able to reproduce this. Now I cannot. I know some changes were made today but nothing I would expect to affect this.
"Nobody said this was going to be easy"
Youtube Video
-
I also note for the first time that moving rules/separators around the page is very snappy now on OSX Firefox 44.0.1 which is great!
Glad you noticed and like it. That was the reason for the change. To be more efficient by not loading all the other interface rules and hiding them. This necessitated re-indexing the separators to just the rules of each interface.
A lot of work, and a few bumps. But think it was well worth it. And it's nice to see that you noticed.
"I love it when a plan comes together"
Youtube Video
-
Found a new way to unintentionally reorder separators on my setup.
I have LAN and DMZ rules with separators. When I copy a LAN rule and change the interface to DMZ, separators move where they should not.
-
Looks like the edit/dup/copy needs some logic to grab the interface from the rule settings being submitted so it updates the separators of that interface. The logic could be a bit tricky since the float rule separators need to use the selected interface (FloatingRules). Pretty sure it can be resolved though.
If someone else doesn't get to it sooner I'll look at it in day or two.
In the meantime:
- You should open a bug report. Select Bug Database from the Help menu.
- Follow the doctors advice. If that hurts then don't do that. ;)
-
Pull request submitted:
-
Merged/tested. Thank you.