Role Limitations default to authenticated user role

Hi there,
i have created role X (with "send invitations" and "access content" perm) and have disabled all permissions on AU. With this setup i cannot reproduce your issue. Users of role X are always also members of AU. So they get the limitation of the role with the highest maximum invitations setting. e.g:
X = 5, AU = 10 --> 10
X =100, AU = 5 --> 100
So far for the normal system design. However:

If the limitation for "au" is 5, role X gets 5 even though it is set to unlimited.

Normally, and it works with my setup here, if either role is set to unlimited there should be no limit. I need to check that further.
Second, i realized that "unlimited" is accomplished by setting the limitation to 0 which is quite ugly since currently there is no chance to set the limit to 0 (disable invitations) for a given role.

My current idea is to patch the invite.module so that only roles with "send invitations" permission set are considered and available on the settings page.

Ideas, comments?

Patch attached.
Changes:

1. Display only roles on the settings page which have "send invitations" permission set.
2. Only take those into account when
   • escalating the roles for the invitees
   • checking the send limitations.
3. Off Topic: Added another delete query to delete the invitation when invitee gets deleted. Otherwise it is not possible to reinvite a user that was previously deleted.

I only did some testing.
Feedback appreciated.

@mg2020
The invite limit directly correlates to the roles a user has been assigned to. Could you please verify (by going to admin/user) that the users in question have been allocated the roles you expect them to have?

@knseibert
Nice solution. I wonder if we should take the opportunity and get rid of that ugly "zero = unlimited" assumption by replacing it with a constant (INVITE_UNLIMITED). Will do some testing now. Converting to using a constant could always be done later, of course.

Re deleting the invitation when invitee gets deleted: Yea, it's off-topic and it faces us with a problem: normally, when an invite is canceled, a corresponding API event is triggered. This would f.e. result in reducing the inviter's userpoints gained from inviting this user. Should this happen here, too? Or do we need a new API event to be able to differentiate deleting a user account from canceling pending invites? Or (as you did it) should happen nothing at all?
--
Stefan Kudwien
_{unleashed minds}

- Fixed the missing permissions message.

Hi Stefan,
i'm not familiar with user points, but i think there should be some sort of event triggered. Otherwise 2 users could push their points by inviting and afterwards deleting the account.
A invites B. B joins. A gets points. B deletes his account. A invites B again and again. Or does the user points module work differently? Again, i'm not familiar with it.

Yours

Kai

@knseibert
Yes, that's exactly how it works, and there lies the problem of the added DELETE query: the current code *is* protected against misuse, as the invitation record remains in the database and thus wouldn't allow a second invitation. With the added deletion however, this is no longer the case.

I'd like to commit the other changes, would you mind creating a separate issue for that?

Committed to 5.x branch. Changing category to feature request means: no backport planned.

@knseibert:
I will add the query to delete invitees of the user about to be deleted after checking the value of the Allow deletion of joined users option. With this option enabled, you could never run a reward system together with Invite, because everyone could cheat (intentionally). When this option is disabled, however, comment #7 still applies. If you feel this is not enough feel free to open another issue.