> > Not anymore. This has changed with 5.3. The .qmailadmin-limits > > is now extended into vpopmail and is now enforced at the domain > > level as well as setting default quotas for users. The old > > method allowed you to set a single site-wide HARD_QUOTA. > > And how does that apply to adding a user?
The limits specify what the default quota should be, and what the default permissions should be. When adding the user, the domain limits should be checked to make sure they're even allowed to add another user. Note that these are just new features. I'm also confident that additional features will be added. Using a set API call to do the validation and manipulation of the backing store makes enhancements smooth and easy. > > > > a patch to actually enforce these limits at, yes, the API level > > > > where it belongs. This *will* break if you insert into a > > backing > > store directly. > > > > > > Exactly what limits are you refering to? > > > > quotas, permissions (limiting what a user can do), etc. > > I set the quota, and it's very easy to limit what a user can do as well, if > you understand how it works. I'm not saying you don't have to write your > own logic for some of this, but inserting a record into the mysql database > to add a user is not only an acceptable method, but one supported by the > developer. See Ken's post to the list. So if/when features are added to the vpopmail package you may or may not get them since you bypassed the API. So then if you think you like an added feature, you'll have to write it each time rather than just benefit from it with an upgrade. The only thing I'm trying to say (which was the same from the start), is that I believe inserting the data directly into the backing store is a kludge. I didn't say it wouldn't work. Thanks, Brian
