Important Request and/or vote for new features - http://plesk.uservoice.com/

[Sergey L]

Hi,

As a way of better tracking your requests and priorities we are trying http://plesk.uservoice.com/ service, where you could write your suggestion or vote for a suggestion of others. We hope this system would increase transparency and would help us to ensure we are aligned with top customer priorities.

As the system gives you only 10 votes, we recommend to vote for what you really like.

We keep watching the forum for your suggestions, but getting high rank at http://plesk.uservoice.com/ greatly increases the chance the request will be considered a priority.

 

[rosskendall]

Thanks. It seems that lately the Plesk team is trying hard to listen to the user.

 

[Muhammas SohaibR]

Just because of fast response of team we are using this service

 

[dado023]

When is this feature, at below url, planned to be implemented?:
http://plesk.uservoice.com/forums/1...lth-show-apache-cpu-usage-per-domain#comments

 

[Sergey L]

When is this feature, at below url, planned to be implemented?:
http://plesk.uservoice.com/forums/1...lth-show-apache-cpu-usage-per-domain#comments

This is definitely in our top list, though implementation isn't too simple. CPU usage is hard to properly track in general and tracking per domain is particularly complicated as not every service/process will give this information. This would have been easier in CloudLinux (and you shall definitely consider it if this is a priority for you). But we obviously need to consider other OSes as well, so research in progress so far.

As you may have noticed we always update feature status when it is close to delivery, so you will be immediately informed once it happens

 

[dado023]

having this feature would put Plesk/Odin before any other Server hosting control manager/panel, just think about......i am really looking forward to Plesk development, because it has many new end user features....but i would like to see more system/OS features ......

Main reason is, end user doesn't spend so much time within web host panel(Plesk, cPanel, Interworx...etc), as much as he/she does within website CMS, Forum, blog...etc

I mean, look at all those votes for this feature, its massive......

 

[Sergey L]

We have no doubts this function is important
I have just been discussing a similar question in another topic - http://talk.plesk.com/threads/limit-cpu-usage-per-domain.334495/
Would you share how you will use that? Same limit for everyone, custom limits, service plan-based limits?

 

[Deepak M]

Below request was added on July 08, 2013 and even after 3 years request is pending.

For such important feature plesk is waiting for users to vote

https://plesk.uservoice.com/forums/...mer-email-notification-when-mailbox-quota-exc

 

[Sergey L]

Below request was added on July 08, 2013 and even after 3 years request is pending.
For such important feature plesk is waiting for users to vote
https://plesk.uservoice.com/forums/...mer-email-notification-when-mailbox-quota-exc

We expect to deliver this function in the next version - thanks for raising the topic

 

[Deepak M]

is it going to be included in ver 17.0 ?

 

[Sergey L]

Yes, it does.

 

[Deepak M]

Also are you considering below request in new version?

https://plesk.uservoice.com/forums/...configuring-email-notifications-for-resellers

Like Reseller should get notification from Server Admin profile ID and Customers should notifications from Reseller profile ID

different source address for the notifications delivering to the customers and to use reseller profile email address instead of server admin email address for delivering the notifications for the newly created accounts under the reseller.

Email Notifications to customers should go from reseller id or let it go from [email protected] and to reseller it can be sent from server admin id or [email protected]

Capnel does it similar way if it goes via reseller id that is better so if customer reply to that email he can attend it immediately

 

[Sergey L]

Also are you considering below request in new version?
https://plesk.uservoice.com/forums/...configuring-email-notifications-for-resellers

Probably not. As you can see it has quite low votes and we have over 100 of higher priority requests to work on

 

[Deepak M]

But in shared hosting environment hierarchy of notification should be maintained Service provider ( Server admin) -> Reseller -> End user
or else all end user will start contacting Service provider ( Server admin) and reseller will lose business

To compete with Cpanel these all basic features plesk development team should include it without waiting for votes

 

[Fronobulax]

On something that has 335 votes (https://plesk.uservoice.com/forums/...ions/5947702-dkim-and-dmarc-support-for-plesk) and has been planned for a couple of years now...
Should we continue voting for this? Is it already being worked on? Will it be implemented soon?

 

[Sergey L]

On something that has 335 votes (https://plesk.uservoice.com/forums/...ions/5947702-dkim-and-dmarc-support-for-plesk) and has been planned for a couple of years now...
Should we continue voting for this? Is it already being worked on? Will it be implemented soon?

It is planned, but you still can keep voting. There isn't such thing as too many votes for a good thing.

 

[George Gonzales]

Currently I see only minor bug fixes but no new features.

 

[larryk]

observation:

1) some requests have very few votes, and they are completed.
2) some requests have a lot of votes, and they are completed.
3) many declined requests have very few votes, but they do have a decent explanation as to why ( I think that is good enough).
4) some requests have lots of votes, and they are not planned, not complete, and don't have an official comment.

but overall, it looks like the number of votes is not really important?

thoughts?

 

[custer]

observation:

1) some requests have very few votes, and they are completed.
2) some requests have a lot of votes, and they are completed.
3) many declined requests have very few votes, but they do have a decent explanation as to why ( I think that is good enough).
4) some requests have lots of votes, and they are not planned, not complete, and don't have an official comment.

but overall, it looks like the number of votes is not really important?

thoughts?

Hi Larry,

I assume that you are mostly confused by two things: the existence of completed requests with only a few votes ("why they do things that are not popular") and the existence of open requests with a lot of votes ("why they don't do things that are popular"). I understand why such a confusion could happen and I'd like to share our perspective on this situation.

Completed requests with only a few votes are typically items that we already knew about for some time and we had them scheduled as a small but important improvement, often a fix of something really annoying. These are typically small QoL (quality of life) improvements -- the key word being "small". They take little development time, and they improve the overall product health and make your lives more comfortable.

Open requests with a lot of votes are typically big features expensive to develop and test, with a lot of risks that something could go wrong or break down. Usually, we can only fit a couple of such features in a release due to their size and complexity, so some features, unfortunately, are postponed to the next product releases because we can't develop all of them (or even many of them) at once.

So, as you see, the number of votes is really important because we cannot implement a lot of big features simultaneously, so we have to carefully choose which big features we should focus on. Your votes help us tremendously since they show us a pretty clear picture of what the community believes to be important. We also have our own ideas about what could be helpful to the existing Plesk users and what could attract new users, so it's always a mix between your requests and our ideas. Please continue to vote, since your voices are a very important part of the Plesk equation.

Hope this clears the possible confusion, Larry.

 

[larryk]

Thanks custer...
that was a GREAT reply