Hi all,
Picking up on something I was thinking about last November, but got distracted from.
I want to implement group quotas for users based on their client_idnr.
The idea is that you set a quota of say, 100M for a group of users.
When a mail arrives for a user in that group, a further quota check is carried out against the combined mailbox size for all users in that group.
If the mail pushes this total over the group quota, it is rejected.
The normal quota checks would still be carried out for that user, so that some people can still be restricted.
I know some people kinda do this by averaging the group quota across the number of users in that group, or by using some management interface to juggle the individual quotas.
However, this doesn't work in cases where the client doesn't care, they just want to pay x euros for y megs of space.
Last time I broached this, I was told the mechanism already exists. If it does, it's not in the 1.2.3 code.
In terms of mechanism, I was looking at using the config table to store the group quotas.
I looked at the structure of this table and noticed something puzzling:
config_idnr | integer | not null default '0'
item | character varying(255) | not null
value | character varying(255) | not null
The config_idnr doesn't have a unique constraint - is this by design, or by accident?
If it's by design, the implication is that usage is intended to group certain types of config entries together. e.g. all the entries relating to group quotas would have config_idnr=123, whereas all entries relating to disabled users would have config_idnr=42. If this were the case, then
is there a plan to avoid duplicating numbers for different purposes, possibly publishing a list of used ones?
Given the lack of indexing, I'm guessing that it's just that the table hasn't really been used, and thus this hasn't been an issue. If that's the case, then how *should* it be used? Should the config_idnr be unique and/or auto-incrementing?
Feedback please? I'd like to do this correctly so it can be committed to further releases, so if people see a problem with this in their dbmail deployment, please say so.
Cheers,
-Feargal.
--
Feargal Reilly,
Codeshifter,
Chrysalink Systems.
Picking up on something I was thinking about last November, but got distracted from.
I want to implement group quotas for users based on their client_idnr.
The idea is that you set a quota of say, 100M for a group of users.
When a mail arrives for a user in that group, a further quota check is carried out against the combined mailbox size for all users in that group.
If the mail pushes this total over the group quota, it is rejected.
The normal quota checks would still be carried out for that user, so that some people can still be restricted.
I know some people kinda do this by averaging the group quota across the number of users in that group, or by using some management interface to juggle the individual quotas.
However, this doesn't work in cases where the client doesn't care, they just want to pay x euros for y megs of space.
Last time I broached this, I was told the mechanism already exists. If it does, it's not in the 1.2.3 code.
In terms of mechanism, I was looking at using the config table to store the group quotas.
I looked at the structure of this table and noticed something puzzling:
config_idnr | integer | not null default '0'
item | character varying(255) | not null
value | character varying(255) | not null
The config_idnr doesn't have a unique constraint - is this by design, or by accident?
If it's by design, the implication is that usage is intended to group certain types of config entries together. e.g. all the entries relating to group quotas would have config_idnr=123, whereas all entries relating to disabled users would have config_idnr=42. If this were the case, then
is there a plan to avoid duplicating numbers for different purposes, possibly publishing a list of used ones?
Given the lack of indexing, I'm guessing that it's just that the table hasn't really been used, and thus this hasn't been an issue. If that's the case, then how *should* it be used? Should the config_idnr be unique and/or auto-incrementing?
Feedback please? I'd like to do this correctly so it can be committed to further releases, so if people see a problem with this in their dbmail deployment, please say so.
Cheers,
-Feargal.
--
Feargal Reilly,
Codeshifter,
Chrysalink Systems.