Sanity check on some ideas for enhancements?
-
I've been thinking about a few enhancements that seem sensible to me.
Before investing time in PRs for any of these, I thought I'd get feedback, not least to check if there are reasons things should be left as they are.
-
GUI Updates/package manager pages - Now that updates use the same system as packages, maybe we don't need half a dozen tabs to view the various lists of these? Maybe have just one tab for available/installed packages and updates, and actions. The page would have 3 sections: filters - updates - packages. The filters include checkboxes for <installed available="" both="">and <packages updates="" all="">, the usual sort/filter/search and a collapsed "settings" section which allows selection of releases only vs alpha/beta/snapshots, and other update settings. Retitle the menu item to "Updates and packages". Result - users can see all applicable or applied updates in one place at one time, as they wish, without flipping between pages.</packages></installed>
-
Sysctl handling - It's wierd having sysctl descriptor strings as fixed text strings (and in English only!) stored in $config and the config.xml. Sysctls are pretty much tied to the OS and hence to the release version, and their descriptions are only needed occasionally (mainly in the advanced -> tunables GUI). So perhaps move descriptions to the codebase and not kept in the config. Any updates are likely to be release-related anyhow. Also maybe allow for extra non-standard tunables to be added by the user, and use sysctl -d for their descriptions if not held in the codebase. Perhaps change to "FreeBSD default description" and "pfSense additional notes", so we don't just have text duplicating readily available sysctl -d output. But I'd really like to see the fixed strings moved out of the $config array, it hurts my brain to see that done :)
-
Edit file enhancements - Although this is mainly a developer function, it's very handy. But it's got a very rudimentary interface. Maybe add some history of files/directories, allow editing of 2+ files side by side or above/below, a "tools" button to easily access diff + lint + find, and a couple of settings such as the option for tab to change field vs indent text (both have their uses but it's really a PITA adding a tab if you want to, and would be nice if the user could choose). Most of this can be hidden or collapsed, but I imagine at least some of these would make life easy for some (many?) users.
-
CSRF timeout placing in GUI - The CSRF GUI timeout doesn't seem to be especially related to specific users or groups, it's just buried in user management settings. Move from user settings to system->advanced->admin, to be shown with DNS rebind, HTTP_REFERRER and all the other GUI security/timeout/controls which it's much closer to in function, in one place.
-
Interface/gateway widgets - For many users, there will be a 1:1 correspondence of interfaces and gateways. But at the moment it's hard to see these in an intuitive way, because the dashboard shows interfaces (but no details of the GW they link to, their uptime/latency/subnet etc) or gateways (but no linkage to related IFs). I keep thinking there must be a better way to do this, perhaps a combined IF+GW widget which allows the user to configure what info they want to see on the dashboard, and a few possible formats to present it (including just IFs, just GWs both separately, or both combined).
-
Per-user GUI settings - Users vary. It wouldn't be hard to allow some GUi settings to vary between users. For example a user with poor vision may find small font (useful to many people) literally impossible or a headache to read. pfSense doesn't really provide much accessibility help other than "choose a theme, some column sizes and edit the css yourself". Maybe adding scope for very basic per-user GUI settings would make this easier, by allowing a means by which different users could have at least some visual settings differ between them.- done (thanks: phil davis) -
Crypto algorithm notes - see "possible improvement #2" on redmine 6332.
-
Notify event match - there isn't a built-in way to notify selected events that could be important to some users, such as successful/failed admin logins, matched log entries, or (whatever else). This could be commonly enough desired to be worth adding "notified events" to the system->advanced->notifications page. (Also, scope to notify multiple email addresses, for example an admin's usual and travelling email, or multiple admins?)
-
Better notification control - on an average forum, a user can see the events that can be notified, and choose which are notified in which way. On the router, wouldn't it be nice to configure that some items get notified by emailing to these addresses, others by growl and email, and some not at all?
-
Improve package repo options- At the moment packages are downloaded from the official repo (partly because the Docs pages warn that installing a local repo would require changes to xmlrpc). But looking at the code, an option to enable/disable a local pkg repo, perhaps in the form of a user-entered directory and not using xmlrpc at all, might not be so hard to do. It would allow aspiring and occasional developers to set up a local store on the router for quick pkg testing or to install pkgs they need to install, even without having a net connection, and also without needing to create and manage a repo elsewhere. The idea is that the user can enter additional pkg repos, with each being either local (filesystem path) or remote (normal repo IP/url) and individually enabled/disabled. For security "local repos" would be disabled by default
-
-
6. Per-user GUI settings
Pull request https://github.com/pfsense/pfsense/pull/2989 makes the current GUI preference settings available optionally per user.
If there are other settings that are relevant per-user, then they can be added to that. -
Hi!
Multiple dashboards?
On first page system info, on second traffic graphs on third some logs etc…
:) -
2. That requires inventing internal identifiers for the sysctls to be used in the config and keeping track of them on one additional level. I'm sure you agree that nobody wants to use numbers as those identifiers because then the sysctls in the config file are just not readable (and not user editable) anymore. This would mean that you'd have to use something like TCP_BLACKHOLE for net.inet.tcp.blackhole and I'm not sure that's much prettier. Forget the idea of localizing those IDs, it's not going to happen.
-
@kpa:
2. Forget the idea of localizing those IDs, it's not going to happen.
That might be a misunderstanding. It's the plain-text descriptions, not the sysctls themselves, that I referred to.
-
@kpa:
2. Forget the idea of localizing those IDs, it's not going to happen.
That might be a misunderstanding. It's the plain-text descriptions, not the sysctls themselves, that I referred to.
I started to wonder if that's what you meant :) Translating the WebGUI to different languages is of course a welcome development :)
-
Hi!
Multiple dashboards?
On first page system info, on second traffic graphs on third some logs etc…
:)Ohhhh sorry :-[
I was reading too fast to notice this is not whishlist :) -
@kpa:
@kpa:
2. Forget the idea of localizing those IDs, it's not going to happen.
That might be a misunderstanding. It's the plain-text descriptions, not the sysctls themselves, that I referred to.
I started to wonder if that's what you meant :)
It's that the config file "sysctls" section currently looks like this:
<tunable>vfs.read_max</tunable> <value>default</value>but the meaning of vfs.read_max should be moved out of the config file and read as needed from the system itself, or stored as strings/gettext() in the router code.