Move sneaky the "Administrator's Webmin modules" from the "Templates" to the "Account Plans".

[iliaross]

Howdy, Jamie!

We need to move "Administrator's Webmin modules" from "Templates" to "Account Plans," which supports both "Apply" and "Save and Apply" logic! Templates should be reserved solely for new domains. It's confusing for this page in templates to apply to existing domains—it's simply wrong!

[shoulders]

I absolutely welcome this one. I have been mentioning this one for years, however I would like to ask that you considering doing the following.

After moving the Administrator's Webmin Modules to Account Plans you should keep the live nature of these settings and change the rest of the Account Plans be be the same so they are looked up on a live basis and not use the save and apply mechanisms.

The save and apply in Account plans is not what a user expects. The code/mechanism for live lookups currently exists in the Adminstrators' Webmin Modules

Related

• Cannot configure availabe Webmin modules after account creation using Virtualmin #800
• Feature: Account Plan and Owner Limit improvements #687
• Bug: 'Account Plan' and 'Edit Owner Limits' pages do not match #686
• Re-Send Signup Email - should be in Account Plans #961

[iliaross]

The save and apply in Account plans is not what a user expects. The code/mechanism for live lookups currently exists in the Adminstrators' Webmin Modules

I don't think we should change that though! We already have the options for "Save" and "Save and Apply," so there's no need for a change. People are accustomed to it, and it won't provide any benefit unlike moving "Administrator's Webmin modules" from the "Templates" to the "Account Plans" itself.

[shoulders]

"Administrator's Webmin modules"

When logging into webmin, these values are looked up from server template assigned to the account whereas the other settings are set on the domain which requires them to be applied. My thinking was that a lookup to an account plan for the values would be better rather than hardcoded values in the domain

Maybe consider changing the buttons from save and save and apply just to one single button. Having the 2 options has no place in a modern panel where it is managing your websites. Perhaps the behind the scenes mechanism would not be that important then.

[iliaross]

Maybe consider changing the buttons from save and save and apply just to one single button. Having the 2 options has no place in a modern panel where it is managing your websites.

No, we cannot do that, as not all updates to the plan should be applied to the virtual servers using it. It has always been optional, and we won't be changing it.

[shoulders]

No, we cannot do that, as not all updates to the plan should be applied to the virtual servers using it.

Ok, fair enough

It has always been optional

Why? As an end user I cannot see why you would run multiple versions of an Account Plan, surely that is why you can define as many Account Plans as you want. Also all you have to do is to click the wrong button and all of the different versions are then wiped out anyway.

If you use the save only option so changes to the account plan only apply to new accounts, then why not just create a new account plan, you could even use the clone button.

Versioning of an account plan is definitely a useless idea. It adds administration overheads that require real life interventions (ie spreadsheets).

Just because the feature has been put there some time in the past does not mean it is useful, used or should not be removed :)

All other panels I have researched only have a save option (this implies apply in context of virtualmin) so when you make a change to the plan all users assigned to that account plan get the change.

[iliaross]

Why? As an end user I cannot see why you would run multiple versions of an Account Plan, surely that is why you can define as many Account Plans as you want. Also all you have to do is to click the wrong button and all of the different versions are then wiped out anyway.

Imagine a situation where a company has changes starting next month. For the new domains, the changes would be applied immediately, but for the old ones, the change is meant to happen only starting next month.

This allows me to make continuous changes to the plan throughout the month, applying them selectively and at a time of my choosing. I actually think this is a fantastic feature! Kudos to Jamie.

If you use the save only option so changes to the account plan only apply to new accounts, then why not just create a new account plan, you could even use the clone button.

It would require then changing all domains to the new plan.

Versioning of an account plan is definitely a useless idea. It adds administration overheads that require real life interventions (ie spreadsheets).

It exists; it took effort to implement—it cannot be a useless idea! There are people using it!

Just because the feature has been put there some time in the past does not mean it is useful, used or should not be removed :)

Just because one doesn't use or understand the future, it doesn't mean it should be removed. :)

