Retroactively change invitation limits

What is the use case for storing invite limits per user? As long as I can't see a use case I would prefer to pull this bug (feature!?).

Assuming there is a valid use case for this, the correct way to implement this is to ONLY store the per-user limit IF the user's limit has been overriden. If a user's limit has been overriden then the role limit/s for that user can never apply.

I also have a use case for this. I have a website where users could earn invites based actions.. or possibly buy invites with userpoints.

I see. That makes sense. So could we assume that all websites want to apply invite limits either; per role (invite.module's default setting) OR per user (e.g. with userpoints or ecommerce etc.)?

Would we be neglecting any other way of using invite.module if we made this assumption?

If so, Invite module should never set the per-user limit. This should be the responsibility of other modules that integrate userpoints and invite, since invite module can never know how to initially set the limit or when to change it.

Invite module could provide an optional extra module (or possibly an internal feature?) that provides an API for per-user limits. This would primarily provide a storage engine for user limits (it's own table, not the user table) and functions that get, set, increment and decrement the invite limit.

This way, the only time invite.module needs to do anything with the per-user limit is when it is getting the limit for the current user, in invite_get_remaining_invites(). It should be able to determine whether the site is running in per-user or per-role mode, and get the limit appropriately.

If per-user mode was a feature in it's own module then table creation and mode-detection becomes easy. Table creation and schema maintenance go in the per-user module – say invite_user_limits.install, and invite.module knows whether it's operating in per-user mode if module_exists('invite_user_limits') is TRUE.

Doing this in invite.module itself is less clean because the per-user-limits table would be redundant for most uses of invite.module.

What do you think? Is this a suitable solution?

I can work on this a bit over the next few weeks, but need to know that the maintainer is on board and I have the right solution.

For now I'm commenting out one line in invite_get_remaining_invites() to work aroung this bug, as per the attached patch.

A cleaner variation that avoids setting the limit on the user object altogether.

So, as I understand, new values won't be saved anymore. But, how can I get rid of the existing limits? We upgraded the limit from 1000 invites to unlimited, but our members still see the old limits. Where are they stored? Is there any chance to flush these values?

Any help is appreciated.

truelove, the patch in #6 should do what you want. Note this is a hack and should only be a temporary solution until this bug is fixed. You could also use the patch in #7, but would additionally need to iterate on {users}.data, unset($data['invites']) and resave the user/data.

Thanks Bevan. I used patch #6. Limits are not visible anymore.
Patch #7 is too complicated (for me).

subscribing

subscribing

I am closing this issue, since it's for a Drupal version no longer supported.