• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs Service Plans creation not following server rules: controls for non-existent mail are visible

Linulex

Silver Pleskian
Username:

TITLE

Service Plans creation not following server rules: controls for non-existent mail are visible

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian Version 18.0.42

PROBLEM DESCRIPTION

At Tools & Settings --> Interface management --> Interface control visibility

"Hide controls for rejection messages for non-existent mail addresses"

is enbaled.

But at a service plan the controls are still visible.
Not only for admin, but also for resellers.

STEPS TO REPRODUCE

Disable the controles by enabeling "Hide controls for rejection messages for non-existent mail addresses"
go to an existing service plan or create a new
go to the mail tab
The controls are visible.

ACTUAL RESULT

controls for non existing mails are visible in the service plan to everyone that can create service plans: admin and resellers.

EXPECTED RESULT

controls for non existing mails are NOT visible in the service plan.
At least resellers should never see this and mail to non-existent should be the standard, on our servers always "reject"

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
It seems that a reseller can see every option at the "Permissions" tab. Even the onces he has no access to.

For example: i alway set ssh to Not allowed, but a reseller still can choose all 3 in a service plan. Syncing then fails, but still: option for permissions the reseller has no permission to use (disabled in the reseller plan) should not be visible.
 
From guide Interface Preferences
  • Hide controls for rejection of messages for non-existent mail addresses. Select this option if you want to prohibit your users from using their own mail bounce policies for email addressed to non-existent recipients within their domains.
Resume: the current behaviour is expected.
 
From guide Interface Preferences
  • Hide controls for rejection of messages for non-existent mail addresses. Select this option if you want to prohibit your users from using their own mail bounce policies for email addressed to non-existent recipients within their domains.
Resume: the current behaviour is expected.

As admin, resellers are my users also. How can it be correct that i hide it from my users, but my resellers still can see it, and change it, in the service plan?

hidden is hidden, for everyone. Everything a reseller has no access to should be hidden for that reseller.
 
Resellers are admins as well as they can manage their end-users. Currently, functionality is implemented according to this business logic. Plesk development team can consider improving such functionality to allow hide this option for resellers/administrators. That's why the mentioned feature request was created.
 
Resellers are admins as well as they can manage their end-users. Currently, functionality is implemented according to this business logic.

Yes, resellers can manage there own users, but there is a hierarchy. rules set by server admin are above rules set by resellers. If a server admin hides something, it should be hidden for everyone.

Plesk CEO is in the hierarchy above you but you manage users on the forum, so you both manage something. In your business logic, if the Plesk CEO decides that pay grades are not vissible for everyone, then you would be able to overrule decisions and make pay grades vissible?

The real world works like this: If someone in the hierarchy above you makes a decisions, then everyone lower in the hierarchy has to follow that decision.

If the server admin decides no one has access to a features, then no one should be able to have access to that feature. This is not only the mail to non existant users, but resellers can also see ssh access for example in the service plan. Now they see it would be possible and start moaning why they can't have ssh access.

I don't understand why this has to be a feature request. This is how every company, gouvernement, army, etc... in the world works: if you boss decides you don't have access to it, then you don't have access to it.
 
Back
Top