Revamp log file selection method to be consistent with the other system logs.
Add advanced filter section; only activated for the non-vpn.log files (needs testing with vpn.log file first, continue using dump_clog_vpn until tested).
Add manage log section
* 'patch-6' of https://github.com/phil-davis/pfsense:
status_logs_filter_summary make the info box open on initial page load
status_logs_filter_summary make the info an info box
In 2.2.* the shaper bandwidth type dropdowns show "Bit/s", "Kbit/s"... but in 2.3-BETA they are just showing "b", "Kb"...
That is fixed in the various array() definitions here.
I also added GetBwscaleText() function that will return the full text "Bit/s" etc associated with the current bandwidth type. Then call that in a couple of places that were displaying just the "raw" bandwidthtype on the screen. e.g. firewall_shaper_queues.php was displaying just "Kb" etc and now it will display "Kbit/s". That "issue" was in 2.2.* also - so that is an "enhancement".
Since Suhosin has a configured limit of 5000 maximum input variables, for consistency, PHP should be configured with a similar setting (the default is just 1000). This will allow BIG forms to save without any problem in the future.
1) When the Save button has been used to save the Permanent Read/Write setting then display a success message so the user knows it worked.
2) Move the "This setting is only temporary..." setHelp to be with the Read/Write status area, where it is in 2.2.6. That text was under the Permanent Read/Write checkbox, where it was not true.
3) Always set the $btnlbl text used for the $robtn - there were ways to have the system in permanent read-write and then the button would not have a custom label, and so it would just say "Submit"
4) Only display the $robtn when it is relevant - if permanent RW is set and the running system is actually in RW then press a "Switch to Read-only" button actually does nothing anyhow, so there is no point displaying button.
The align attribute on the td element is obsolete. Use CSS instead.
The cellspacing attribute on the table element is obsolete. Use CSS instead.
The cellpadding attribute on the table element is obsolete. Use CSS instead.
The border attribute on the table element is presentational markup. Consider using CSS instead.
A table row was 6 columns wide, which is less than the column count established by the first row (7).
The existing behavior in 2.3-BETA is that if you close this box with the "x" it goes away completely and you cannot get it back.
Do we want to make it a "proper" info box that can be open and closed as desired? (like I did here)
Note: with this change the info "i" is displayed in the closed state. Maybe it should be open by default?
Currently this display as an orange box. It seems to me that it is ordinary info and should be an info box (displaying in blue).
Note: with the current behavior the text is always displayed, after changing it to an info box the "i" icon has to be clicked to show the text.
Do we sometimes(like in this example) want the info text to be automagically displayed on initial page load?
1) When you click to add a new limiter or new queue, then the "Add new queue" button is displayed down the bottom. That is dumb - you are already adding and actually you need to enter the data and save first before adding something else.
2) When you are adding something (like in (1)) the Delete button is displayed. That is also dumb - there is nothing to delete until you have pressed save to add it!
3) When clicking on a Limiter at the top of the tree, the Delete button says "Delete this queue", but it is the top level limiter that is being edited and could be deleted, The $_GET/$_POST that happens sends "pipe" and "queue" both with the name of the top-level limiter. So in the end $queue always exists. So we only want the text "Delete this queue" if $queue exists and the queue name is NOT the same as the pipe name.
Note: These issues are also in 2.2.6 - see https://github.com/pfsense/pfsense/pull/2362 for the changes to fix in RELENG_2_2.
As far as I can see this URL should be self-referring - to firewall_shaper_vinterface.php
But I am having trouble finding how to test it, because whenever $pipe is set, so is $queue so I never get down the "else".
Anyway, this seems an obvious fix, and there might be other stuff related to when creating a limiter as distinct from a queue inside that limiter.
As far as I can see this URL should be self-referring - to firewall_shaper_vinterface.php
But I am having trouble finding how to test it, because whenever $pipe is set, so is $queue so I never get down the "else".
Anyway, this seems an obvious fix, and there might be other stuff related to when creating a limiter as distinct from a queue inside that limiter.
