Many improvement suggestions for UI

While someone could rightly suggest that each of these might belong in an individual post, or that each item should just be put into the tracker, someone else could easily get annoyed with a lot of posts on related topics. So I'm putting everything here for cherry-picking and comment. I'll create tickets for whatever seems to be of value. All items numbered for reference. Thanks for your time.

Email Domain list

1) Display the numeric ID of the domain in a column or on mouse-over.
Reason: When looking in the file system it's not easy to find the backup for a domain_user because the backup files are saved with ID numbers which are not immediately visible in the UI.

Email Domain maintenance

2) Display the numeric ID of the domain in the information area.
Reason: Same as 1, not necessary with 1.
3) Ability to set defaults for Trash Days, Junk Days, Backup Interval, Backup Copies
Reason: We need to remember the policy and enter it manually for each new client. OR ... where is the default stored, and is it already available in the UI somewhere?
4) Ability to reset values for all mailboxes for a specific domain to current defaults.
Reason: When there is a policy change a domain (or global) reset can eliminate manual effort.

Mailbox list

5) Ability to sort by domain
Reason: Current sort by username is not helpful. We can filter on domain and then sort by user, but that's not always ideal.
6) Display the numeric ID of the mailbox in a column or on mouse-over.
Reason: Same as above. The website list shows the site ID. I'd like to see the display of IDs in column 1 as a standard in all lists.
7) Add fields to table: Purge Trash Days, Purge Junk Days, Backup Interval, Backup Copies, last backup date
Reason: Helps to find any mailbox that is not set properly.
8) Add button to clear filters and refresh list
Reason: Filter fields need to be manually cleared. That's primitive.
9) Wider column for Email address.
Reason: Field is unreasonably small. This can be handled in a custom theme but is being requested for core.
10) Wider column for Autoresponder column header
Reason: Aesthetics - column is scrunched.
11) Ability to select items in list/table.
Reason: See 12.
12) Ability to set values for selected items: Trash Days, Junk Days, Backup Interval, Backup Copies
Reason: Similar to 4 but not as global. This can help to set a per-domain policy.

Mailbox maintenance

13) Display the numeric ID of the (maildomain and) mailbox.
Reason: Same as 2, not necessary with 6. It's just surprising to me that a field as simple as the ID isn't displayed.

Email alias list

14) Ability to sort by domain
Reason: Same as 5.
15) Display greylist check value (yes/no).
Reason: Just as helpful as Active value which is displayed.
16) Add button to clear filters and refresh list
Reason: Same as 8.
17) Ability to select items in list table.
Reason: See 11, 12, 18.
18) Ability to toggle fields in selected items: Active, Greylist.
Reason: Eliminates need to edit each record.

Email Spamfilter white/black list (per user/recipient)

19) Display the numeric ID of the global_wblist_nn.conf in a column or on mouse-over.
Reason: Helps to find .conf file in file system.
20) The priority in the UI is 1-10. Change to allow simple integer value.
Reason: When set, the actual value saved is 20 plus the displayed number (5>25, 7>27). Per Rspamd doc, any positive integer is valid, higher numbers are higher priority. I understand that ISPConfig is just asserting a high priority for us. I don't see a good reason to disguise this as a value limited from 1 to 10. I think the UI and/or doc should suggest higher values, but it should be up to the admin to choose values in whatever range fit the site-specific needs. The change from the display value to a different internal value is also unnecessarily confusing.

Email Spamfilter white/black list - and - Spamfilter User/Domain

21) Add mailbox users to filter lists based on policy inherited from domain.
Reason: If a mailbox/user has Spamfilter set to "Inherit from domain", and the domain spamfilter is "Normal", the user does not show in the list for Spamfilter recipients - and does not show in the User/Domain list of Spamfilter Users. The user must have the filter explicitly set to Normal for the user to appear in the Spamfilter white/black user dropdown list or in the table of spamfilter users.

Email Global white/black list (all domains/users)

22) On saving a Global filter, the operation to create the global_wblist_n.conf file is queued and processed as it should. But the queue notification at the top of the page is not displayed.

Spamfilters (general)

