Firewall: NAT: Port Forward - refactor to MVC (work in progress) for https://github.com/opnsense/core/issues/8401
Add some missing pieces in the controller layer, use shared getCategoryColors() and getNetworks() to render gui information in the same way as the filter page does.
Use a volatile field categories to keep track of uuid's so we can reuse these easily for matching in our selectors and data.
Firewall: NAT: Port Forward - refactor to MVC (work in progress) for https://github.com/opnsense/core/issues/8401
Add a model wrapper around nat/rule and align filter code to generate the same output when using the model.
To test this part, make a copy of /tmp/rules.debug, run migrations (/usr/local/opnsense/mvc/script/run_migrations.php) and execute rule generation via /usr/local/etc/rc.filter_configure
A diff between the newly generated rules.debug and the backup created earlier should show no differences.
The following notes apply:
o ipprotocol and protocol have no defaults set as old frontend code didn't enforce this, we should likely set defaults (inet, any) knowing this will show a small diff in the output
o registerForwardRule() replaces the array_merge with an !empty() compare per field as our defaults are empty instead of missing
o legacyMoveAddressFields() in Rule.php assumes any when network and address are not set, which should comply with frontend logic as "any" is set in these cases anyway
o source/destinations are converted inline, using a volatile field to trigger the initial load (as only one is used, we prefer network)
mvc:model - default sort order ignore in fetchBindRequest() when sort is an ampty array (which is tabulators default now). spotted while working on https://github.com/opnsense/core/issues/8401
VPN: IPsec: Connections - prevent model caching when refering items within the same model, closes https://github.com/opnsense/core/issues/9459
Since we keep the model open during the transaction, the child nodes miss their parent when using the cached model. This commit is a variation on https://github.com/opnsense/core/commit/cbd6ea95a759e61bb9a8475b877ebdabf59141e6 and should close the loop.
One other minor problem seems to be that legacy VTI interfaces are able to inject dynamic code which does not fit regular validations. As these items are "view" only, we can ignore them during validation.
mvc: it's time to add asInt()
Switch to casing as intval() and floatval() seem to have annoying
side effects. Not sure if we use a real asFloat() or just treat
it like ints. The thing is for JSON output we have to cast to int
so this is much more convenient.
dhcp/kea: Refactor model to use BaseField helper methods (#9450)
* dhcp/kea: Refactor KeaDhcpv4.php to use BaseField helper methods
* dhcp/kea: Refactor KeaDhcpv6.php to use BaseField helper methods
* dhcp/kea: Refactor KeaCtrlAgent.php to use BaseField helper methods
Firewall: NAT: Port Forward - refactor to MVC (work in progress) for https://github.com/opnsense/core/issues/8401
Add a model wrapper around nat/rule and align filter code to generate the same output when using the model.
To test this part, make a copy of /tmp/rules.debug, run migrations (/usr/local/opnsense/mvc/script/run_migrations.php) and execute rule generation via /usr/local/etc/rc.filter_configure
A diff between the newly generated rules.debug and the backup created earlier should show no differences.
The following notes apply:
o ipprotocol and protocol have no defaults set as old frontend code didn't enforce this, we should likely set defaults (inet, any) knowing this will show a small diff in the output
o registerForwardRule() replaces the array_merge with an !empty() compare per field as our defaults are empty instead of missing
o legacyMoveAddressFields() in Rule.php assumes any when network and address are not set, which should comply with frontend logic as "any" is set in these cases anyway
o source/destinations are converted inline, using a volatile field to trigger the initial load (as only one is used, we prefer network)
System: Gateways: Group - a bit of an experiment for https://github.com/opnsense/core/issues/9442
Since 2023 we have refactored the gateways to MVC, which made ipprotocol part of the output, this eases validation a bit.
The route-to statement can either contain multiple `(if gwip)` entries or multiple `if` entries, but not combined.
This change keeps track of which entries are being added to the route-to statement and ignores the ones that can't be combined.
Let's put this to a test on master for a while.
In the long run the gateway group page should validate these situations to decrease the chance of gateways being silently ignored, but not before a migration to MVC.
