Since ea75da8a this is no longer necessary although the introduction
in 039ae3c19 states that this was happening and allegedly helping.
Pre-upgrade runs this as well as the cleanup audit if it's needed
manually.
Catch empty lines. A single "," will generate
an empty string instead of NULL so we are good
here. It's safe to assume we have at least one
property in the line, otherwise the data is
useless to us anyway.
From the fgetcsv() manual:
A blank line in a CSV file will be returned as an array
comprising a single null field, and will not be treated
as an error.
See: https://www.php.net/manual/en/function.fgetcsv.php
The footer commands weren't taking into account the required properties, rendering unlinked buttons where they shouldn't be (e.g. in dnsmasq DHCP ranges etc.).
Take this opportunity to clean up and improve some front-end code, including batching of enable/disable-selected API calls. The arbitrary default limit of "40" has been set based on (40 * 36-character UUID + ~150-character URI out of a 2k URI character limit).
In the controller, change how rows are collected (use getNodeByReference only for rootnode) to save some cycles, throw an error if someone tries to swap multiple records at once as that is less likely intentional anyway (explicit on/off are acceptable values) and keep simplified result output.
Reference: https://forum.opnsense.org/index.php?topic=50806.0
---------
Co-authored-by: Ad Schellevis <ad@opnsense.org>
The static option list caching mechanism is now invoked over a
nonexistant config.xm; caching no interfaces for the "*" static
options key. In order to fix that add a reset for the list.
Would be nicer to move reset to BaseListField since a number
of fields use the static option list for caching but they all
define their own.
The tests aren't complete but they do cover parseReplaceSimple()
in its latest form so that's good enough.
Just as a note the tests are designed to be render-agnostic so
that we always start with our rule input and produce pf.conf
compatible rulesets with the tests. There are two purposes here:
1. Catch regressions when parsers are changed and that also includes
switching the parser implementation completely in the future.
2. Make sure that the files are actually compilable by pf.conf and
this should be covered later (the conf files are there on the
disk for that purpose).
This is the right type of testing for the purpose since the pf.conf
syntax is virtually static and will require little maintenance.
Just needs a lot more coverage for the missing features/rule types.
When uploading a file results in validation messages, add a download button to dump the results into a csv file as well.
Since our javascript code doesn't translate very well, only add an icon and skip the title text for simplicity.
The test already revealed an issue with the refactor:
replacing "any" with "" and then "" with "in" is not in
the interest of the inventor. Fix follows.
Only support %s and %% using preg_replace_callback() and throw
3 distinct TypeError cases making sure the resulting command is
the dummy command then.
We're not overly interested in how well escapeshellarg() works,
but we ensure it's being called always.
* Firewall - Rules [new]: Add all rules option to interface selectpicker and select it by default
* Interface select default only on null or no match, not on empty string
* To fix URL hash weirdness, it's best to special case __floating and __any in the frontend
* Lower diff in controller by folding null case into is_if
* firewall: tweak the interface selector
Show group name and description. Could be inconvenient when
the description is long, but better for the auto-groups.
That also removes the hint at the end. See note below.
Use fixed width logos for the interface groupings.
Remove muted from the any selection.
TODO/Remarks:
The groupings being shown as muted is a bit inconvenient also
as it muddies the perspective of what this does and how important
it is. Would be nicer to not have it in this particular selector.
When an interface is selected it would be perfect if the grouping
icon would show so people see better what they selected. Coloring
is nice so that would take it to the next level.
Badges with rule counts are not overly nice in front of the selection
and also don't update on rule delete. While it's nice to have this
the question is if this is really needed. A counter already exists
when clicking on them (Showing xxxx).
---------
Co-authored-by: Franco Fichtner <franco@opnsense.org>