23) Consider a third maintenance page for filters, one that allows more complete usage of rules. This might eventually replace user/domain and global filter maintenenance pages.
Reason: The Rspamd spec any allows for multiple instances of the same attribute, as well as regex, and comparison of user OR domain parts of from/rcpt. Valid attributes also include ip and headers. The current filter UIs don't allow for full usage of the current features.

System / Server Config / Web maintenance (or System / Main Config / System Config)

24) Mail: Ability to set defaults for Trash Days, Junk Days, Backup Interval, Backup Copies
Reason: Avoid manual edit of configuration. (Does this already exist?) Related to 3 and 7.
25) Sites: Ability to set defaults for Backup Interval, Backup Copies
Reason: Same as 24.

Sites/Website list

25) Display a Let's Encrypt Yes/No column
Reason: Quick visual confirmation of SSL.
26) Add fields to table: Backup Interval, Backup Copies, last backup date
Reason: Quick visual confirmation of backups.
27) Add ability to set Backup Interval and Copies for selected sites.
Reason: See 17 and 18.

Tabs and pages

28) Back button has undesirable behaviours.
Email tab > Email Mailbox list > enter a Mailbox Click Back : The browser leaves the ISPConfig page entirely. I'd prefer for it to go back up one level, like the Cancel button. I understand the challenges of the Back button and that there is a difference between browser/webpage navigation and navigation within an application. There are solutions to the problem.

29) Inconsistency in Tabs/pages, and back button.
Issue is reproduced as follows:
- Click Sites tab, then Website sidebar item, note the site list.
- Click Email tab.
- Click Sites tab, note still on the website list.

- Click Subdomain (Vhost) sidebar item, note the subdomain/vhost list.
- Click Email tab.
- Click Sites tab, note still on the subdomain/vhost list.

- Click Subdomain for website sidebar item … I have no data in this list.
- Click Email tab.
- Click Sites tab, it goes back to the subdomain/vhost list, not actually the last sub-page.

- Click Alias for website sidebar item.
- Click Email tab.
- Click Sites tab, it goes back to the subdomain/vhost list, which is the last page for which there was data.

- Click the Website sidebar item.
- Click Alias for website sidebar item … I have no data in this list.
- Click Email tab.
- Click Sites tab. It goes back to the website list, which is the last page for which there was data.

I believe it would be more consistent when clicking on the Sites tab to always go back to the last tab, not just the last one that displayed data. OR, always go to the website list.

Similar inconsistencies are experienced in the System config navigation with the Back button.

30) There is no 30.

Thanks!!!

 

@Th0m - Sincere thanks for your time, consideration, and feedback.
As I noted in the OP, I could be faulted for too many or too few tickets so I decided to open this in the forum first. This also puts more eyes on the topic. More people visit forums than scan through issue trackers for enhancements that they might want to +1. I'm happy to create tickets after we've nailed down some specific requests that can be processed (even marked stale or rejected) in the tracker.

Based on your responses, maybe a different approach can be taken to the items about columns in tables : The left-side navigation is 280 pixels wide, and those tables are 980px. With resolution of 1920 wide, we have 660 pixels of unused horizontal space. (CSS #content, width: 78%) Perhaps the suggestions should be for a page in Main Config which allows for column names to be checked/toggled, then the admin-defined columns can be displayed for Sites, Mailboxes, Aliases, etc. In the styling, just let the horizontal width expand as wide as the column widths demand. For another enhancement later, add fields to that column maint page for the column width min/max. This allows the admin to decide how wide the columns should be. This eliminates our sense of what's desired or required and leaves it all up to the users. You alluded to something like this for #21.

I am not 100% sure but I believe this can be done with a new theme and an addon, so it does not need to be built-in to core.

Does that address many of those concerns?

 

Regarding the viewing and setting of fields that either don't fit in the tables, or perhaps which do not need to be there : Queries for viewing data can be handled with CLI SQL. Batch updates also do not need to be handled in the UI with select/save operations. I'll work on some SQL queries, and scripts with the API. These can be used, for example, to get a list of mailboxes, with just their detail for backups or trash handling, and then maybe to set the selected records with new values.

 

Ubiquiti UniFi? No, I haven't, but I have written dynamic apps with dynamic grids. When I make requests like this, as a developer I can sort of picture what's involved (time/value/code) even if I'm not yet intimate with the specific UI details. So I have a good idea of how this can work.

Speaking of which - since a lot of these comments are related to the UI, I have no problem with a suggestion to DIY and submit MRs for consideration. This is just my first attempt to understand what people think about this topic and what might already be in processing, but if the response is "yeah, we'd like to get that in the software but we have other priorities" then DIY is the right FOSSy answer. What I don't want to do is to spend a lot of time coding, only to have the result ignored and obsoleted by the next point-release. I risk irritating people with threads like this to avoid that pain.

 

one thing i can think of. for the websites list, ( and aliasdomains vhost and subdomains vhost) include a column for the php version so the list can be filtered/sorted by this.

i know i can see how many sites total are on each php version on each server under 'additional php versions' but it's time consuming having to go into each individual sites settings to see what it's using, or manually query the db.
would save so much time and be so much easier to see which sites are on outdated php versions if the sites list could be filtered by php version. would be nice for customers/resellers with lots of sites to see this info easily as well.

 

@nhybgtvfr That request fits well with my note above:

Over time, many admins can come to this thread and ultimately request that every possible field be made available in the list for selection and maintenance. That's not practical (unless you'd like your browser to expand across three monitors at 1920 resolution). I think it's more practical for the admin to choose fields which will display. Then, we all get what we want.

