With the current implementation of the group management it is easy to assign clients/domains/adlists to groups. Depending on users needs the group management might be fairly complex. At the moment there is no easy way to answer the questions
What clients/adlists/domains are in group XY?"
Users need to go through each subsection (clients, adlists, domains) to answer the question. It would be extremly helpful to have a tool to look at a group from the opposite direction. I could image a table with each group one can expand and sees which client/adlist/domains belong to that group. For easy handling one could also remove items from that group overview directely.
Feel to move this to Feature Requeste or Beta v5.1
That looks a lot like the side menu structure with all items expanded at once.
While quite uniform and tidy when using abstract names, that may become not very appealing, even fidgety, once you start populating that with actual properties for the different categories, for two reasons:
Items of different categories will have different properties, e.g. IP address(es) and hostname(s) for a client or name, last update timestamp and description for an adlist.
And as we are dealing with n-to-m-relationships for the most part, an item may appear in several places (as you have included in your sample structure).
For "five millions blocked domains" users, this may become a bit unwieldy.
The main advantage I see in that approach is you do show everything in one place.
I personally don't like scrolling long lists that much, and I'd also guess that most of the time, a user would focus on managing same type items from each of the sections (of course, that's an assumption only).
So I would probably want to select a specific group (maybe from a dropdown), displaying some basic info and allowing me to switch the item of interest (i.e. Clients, Adlists, etc.), which in return prompts display of the associated list.
The main disadvantage of this approach is that it focuses on a single group.
To mitigate this, you would also need a dedicated search that would allow you to find the groups of your interest.
Anyway, it won't be easy to decide on any layout without knowing or assuming how that information will be used most often.
Again, that's me assuming that a user would normally look at data to initate some kind of action, rather than just for the sake of looking.
But I see the charm of your design. It's much cleaner and I liked the "boxed" design. The challenge would be the upstream choise/design of which/how a specific group is selected.
I'm not sure if this is a disadvantage when the user can switch fast and easily between groups.
I assume typical user questions would be something like
"Are all my kid's device in Group "Kids"?"
"Did I add all malware lists to Group "IoT?"
"Did I add all Whitelist entries to Group "Samsung TV"?"
I must confess I haven't looked at v5 group management that intensely until now.
Think of questions like "A given client is a member or which groups?" or "Which groups do not contain a given adlist yet?", and a search may prove useful or even necessary, if the information sought is not available elsewhere.
This will not be in v5.1, the entire frontend is still missing and v5.1 is (loosely) scheduled for release in 1-2 weeks. It's almost time to go into a short code freeze phase so we can test and verify the new changes.
Good catch, the SQL query is too verbose here, I will optimize it.
Yes, however, this is what is in the database. I will check this out separately and push a fix.
We will still take both possibilities "" and NULL for empty comments into account as users may have been interacting with the database directly and this does not necessarily need to adhere with how we anticipate things.
