SL projects update week 9/2: group bans update

Group Bans, or Group Ban Lists as I’ve tended to refer to them, as some people appeared confused by the term “group bans” and have taken it to mean banning groups from parcels or regions, is nearing a status where it will be ready for testing on Aditi.

“I’ve gotten the backend almost ready for release (I’m waiting on some builds at the moment),” Baker Linden said of the server-side element of his work, while speaking at the Server Beta Meeting on Thursday February 27th. Baker is hoping that the viewer code will be appearing in a project viewer in the course of the next week.

Recap on Functionality

Baker Linden has been working on the ability to ban people from groups for some 10 months
Baker Linden has been working on the ability to ban people from groups for some 10 months

While discussing the project status, Baker gave a recap of the new functionality:

I’ve talked many previous times about group bans, and now that it’s finally boarding the release train, I’d like to just do a quick overview of what known issues are and what it can do:

    • Group Ban provides the ability to permanently prevent a resident from joining your group.  Currently, the limit will be set to 500 bans per group
  • By default, only Owners will have this ability set
  • Owners must then grant the ability to the roles they want to have manage the ban list
  • You can ban members from the “Members” tab of the group panel, and pre-emptively ban residents through the new “Banned Agents” tab
  • The “Roles” tab will allow you to grant the “Manage Ban List” ability to a role.  when doing this, keep in mind that allowing this ability will also automatically grand the “Eject Members from the Group” and “Remove Roles from Members” ability
  • You will NOT be allowed to disable the “Eject” and “Remove Roles” ability while “Manage Ban List” is allowed
  • You will also be able to (hopefully) batch up bans in groups of 100 at a time (through the “Banned Agents” tab). [It’s the] same as inviting residents; it’s the same code, I just refactored it so I could use it for bans too.

In the initial release, group members can only be banned from within the group floater (right-click on a name and click the Ban button), it will not be possible to right-click on a name in group chat and ban the individual; however, this may be added in the future, as it is considered a relatively straightforward addition.

Group Ban will introduce a new tab to the Groups floater, called "Banned Agents"
Group Ban will introduce a new tab to the Groups floater, called “Banned Agents”, allowing group owners and designated roles to ban people from joining a group

A FAQ has been produced, purely for the purposes of testing on Aditi, but which also helps further explain the group ban functionality. This can be found here, but do note that:

  • The instructions apply to the yet-to-be-released project viewer
  • The final functionality of group bans may vary from that described in the FAQ as a result of bugs or issues arising during testing.

In order to function correctly, the ban ability requires that the Eject and Remove Roles are enabled, as Baker explained above. To make this clear, when a group owner grants a role the ability to ban people from the group, a pop-up will be displayed reminding them that Eject and Remove Roles will also be granted. Similarly, when the ban ability is revoked, a message is displayed confirming that both Eject and Remove Roles have also been revoked.

Known Issues / Initial limitations

  • There may be an initial issue with the new capability during initial deployment as the code starts to reach Agni, when there is the “new” and “old” server-side code running on different channels. This may result in someone being able to re-join a group after being banned, simply because the ban was executed on a simulator which does not have the new code. Obviously, once the code is fully deployed to Agni, this will no longer be a problem
  • There is a risk of some “overlapping” bans may not be processed as anticipated. For example, if two people have the ban role, and one bans users A,B, and C and the other C, D, and E at the same time, “C” should be banned, but there is a slight chance this may not be the case
  • If two (or more) people have the ban ability, then their own view of the group member list will not be updated to reflect bans made by others until such time as they refresh the list
  • The list will cap-out at 500 bans. When that limit is reached, someone with the ban ability must remove names from the list in order for new names to be added, otherwise further ban attempts will fail.

Group Bans represents some 10 months of work for Baker Linden, including a large amount of code refactoring on both the server and viewer sides. The capability still won’t be deployed to the main grid for a little while longer, but progress has now reached a point where more widespread testing should be taking place on Aditi, most likely starting in week 10 (week commencing Monday March 3rd). Deployment to the main grid will most likely remain a combination of resolving any unforeseen issues during the more widespread testing on Aditi and on how it takes for the viewer code to progress from project viewer to release candidate to release viewer.

13 thoughts on “SL projects update week 9/2: group bans update

  1. Question: With Baker’s group ban functionality, will a group “officer” (i.e. a role that was given moderating and administrative powers and duties by a group owner) be prevented by the system from banning a group owner? I’m asking, because we wouldn’t want groups to become vulnerable to takeovers.

    Like

    1. Owners cannot be banned from their own group. Those with group ban rights can, however, ban one another.

      Like

  2. What a great feature this is! Thank you, Baker Linden, for devoting so much time to its perfection. I hope this release also fixes the problem where a member can be ejected from a group but can still harass others in group chat as long as they are online.

    Like

    1. Actually, given the amount of group spamming, together with trolling and baiting that goes on within groups with open enrollment, this is a feature what has been long requested by many group owners. As such, it’s hardly a waste of resources on Baker’s part. It’s a response to user requests and JIRA.

      Also, just because work has been invested in this, doesn’t mean that other issues with groups are being ignored.

      Like

      1. So i just be really lucky cause on the 42 groups i belong to, some of them with more then 1000 users, i didn’t noticed any trolling worth notice!
        What i do know is:
        Chat lag on group im or not even able to establish a connection to the chat!
        A daresay to low limit for the groups one can join!
        That is what i face every day!
        And Yes, im glad to know that these problems are also being sorted and i understand (do i really?!) the need for LL to justify every single fix or progress they are making (at least they are communicating, more important that then any!)

        Like

    2. What Inara said. Open enrollment groups are often seen as a free-for-all for various lower forms of online life whose only purpose is to ruin enjoyment of SL for others. Kudos to Baker for his hard work on this.

      Like

    1. Account linking isn’t something that is officially supported within the viewer. Ergo, banning alts on the basis the main account isn’t possible with either group bans or estate access bans.

      Like

Comments are closed.