Note also:

So over time, we can assemble (in the new documentation area ) a set of queries and scripts that will allow us to see what we need from shell ... No changes to the ISPConfig UI required! Ultimately I think this is the best short-term solution, and it gives the dev team as much time as they want to decide what they want to do with the UI, with no pressure from us about what we "can't" do.

What do You think?

 

having a selection list of fields for admin is ok, i have no problem with them being able to choose what to view, but your probably not going to want to make the whole list of fields available for selection to a client or reseller, admin will likely want to view a field he doesn't want a client/reseller to be able to view. And you certainly won't want them to be able to run sql scripts against the dbispconfig db.

and if you look at all those fields, really the only ones not included on the sites list currently that i can imagine would want to be viewed/changed regularly/easily and would be helpful/time saving for both admin, and clients/resellers, are the php versions, and probably SSL. and letsencrypt SSL can probably take the form of a button, like the 3 that currently exist, showing a padlock icon, with a grey background for unused/off, and green for on/active. and maybe also show another one, (a padlock and a currency symbol?), if the site also contains all the required keys/csr/crt data to enable/disable a separately purchased certificate.

 

I think you're confirming my point. I started this thread with a list of proposals for UI changes. With great feedback from @Th0m it was apparent that for some fields there is a difference of opinion about what is desirable. You then say "the only ones not included on the sites list currently that i can imagine would want to be viewed/changed", but I've already provided a list of other fields. So let's dream a bit and see where it goes.

You've added a really good point that display fields are not just a toggle on/off. Fields are subject to permissions. As a start, I would propose that a new maintenance page would be maintained by an admin, and new dynamic tables would also be admin-only. Nothing would change for clients and resellers. A later enhancement could change the simple toggle into three checkboxes, one for each role, and the page that renders the lists would respect the toggles for the roles.

About scripts, there are obviously OS-level features that are also governed by permissions. We can publish documentation with helpful scripts for SQL queries to reveal information for administrators, and other users/roles would simply not be able to execute them. There's nothing special about this. And again, with scripts there are No changes to the ISPConfig UI required! I can imagine developers here rolling their eyes as proposals for the toggle options - and I would completely agree that if this is something that We/someone want that We should take some initiative to code it rather than simply dumping it on the team along with their existing pile of requests. But I don't think anyone can object to simply documenting queries that allow us to view data that we feel is missing from the UI.

So now, what do you think?

 

I much prefer reports from database to adding lots of columns and displays to the GUI. Having all possible information visible in the GUI makes the GUI worse.
Even just documenting useful SQL queries to for example show which PHP version and mode each website uses or what SPF e-mail domains have would be plenty useful. These kinds of information are needed but only seldom.

 

There is a way to solve the cluttered columns problem. You can handle it the way wordpress does it. Create a hidden div above each dashboard table with check-marks to show which columns should be available. Set a few as default and allow the user to build his own column layout.