Removed more fluff, concepts anf functionality are there.
Plugin conflict labels could probably require improvement,
but the way they work is relatively complicated, but maybe
it is only getting late.
As soon as we have plugin JSON metadata we can ship the
plugin conflict rework as well as that seems to help a lot
when recovering from strange situations (mostly development
things, but we never know).
o show updates tab log tracking progress icon
o get rid of spurious messages when tracking updates tab
o use "status" name to register the first tab
o ignore empty log messages when configd restarts
o table-condensed use everywhere padding a small td on the left
o ditch accept plugin again, users can remove them now manually
o remove fluffy wording from buttons
The plugins accept/reinstall functionality is not fully
reworked yet. There are some backend issues with it
that need to be sorted out. The general idea is to move
the buttons to the Status page to avoid clutter in the
plugins list.
Although it looks nice to return the current configured rule overwrites, it's confusing when querying items. Remove the rule overwrites and only show what's being use now, needs an apply to update.
o Don't try to cleanup single rule changes, since we can't measure the impact of the policy upfront
o Add a grid in the policy editor to show the single overwrites so the user can easily delete them if needed (small number of items isn't an issue, a lot will be)
o warn the user if he/she uses more 100 custom additions, often its better to switch to other definitions (prevent slow config access for all components)
* Do not render "stop command" to config if not configured
* Added missing service description to model and view
* Clarified various mail server settings in settings view
* Fixed spelling in settings view
Builds upon the 6rd routing fixes discussed in https://forum.opnsense.org/index.php?topic=20260.0
Instead of setting the calculated /64 subnet length on the _stf interface, I set the original ISP provided subnet length.
And change the gateway to be inside the ISP provided prefix instead of the calculated /64.
wan address will still be the same but the wider subnet solves any routing issues with single /64 prefixes
This adjusts to the user's preference: in an English browser, 1234567890 will be shown as 1,234,567,890. JavaScript is already required for widgets to work, adding these toLocaleString calls is not an issue in that regard, and the function is supported in all browsers as far as I can see https://caniuse.com/mdn-javascript_builtins_number_tolocalestring
