• check if a given user is a member of a given group
• give a user's role, status, last-login-date in a given role.

[Text of SVC-1172:

As per http://nwn.blogs.com/nwn/2008/01/robin-linden-on.html and MISC-208 there is a need to reduce the number of groups that users have to be concurrently members of.

llGroupInvite(key agent, string role);

Sends an invitation to join the script's group in the indicated role to the agent. If the agent is already a member of the group, then they are simply assigned to that role.

llGroupRemove(key agent, string role);

Removes the agent from the role. If that was the last role the agent was in, or the role is "", the agent is ejected from the group.

Restrictions:

Script must be owned by an agent who is a member of the group allowed to invite users to the group and role provided.
Script must have the (new) permission, PERMISSION_MANAGE_GROUPS, granted by the script's owner.
Optional: for llGroupInvite(), script must be called from a touch event and agent must be llDetectedKey(0).

llGroupInvite() would be strongly throttled, to prevent it from becoming a load on the database system itself.]

I'll mark it as a duplicate and close it. (DONE)

As such I would like to point out for those who want automatic group invitations for things such as content control (renting mainland, vendor space etc.) then VWR-174 holds an alternative for these cases.

I see it being unlikely that we'll get scripted support given the huge amount of extra work it would require of the group servers.

See SVC-1173 and my comments in SVC-208 for further discussion of why this would work.

Also, I fail to see what SVC-208 has to do with it, did you mean a different issue?
As for SVC-1173, LSL control wouldn't help at all, as the group you want to "suspend" would require you to be IN IT in order for your object to let you re-join as required. It would require groups to have their own "suspension servers" which would require users to constantly teleport to them in order to re-add themselves to the group under their previous role.

Why would llGroupRemove() require a role to be specified? For it to be related remotely to SVC-1173 it should return the user's role (or empty string if they weren't a group-member) so that they can then be re-added under the same role. As you've detailed it the script would have no way at all of knowing what role somebody was in the group. Lastly to work at all it'd really need to be a dataserver-based implementation due to having to fetch group-data.

We seem to be talking at cross purposes. The only thing that is required for the object to store is PERMISSION_MANAGE_GROUPS. When it performs the llGroupInvite() operation or the llGroupRemove() operation it would follow the same code path that is used when a group administrator performs the same action. This would not add any load over the current situation where a human or a bot performs the same operation, and doing it in-world would allow the group table to be significantly reduced in size as people get used to using tools like this instead of staying in-role all the time.

This is a more general tool than needed for SVC-1173, and if the goal was simply to allow that llGroupRemove() and the role argument to llGroupInvite() wouldn't be necessary at all. I agree that just for that purpose this would be a far less desirable mechanism than implementing SVC-1173 directly. The situation wouldn't be as bad as you make out for most cases, for example the rent box in a vendor space or house would be able to call llGroupInvite() for the tenant, who would be there anyway.

llGroupRemove() would accept a role to allow you to only remove them from the role, you'd provide the empty string to remove them from the group completely.

llGroupInvite() similarly has the role option to allow you to put someone into an administrative role.

There would be no return value, to allow the operation to be asynchronous.

VWR-174 is also useful (albeit misfiled :> ). Any of these solutions would serve the purpose. You may note I already voted for it.

As for VWR-174, I wasn't aiming it specifically for you but for anyone interested in this. As for it being misfiled, it was posted back when SVC had no script option, I'm unsure about posting it again, I suppose I should, it took ages to get its 9 votes but then that might be because of it being VWR, such a conundrum =)

[edit] VWR-174 is now filed under SVC-1466 =)