> 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)
There were discussions on this and we determined it would be best to keep them separated out for those that read directly from the table (and I happen to have java EJB's map the attributes to these columns). Another purpose of separating them out was to allow search conditions on the elements, which is difficult with masks. Since the new field would be just a default value for the GID field of the password entry, I don't see any problem for this field being an int. > something like enforced_domain_permissions and default_user_permissions .. but > if it's to late to change that now, i won't object :) I don't think it should change. I actually use it with the individual fields and find it useful. > i'm adding two functions now: > vget_limits_default_mask (const char *domain, int *mask) > vget_limits_enforced_mask (const char *domain, int *mask) Don't think you need to do this. The limits are stored in a structure. You would only need to add a single value (the mask) to the structure, then add the code to parse it out of the .qmailadmin-limits file (and write it), and add the field to the mysql table definition and queries. The API would remain the same (just a get/set of the structure). > 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. Please don't. > 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) Its not hard to add a single field, however I went and added several (pretty much everything that people suggested months ago) but haven't integrated all of it into qmailadmin or the other programs. I have some in an older version of qmailadmin that I'm still using (haven't submitted a patch yet). > > -- > Mit internetten Grüßen / Best Regards > --------------------------------------------------------------------------- > Justin Heesemann ionium Technologies > [EMAIL PROTECTED] www.ionium.org > > Thanks. Brian
