« Joshua Nightshade Lies: Revisiting CopyBot | Main | FIC '09: M, Save Our Sims! »



Feed You can follow this conversation by subscribing to the comment feed for this post.


What are you talking about? It's not marked critical. Nothing has changed on those issues since May.

Of course I agree with you that it is a bug that should be fixed.


Yes it is, link was incorrect. See here:

The other link is to the "feature" Soft proposed out of the actual bug.

Ace Albion

I'm guessing people are seeing that group shared objects would allow you to return as if they are your own (even if not to your inventory) if you're a member of the group the object is shared with. That being a kind of ownership permission you have as a group member. Versus the power to return other users objects (ie the kinds of objects that would be returned if you have autoreturn on your land) which is the group role?

I don't know which way it should be, but if buried prims in linksets have wierd perms/settings infecting the whole object like that, then it definitely needs to be fixed.



Here's the issue.

The group tools as originally created reformed the hippie stuff in them. That hippie stuff included making every single payment distribute entirely to the group, with no way to calibrate. That hippie stuff included making every single piece of land owned entirely by the group, with no ability to differentiate who did what on it.
that hippie stuff included "officer recall" which seemed like a great way to prevent tyrants at the time.

That meant that any common member of a large group could flip the switch on a vote for "officer recall," and that officer who paid for the land, and paid all the tier on the land, could suddenly find all this actions frozen in a group he paid for! Furthermore, no new members could come into the group.

The only way he could stop the officer recall, which would run 30 days and keep collecting votes until he might be expelled, was to leave the group. But what if no one invited him in?

This was terribly risky, but people made such groups anyway, trying to failsafe them with alts or trusted partners. This constantly broke down, as griefers realized the best way to terrorize a group was to flip the recall on the owner and hobble him with annoyances. It was insane. It took enormous numbers of reports and documentation of how this was really being used (never to get rid of real tyrants) to get it to change.

And in the course of granulating group roles, there was differentiation among the types of people who could be members of a group, and access "share with group".

The issue is simple -- if you have every single ordinary member of a group that is meant for a club, or a rentals, or some kind of joint art project, or university, able to access and move all prims, havoc can ensue as you get a combination of newbies, griefers, and disgruntled people with axes to grind wrecking the project.

I had to remove all modifiable rental homes because anything left in "share" could also get a malicious script popped into it non-paying tenants, for example.

A group build could no longer distinguish between, say, club-goers and students, and the owners or teachers who didn't want the average visitor to join the group and return an entire shared build that people who built it wanted to interact on.

Deeding TVs, or deeding objects taking money to pay out to the group, only some of whom were checked off to get payouts - all that got defeated.

It was NOT the intention to make every single group member have all the features of access to share -- and that was changed. It was changed as you can see by opening up the group tools: you get to check off whether a given person, and a given role for that person, gets the right to access, move, deed, and get distributed money from group objects. That's vital for normal business.

In a rentals, you want tenants to be able to deed TVs after they pay. But if you have an open group, or a group that also has another role, like visitor or event-attender or something, you don't want that category of people deeding -- and selling to themselves, for example -- media.

You would also want someone paying and intended to be a group member with greater powers able to return non-group items that fell on their land. But you don't want that category of people all able to return group-set prims put in share, or they all start returning neighbours' prims they don't like, or accidently return fellow tenants' prims or management prims.

The issue of the one prim in a linkset with the "shared" throwing off the entire thing is merely a subset of this problem. All that meant was that if you had, say, a prefab, that didn't seem as if it was put in "share with group," and yet some one piece of it was (say, a permissions set on a box to tint the windows), then the entire thing could be sent back to inventory.

The Lindens, and a handful of JIRA regs, decided that this wasn't a bug (though it *was* because you can see in the group tool functions that group return powers were intended to be granulated, and once worked that way).

With the tools themselvs containing granulating powers and boxes to check off, I had to marvel and roll my eyes that these Lindens proved so resistant for a year to getting it about these powers.

But what happened is that the hippies and technocommunies began to cry, "Creativity! Collectives! Commons!" and began describing all this as an example of how "everybody" should be "equal" and be able to move and return everything at will.

And as I kept pointing, all this only increasingly closed the society, not opened it, as you would have to forcibly move to a closed group to prevent griefers and newbies and casual passersby from wrecking stuff.

Instead of having open groups that in fact could be encouraged for convenience and greater participation, but with merely some powers checked off or not checked off.

Darien Caldwell

If you did a survey I think you would find most people use groups in a very blunt way because of issues like this. Most groups have two roles. The owner who has the power to do everything, and the members who have the power to do nothing.

