Since @swhite2 was asking to make a generalized pattern I played
with the layout a bit and ended up just moving the form below so
it actually holds more settings if it has. This way the base_form
could be extended to only show a subset of settings (like enable)
but also show the full set if more settings are coming in.
While here adjust the menu structure and remove the ordering of
the VPN types since they order naturally.
Sometimes it's practical to be able to use tools like excel to modify data, in order to do this we need an import and an export option in the model.
The export seems to be quite easy, controllers and forms can easily use this with a construction like:
$this->exportCsv($mymodel->myarray->asRecordSet());
The import is likely a bit more challenging.
Fix regression in c2ea9aa303, performValidation() should return an object which is able to add new messages (using appendMessage()) as the previous Messages class did.
The complexity of some legacy modules such as the gateways indicate that it would be practical to offer something in between legacy and mvc. Normal modals require a single container to account for versions and easy access, where some legacy objects miss the container level in which case overlaying is not possible.
Without the singular container level, it's not possible to track versions and offfer migrations, but does prevent data being moved to different spots in the config.xml and break existing users of the same data.
This commit adds the isLegacyMapper() method, which is controlled by the model mountpoint using an additional plus (+) sign at the end of the mount. e.g. /cert+ would collect all items the xpath /opnsense/cert would offer and hooks them on items with the same array key.
For example, the model below would offer access to all cert items (and thus add's an uuid to them):
<model>
<mount>/cert+</mount>
<version>1.0.0</version>
<items>
<cert type="ArrayField">
<refid type="TextField"/>
<descr type="DescriptionField"/>
<caref type="TextField"/>
<crt type="TextField"/>
<prv type="TextField"/>
</cert>
</items>
</model>
In the long run this would help migrate these kind of objects with minimal risk of breakage, making a full model migration at a later moment in time easier (which requires data to be moved into a single container).
Requirement for https://github.com/opnsense/core/issues/7248
Properties should be copied 1-to-1 before we apply the required
defaults if necessary. In the previous situation this caused
required properties to be set to an empty value after the default
value had already been written to it. In the failure case we
attempt to be a bit more explicit and refer to the crash reporter.
While here, the master branch has dropped the Phalcon Messages class,
so switch to count() since this seems to inherit array type
and is therefore backwards compatible:
$msgs = new \Phalcon\Messages\Messages();
$count = count($msgs);
// $count == 0
See https://github.com/opnsense/core/issues/6389
Add simple Message class and remove "Messages" dependancy in Validation.php, which should be backwards compatible with all existing validations.
By moving \Phalcon\Filter\Validation() into validate() we're making the validation paths more explicit, if an objects implements ValidatorInterface, it uses phalcon, otherwise it's a simple BaseValidator passing messages back to $this->appendMessage().
The original phalcon Message class has additional fields we don't use, we only use fieldname for tracking purposes and the message itself.
After giving this some thought, it looks like a good idea to fix this bug anyway. There is a very small chance people combine legacy and mvc rules which contradict eachother, but in the long run this will lead to more issues. Since getPriority() skipped group priority, we'll add the same calculation as being used in db4b90d218/src/etc/inc/filter.lib.inc (L632-L638) too.
