Many suggestions and much progress made [#1095310]

Hey,

We began our conversation over at #318082: Issues Problems with Invitations, Group Types, Access, etc...

I think you did a great job with the module so far, but there are a ton of things that need to be added, fixed, tweaked, worked on, etc. Being that I need this sort of functionality straightened out for a project that I'm working on, I decided to spend some time working on this (actually, completely reworking). I'm very interested in becoming a comaintainer so I can bring all these changes in - please add me if you're okay with that.

Changes made: (real sloppy shorthand notes)

use db_placeholders() instead of implode()
use hook_menu_alter() to remove old OG invitation page
use hook_og_links_alter() to change invite link in group details block to our page
changed invite form title from 'invite members to mail' to 'invite members'
changed path from */invite_user to */invite
removed unneeded page callback og_invite_link_invite_page() - used drupal_get_form() instead
added the entire group node into the form to avoid a node_load() on submit
not sure what $form_state['values']['results'] (on invite form submit) is supposed to be, so it's removed
og_invite_link_send_invites() turned into og_invite_link_send_invite() [meant to only take one user]
og_invite_link_send_invite() meant to only handle the inviting, no messages, etc, so it can be a generalized function
removed og_invite_link.inc and the "gateway" function
removed og_invite_link.model.inc and the "gateway" function
checks to see if the invitee is already in the group before inviting
check to avoid duplicate invitations on the same form submit
filtered for XSS on invitee list!
filtered for XSS on additional message!
added incrementing id as primary key to schema (will have to reinstalled)
removed used of $invitation->is_new to determine if a invitation is new or being updated
moved invitation data generation to the function that saves the invitation; so it can be centralized
allowed users to be invited more than once to a group (what if the invite is lost?)
-- when a user accepts an invite, the other pending invitations are deleted
added token to the schema so it can be used to query for specific invites (since users can have multiple pending invites)
created an access callback for the invite form
-- allows admins to always access
-- allows group members to access as long as group isn't closed
if logged in user follows invite link and doesn't match UID in URL, deny access
moved most access handling for the join access callback into the page callback
-- gives ability to offer messages for many conditions instead of a access denied
-- gives ability to redirect to places other than the group home page, to avoid access denied on private groups which acceptance must be approved
make sure the user account on invitation is active before logging in
delete invitations whenever a user is deleted
delete invitations whenever a group is deleted
invitiations are tagged with a moderation flag, meaning if an admin sends an invitation, the user is automatically accepted. if a normal group member sends the invitation, the membership much be approved by the group admin, unless the group is open

This ends up with an invitation access structure like:

open: anyone group members can invite. invitations will auto-join the user without approval.
moderated: anyone group members can invite. invitations will have to be approved by the admin. admin-sent invitations will automatically be approved.
invite only: anyone group members can invite. invitations will have to be approved by the admin. admin-sent invitations will automatically be approved.
closed: only admin can invite users. admin-sent invitations will automatically be approved.

-----

I attached an entire tarball of the module because a patch didn't make much sense given the amount of changes made.

I haven't tested this too thoroughly yet, but will continue to do so. If you like what you see, please add me as a maintainer.

Thanks