* show dynamic interface properties when received. To prevent additional call overhead only parse the files ifctl leaves behind in /tmp/
(merge ipv4 and ipv6 properties into the same field as the address itself should be clear enough.)
* Since we rather keeo a single link type in the overview, fallback to ipv6 when ipv4 is not offered.
ref: https://forum.opnsense.org/index.php?topic=38223.msg191234
To use the upload, create a button offering a dialog title and endpoint like:
<button
id="upload"
type="button"
data-title="{{ lang._('Import') }}"
data-endpoint='/api/path/to/import_controller'
class="btn btn-xs"
><span class="fa fa-fw fa-table"></span></button>
and hook functionality using:
$("#upload").SimpleFileUploadDlg();
Adds a spurious gateway due to presence of <gateways><gateway_item/></gateways>
but it it also begs the question why we go into legacy mode when we only have
automatic gateways so none are stored in the MVC model, which is kind of a standard
case.
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.
