Add hooks for feature plugins to inject users into the users listing#1183
Add hooks for feature plugins to inject users into the users listing#1183tecto wants to merge 1 commit into
Conversation
Adds three hooks so feature plugins can display their users in the standard domain users table and provide creation links: 1. list_plugin_users hook in list_domain_users() — plugins return user hashes that are merged into the users listing (follows the existing list_extra_web_users pattern for virtualmin-htpasswd) 2. edit_url support in users_table() — if a user hash has an edit_url key, it is used for the name link instead of edit_user.cgi 3. users_create_links hook in list_users.cgi — plugins can add "Add" buttons to the users page, placed outside the mailbox quota guard All three are no-ops when no plugins define the hooks.
- Fix shebang to #!/usr/local/bin/perl to match upstream Virtualmin - Add PR link (virtualmin/virtualmin-gpl#1183) to patches/README Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| # Include users from feature plugins that define list_plugin_users | ||
| if ($includeextra) { | ||
| foreach my $f (&list_feature_plugins()) { | ||
| if ($d->{$f} && &plugin_defined($f, "list_plugin_users")) { |
There was a problem hiding this comment.
Since it comes from a plugin, shouldn’t the function name be feature_list_users for consistency?
| if (!$virtualmin_pro && $u->{'extra'}) { | ||
| my $col_val; | ||
| if ($u->{'edit_url'}) { | ||
| $col_val = "<a href='".&html_escape($u->{'edit_url'}). |
There was a problem hiding this comment.
Are you sure that links need to be HTML-escaped? 🙂
| "user=".&urlize($u->{'user'})."'>$col_text</a>"; | ||
| if (!$virtualmin_pro && $u->{'extra'}) { | ||
| my $col_val; | ||
| if ($u->{'edit_url'}) { |
There was a problem hiding this comment.
A better way to make the PR with fewer changes is to leave the existing code as is and just add your new check if ($u->{'edit_url'}) {...} after the existing logic.
|
Jamie, I think it’s a nice addition. What do you think? |
| foreach my $f (&list_feature_plugins()) { | ||
| if ($d->{$f} && &plugin_defined($f, "users_create_links")) { | ||
| my @plinks = &plugin_call($f, "users_create_links", $d); | ||
| push(@links, @plinks) if @plinks; |
There was a problem hiding this comment.
There's technically no need for if @plinks here
|
seems like a pretty cool idea to me, once the comments are addressed! |
@tecto Could you provide an update on this? |
Do you want us to handle the patches as we see fit, or would you rather fix them in your PR? |
|
This pull request has been inactive for 3 weeks. It will be closed in 1 week if there is no follow-up. |
3 participants
Problem
Feature plugins that manage external user stores (remote mail relay accounts,
LDAP users, etc.) have no way to display their users in the standard domain
users listing or provide creation links. The only option today is a separate
plugin-specific page, which is inconsistent and harder for admins to discover.
Changes
This PR adds three small hooks to Virtualmin core, following the existing
plugin_call/plugin_definedpattern already used for database users(
list_domain_usersline 1096) and web users (list_extra_web_usersline 1127):1.
list_plugin_usershook inlist_domain_users()Feature plugins can define a
list_plugin_users(&domain)function that returnsuser hashes. These are merged into the standard users listing, just like
list_extra_web_usersdoes forvirtualmin-htpasswd.2.
edit_urlsupport inusers_table()If a user hash contains an
edit_urlkey, that URL is used for the user'sname link instead of the hardcoded
edit_user.cgi. This lets plugin userslink to their own edit pages. Existing GPL behavior (plain text for extra
users) and Pro behavior (edit_user.cgi links) are preserved unchanged.
3.
users_create_linkshook inlist_users.cgiFeature plugins can define a
users_create_links(&domain)function thatreturns link arrays (same format as the existing
@linksentries). Theseare placed outside the
$mleftmailbox quota guard since plugin usersdon't count against the hosting plan's mailbox limit.
Backward compatibility
All three changes are complete no-ops when no feature plugins define the
hooks. The existing behavior for standard users, database users, and web
users is entirely unchanged.
Motivation
The immediate use case is virtualmin-remote-mail,
a feature plugin that manages mail relay accounts for domains using an
external mail provider. With these hooks, remote mail users appear in the
standard users table alongside regular mailbox users, and admins can create
them from the same page.
The hooks are generic enough that any feature plugin managing external user
stores (LDAP directories, external authentication backends, etc.) could use
them.