All other panels I have researched only have a save option (this implies apply in context of virtualmin) so when you make a change to the plan all users assigned to that account plan get the change.

That's a good indication that we're doing it correctly. Might not always be so, but here it definitely is, in my opinion.

[jcameron]

So I am open to the idea of this template setting not immediately updating all existing domains, but it reallt doesn't belong on the plans page. A plan is supposed to set limits on what features and resources a domain owner has access to, and not control the UI.

Also, migrating all existing systems would be a nightmare if there are many plans and templates!

[iliaross]

So I am open to the idea of this template setting not immediately updating all existing domains

That doesn’t seem like a workable option either, since it blocks the ability to change existing domains. How would someone go about adjusting those settings for domains that are already set up? Nevertheless, it's simply the wrong place for that page to be initially.

but it reallt doesn't belong on the plans page. A plan is supposed to set limits on what features and resources a domain owner has access to, and not control the UI.

Well, I don’t see why not? We’re not just dealing with UI here—account plans already use a similar “Allowed virtual server features” accordion to "control" what shows up in the navigation menu (UI). Doing the same for the new “Allowed virtual server modules and functions” accordion wouldn’t be much different.

And, realistically, it’s probably the best spot to move it to, especially since it already supports both save and save-and-apply logic.

Also, migrating all existing systems would be a nightmare if there are many plans and templates!

Well, sure—it won’t be that easy, but it’s not a nightmare either, I don't think—especially given how important it is to keep the logic clean for the templates system. And, each domain only uses one template and one account plan, so moving options between them just means updating two text files in the postuninstall.pl script—doesn't seem too hard, right?

Think you could give it a try?

[shoulders]

I am guessing that you guys know this one anyway but Just for reference the following WHM pages does the following:

• WHM/cPanel does not have a Server Template system but does use templates for such things as DNS Zones
• WHM uses Feature Manager for granting access for the user to the various features of cpanel
  • there is no permission graduation, it is either enabled or not.
  • Controls Access to various modules and features such as File Manager, Awstats, Contact Information, Cron jobs, EA4 - Allow PHP 7.4, Email filtering, Immunify360 and more
• You define the Feature List to be used in the Package
• Packages
  • Specifies which Feature List, cPanel Theme
  • Defines resources such as Quota, Bandwidth, number of Addon Domains, Dedicated IP
  • WP Toolkit (some settings)
• The Package is assigned to the user account
  • features and quotas are applied on an account/user basis and not per Virtual Server as in virtualmin

So what this might translate to in the Virtualmin context is that if there are issues, perhaps add another page giving:

• Account Plan page
• Features page
• Server Templates page
• An extra option on Edit Virtual Server

NB: I can attach WHM images if that would help

[jcameron]

I would actually argue that this "Administrator's Webmin modules" section shouldn't exist at all, and instead we should grant access to moduies based on capabilities set in the plan.

Ilia, are there really cases where we need the ability to control access to Webmin modules? Like would we need to remove access to the File Manager for example?

[iliaross]

Ilia, are there really cases where we need the ability to control access to Webmin modules? Like would we need to remove access to the File Manager for example?

I recall a few people asking how to disable File Manager access for virtual server owners. Still, I believe we shouldn’t base decisions solely on user feedback—or lack thereof, rather on common sense.

From that perspective, it makes sense that users may want to control access to some Webmin modules. For example, "Upload and Download" or "Scheduled Cron Jobs" and some other is reasonable to have control of.

However, many modules listed under “Administrator’s Webmin modules” could be tied to capabilities—but not all. Some, like “SSH Login,” should be removed entirely.

As for where this functionality belongs, I haven’t figured out a better fit than the "Account Plan" page. It’s flexible enough to hold this without needing a new page, and just keep things simple. So, my suggestion is:

• Remove some modules entirely
• Make others capability-dependent
• Add the rest either as a separate accordion or as new capabilities under existing ones

[iliaross]

I still suggest moving it under the Plans page, as described in my previous comment.