Since setBase/addBase need a field to message errors on, its likely better to throw an exception when not able to complete the request in full (and data may not be saved).
Usage examples include writing data in other fields not being offered by the gui (for example encode data base64) or autogenerated content as default, volatile model fields can be used to make sure the hook is able to process the non-persistent data (which can still be validated separately).
1. For a floating rule with a single interface group, the interface
count and tooltip did not show when viewed from an interface rules page.
2. For a floating rule with an interface group and at least one other
interface or interface group, the entire rule did not show when viewed
from an interface rules page for which the interface is contained in one
of the interface groups.
Example usage:
<serial type="IntegerField" volatile="true"/>
The advantage of this is one can ask the user for input, validate it when offered and report back when it's not valid.
Currently only ArrayField clones fields, but since we removed the constraint to support structures inside these types (5715d82a7f), deeper structures need to be cloned as well to prevent accessing the original (template) node in the clone.
* 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