The reason you rarely see anything in between is because any other combination of settings becomes a minefield of odd behaviour and unintended consequences. Groups in SL are one of the most convoluted and broken systems.

If the settings worked straightforward and as a normal thinking person expected, it wouldn't be half the issue. But the maze of exceptions to every rule makes it confusing and far from user friendly.

Having the restrict power checkboxes actually restrict powers would be a good first step in making groups more useful to the average person.



I realize it's fashionable to declare everything in SL as "broken," but in fact groups aren't broken. They are 180 percent better than they were before the hippie stuff, and if this one bug is fixed, which isn't such a problem once you clear the ideological hurdle around it, it will be fine.

Group chat lags, but I think one of the reasons that happens is that the Lindens can't bring themselves definitively to put hard limits on group membership. They let people run groups with 2000 or 5000 members, some of them even landed, so that dbase calls are ridiculous, constantly calling to see how can do what.

They have trouble restraining anybody, and if anything cave to special pleadings like the call to have an additional granularity to mute some people in the group but not others, yet keep them members bound to hear chat. So that means even more db calls, just so that divas and BDSM masters can keep their people in thrall with ads and directives, but keep them shut up.

There isn't any maze of exceptions. I think you've never actually studied and used these groups. Do you own groups? Are they big? Are they landed?

The checkboxes all do restrict powers, except this one. This one fell out, and stopped working. I can't even be sure that Lindens themselves shut it off.

It's fascinating to see how it is "critical" now and they are fixing it.

So I can only speculate that some big customers got to M with this, on the dev list.

Sean Williams

'Share with Group' gives the group permissions it would not normally have on an object it does not own.

Doing so when an object is not deeded to a group is NOT a bug in the Group system.

If an object is not deeded to a group, then Group set flags and permissions should have NO effect.

The better method for 'fixing' this would be to allow the object owner to set which of the three standard roles that are usually present in all groups have the ability to use or alter the shared object.

In this instance the interface would then have a drop down or other additional input near the 'share with group' check box that will allow you to set which of those three roles has access.

The alternative is to remove the ability to share an object with a group.

Sean Williams

Oh yes: There is a difference between a Group Set object and a Group Owned object.

Activate a Group Tag, rez a prim and the prim now has the active group Set to it: A Group Set prim.

Group Owned objects and prims are those which have been deeded to the group and now show the Group as the Owner.

Group-Set prims fall under the individual user permission system. Group Owned prims fall under the Group Permission system ... This is the way it should operate.

The way your JIRA entry is phrased, you are looking to alter the permission system for individuals in such a manner as to remove their ability to alter their own objects while they are still set as the owner.

The simplest way to fix this if you truly are using or truly did mean Group Set objects and not Group Owned objects is .... Deed the objects to the group! There is no need to 'share' an object with a group that already owns it.

Ginnevra Allen

I don't get it. If you don't want to share with a group, then don't share it. Sharing should not be redundant to deeding.

Yes, it's wrong that an item with one shared component that isn't the root prim can be returned, but the idea of sharing overriding normal object permissions to share with the group makes sense and there is no reason why it should be subject to group restrictions that apply to deeded objects.

If you have a problem with griefing via shared objects, that's a different issue. Either deed the stuff or don't share, and set up a policy to discourage sharing by tenants.

Prokofy Neva


No, you don't get it, but perhaps that's because you refuse to apply the same literalist tekkie thinking that you are willing to apply to everything else.

People who do not have the roles to return group-set items cannot normally return group-set items.

They can't return group-deeded items, either. Neither group-set, or group-DEEDED which utterly turns over the object to "the group" can be returned, i.e. so that guests can't return builds, etc.

So...why is it that an object that is merely group-set, and NOT group-deeded, but put in group SHARE can be returned?

You can't return group DEEDED. You can't return group SET. So why group SET plus group SHARE?

Not logical. Not technical. Not reasonable. It is in the category "set" and one shy of the category "deed" so it should not be returnable, full stop.

And that is indeed how it USED to work.

Why should the tranferral of an object from my ownership to group ownership secure it from those who aren't authorized to return it, but there mere "sharing" of the object opens it up to non-authorized persons? Makes no sense.

As there has sometimes been a bug that enables non-authorized to access deeding, too, I simply avoid the sharing and deeding of anything if I can help it. The exception is TVs.

I don't put things in share anymore, although it's a huge nuisance not to.

And I'm constantly plagued by the vestiges of the Linden hippie era, as everything in the Library is already automatically checked off for "anyone can move" and "share with group" so that means every flamingo, stone tile, party hat, etc. etc. that tenants pull out of the library is open to griefing.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)

Blog powered by Typepad