On Tuesday 25 March 2003 18:25, Brian Kolaci wrote: > Do you think we need both domain permissions and > default new user permissions for each type of permission? > (This is the case for quotas, a domain limit and a default > for new users). > > I like the idea of having both (which just generates more > work...). But we didn't take that into account with the > original design. > > I would say that we should do what you were intending > by using the current values as "domain" permissions, and > add a field for "default_user_permissions" that would > populate the gid field of the user password entry. > What I would also do is encapsulate the code you > wrote into a function (you don't need the #ifdefs) > and have it return the mask which can be AND'd with > the gid field of the password entry. This masking > function could go into vlimits.c and called in the > vauth_getpw() functions.
sounds good to me. I guess a single field added to the mysql table for default_user_permissions is enough, as it only has to contain the mask. (Well, we could have done this to the disable_* as well, it wouldn't bloat the mysql table that much) something like enforced_domain_permissions and default_user_permissions .. but if it's to late to change that now, i won't object :) i'm adding two functions now: vget_limits_default_mask (const char *domain, int *mask) vget_limits_enforced_mask (const char *domain, int *mask) but I thought about making some changes to vset_limits/vget_limits plus changing the structure of .qmail-limits/mysql:vpopmail.limits to drop all the disable_* and replace it with the masks. i'll also add an update script which makes the necessary changes to existing .qmailadmin-limits/mysql:vpopmail.limits only someone would have to alter the qmailadmin for me (i've never touched that thing :) ) (well .. i will only start with the altered tables/.qmailadmin-limits files if you say it's ok.. I don't know how many out there are already using vlimits. i think the masks help adding future disable flags without having to change the table structure every time, so yes, we have a incompatible update this time, but _only_ this time) -- Mit internetten Grüßen / Best Regards --------------------------------------------------------------------------- Justin Heesemann ionium Technologies [EMAIL PROTECTED] www.ionium.org
