[Howto] Per user quota edit within ispcp when using dovecot

[JCD]

(06-08-2010 12:36 AM)aseques Wrote:  Hi JCD,
I'm glad you liked it. I had a look at your patch, and it seems that you have updated the patch for 1.0.4.
In the Improved version for 1.0.5 there's a big change, we added a new column so you can edit the quota without having to edit the account. It's far more intuitive.
Please try that one an tell your opinion.

I've taken the improved version for 1.0.5 as template. My opinion is those I've expressed in my post above. I think that an extra button overloads the interface, because in my opinion quotas are no settings that are used very often. Just ask yourself: Is it more likely that you change quotas or passwords? (Don't argue that you change passwords via web mailer)
In most cases the answer is: Passwords are changed more often. To argue from an intuitive view there should be an extra button for changing the password not for changing quota.

We should keep the interface simple and group all settings together. Besides that another point for keeping them together is the re-usability of code. Your stand alone solution uses most of the code which is used by the other settings. To have an efficient code design this would mean in the best case extracting all common code and make it usable for all settings. The end would be unnecessary complexity. After all the quota setting is just a small piece of code and just one tiny bit of all settings.

[aseques]

Quote:I've taken the improved version for 1.0.5 as template. My opinion is those I've expressed in my post above. I think that an extra button overloads the interface, because in my opinion quotas are no settings that are used very often. Just ask yourself: Is it more likely that you change quotas or passwords? (Don't argue that you change passwords via web mailer)
In most cases the answer is: Passwords are changed more often. To argue from an intuitive view there should be an extra button for changing the password not for changing quota.

We should keep the interface simple and group all settings together. Besides that another point for keeping them together is the re-usability of code. Your stand alone solution uses most of the code which is used by the other settings. To have an efficient code design this would mean in the best case extracting all common code and make it usable for all settings. The end would be unnecessary complexity. After all the quota setting is just a small piece of code and just one tiny bit of all settings.

It seems that your users are better than mines , we opted to do the button in a new column for better usability (the people keeped writing a new password every time the changed the quota).
The other reason of this approach is that there is another (not yet tested enough) patch that adds the space/% of mailbox ocupation in the mail accounts window.
It does require some changes on how dovecot stores that information tought.

[JCD]

(06-08-2010 03:35 AM)aseques Wrote:  It seems that your users are better than mines , we opted to do the button in a new column for better usability (the people keeped writing a new password every time the changed the quota).
The other reason of this approach is that there is another (not yet tested enough) patch that adds the space/% of mailbox ocupation in the mail accounts window.
It does require some changes on how dovecot stores that information tought.

There should be a hint to leave the password field blank if you don't want to change it. But this is an ispCP usability issue that affects not only mail account management but also other parts of the software. These issues should be fixed first, because an extra button is an "usability issue workaround" that doesn't resolve the original issue.

Having the occupied space feature there could be a need for an extra button, depending on the implementation, but still the above mentioned re-usability of code remains.
How do you plan to get the occupied space? Because of open_basedir restrictions direct accessing maildirsize can't be a solution. Do you plan to have an ispcp engine helper script that does the job for your?

[aseques]

(06-08-2010 10:29 PM)JCD Wrote:  Having the occupied space feature there could be a need for an extra button, depending on the implementation, but still the above mentioned re-usability of code remains.
How do you plan to get the occupied space? Because of open_basedir restrictions direct accessing maildirsize can't be a solution. Do you plan to have an ispcp engine helper script that does the job for your?

We were planning to use dovecot's quota dictionary. It can use different backends for the storage, we are currently using maildirsize files (the default), but there is the chance that dovecot can use the quotas from the database.
Once it's on the database retrieving it from the UI it's pretty easy.

Cheers

[JCD]

Haven't thought about the quota dictionary feature.
This is definitely the best choice when it comes to accuracy and resource usage. Good luck!

[TheCry]

@aseques
I'd read your docu and there is a litlle issue where you will get the wrong quota of the user...

The problem is you are using:
dovecot-sql-subdomain.conf

Code:

user_query = SELECT CONCAT('/var/mail/virtual/', subdomain.subdomain_name, ".", domain.domain_name, '/',mail_acc) AS home, '1001' AS uid, '8' AS gid FROM (mail_users INNER JOIN subdomain ON mail_users.sub_id = subdomain.subdomain_id) INNER JOIN domain ON mail_users.domain_id = domain.domain_id WHERE mail_acc='%n' and concat(subdomain.subdomain_name,".",domain.domain_name)='%d';

If you add several emailadresses with info@.... and you look in the mail.log you will see the problem!
You can make a test in phpmadmin and execute the query.
%n means the part before @... So you got different lines in your query.

If you are using the query below you will only get one line!
Or you change your query from

Code:

mail_acc='%n'

to

Code:

WHERE mail_addr='%u'

My Query:

Code:

user_query = SELECT concat('/var/mail/virtual/', subdomain.subdomain_name, ".", domain.domain_name, '/',mail_acc) as home, '1001' as uid, '8' as gid, concat('*:bytes=', quota) AS quota_rule FROM (mail_users INNER JOIN subdomain ON mail_users.sub_id = subdomain.subdomain_id) INNER JOIN domain ON mail_users.domain_id = domain.domain_id WHERE mail_addr='%u' and concat(subdomain.subdomain_name,".",domain.domain_name)='%d';

This only an example... You need to change this in every query of dovecot!

[aseques]

(06-09-2010 07:18 PM)TheCry Wrote:  @aseques
I'd read your docu and there is a litlle issue where you will get the wrong quota of the user...

The problem is you are using:
dovecot-sql-subdomain.conf

Code:

user_query = SELECT CONCAT('/var/mail/virtual/', subdomain.subdomain_name, ".", domain.domain_name, '/',mail_acc) AS home, '1001' AS uid, '8' AS gid FROM (mail_users INNER JOIN subdomain ON mail_users.sub_id = subdomain.subdomain_id) INNER JOIN domain ON mail_users.domain_id = domain.domain_id WHERE mail_acc='%n' and concat(subdomain.subdomain_name,".",domain.domain_name)='%d';

If you add several emailadresses with info@.... and you look in the mail.log you will see the problem!
You can make a test in phpmadmin and execute the query.
%n means the part before @... So you got different lines in your query.

If you are using the query below you will only get one line!
Or you change your query from

Code:

mail_acc='%n'

to

Code:

WHERE mail_addr='%u'

My Query:

Code:

user_query = SELECT concat('/var/mail/virtual/', subdomain.subdomain_name, ".", domain.domain_name, '/',mail_acc) as home, '1001' as uid, '8' as gid, concat('*:bytes=', quota) AS quota_rule FROM (mail_users INNER JOIN subdomain ON mail_users.sub_id = subdomain.subdomain_id) INNER JOIN domain ON mail_users.domain_id = domain.domain_id WHERE mail_addr='%u' and concat(subdomain.subdomain_name,".",domain.domain_name)='%d';

This only an example... You need to change this in every query of dovecot!

I think that you're not right, mail_addr is set for ALL the addresses (also the forwards) while mail_acc can be empty on normal_forward types.
Checking for the userpart + domain part should be fine, there won't be cases where you have to users from the same domain called info.

Otherwise can you give me some more information?

[TheCry]

(06-09-2010 09:07 PM)aseques Wrote:  I think that you're not right, mail_addr is set for ALL the addresses (also the forwards) while mail_acc can be empty on normal_forward types.
Checking for the userpart + domain part should be fine, there won't be cases where you have to users from the same domain called info.

Otherwise can you give me some more information?

... I'd found my old thread, where i'd the problem..
The old docu had queries without the domain part...
So i got the problems...
You are right... You are using the this in your queries!

[aseques]

I just uploaded a new release of this set of files. This time I added compatibility to current trunk (what will be 1.0.8).
I just uploaded the files, if someone wants the patches vs v3202 just drop me a PM.

Cheers

[iwik]

Hi, this seems to be very useful patch. But it seems it does not take care about total space occupied by mailboxes under each domain. Users (domain admins) are able to edit mailbox quota, but reseller is not able to limit total space for domain emails. Is some way or plans how to implement this limit?