Well, I'll Be Damned

Take a look-see at this. Incredible.

Another time I'm vindicated on the JIRA, after being harassed, brow-beaten, bullied, and resisted by the "regulars" there on that "science project" at the "Lab".

And resisted even by Lindens, who told me my bug was "expected behaviour"and who told me the bug should be "campaigned for in public triage" to be recognized as a feature. Sigh.

In a nutshell, what happened is that group roles and their powers stop being respected when this bug occurred. It's the sort of thing likely only a large rentals group or big community project trying to share things but keep them from being griefed might notice - private islands that are locked down like Leavenworth might not notice it as quickly. While the group roles enabled you to decide who in your group should be able to return a prim set to the group, and who couldn't, the system -- vital for rentals, clubs, group projects, etc. -- became overridden by the bug. Havoc ensued, as people who shouldn't have been allowed to return entire builds got to return them, and as people joined the open group and used the ill-gotten powers to grief. A crazy neighbour joined my open group and returned a house with just one piece accidently in "share" out of spite; newbies accidently got grief scripts because they didn't get the difference between "share" and "set" to group. That was all unnecessary.

I  just couldn't get the Lindens to grasp this, and of course, amidst the din of all the asshole regulars, like Harleen Gretzky and McCabe Maxsted, both of whom fisked and literalized and bullied me for 10 months, it was hard to get the case heard. It shouldn't have been; that it is, is a disgrace.

Most startling, Alexa Linden, who has been a Doubting Thomas with me before, and Soft Linden, who takes the opensource script kiddie side on every issue and never thinks of business issues, were trying to drive me and other concerned business people to suddenly defy the logic of our senses and our actual experience, in the creation and reform of new group tool features over the last 3 years, and suddenly declare something malfunctioning not as a bug, but as something we wanted to change with a feature. Soft told me to show up at public triages and "campaign" for my "feature" -- which is now -- finally! -- recognized as a bug. Nearly a year after being reported. Bleh.

Then I had to deal with that freak Lex Neva, who falsely claimed, with idiotic outliar use-cases drawn from some weird group of his, that if this actual bug was fixed, it would "break a lot of group usage". So I had to beat that one back. Soft Linden even had the nerve -- the ass! -- to urge me to "come to public triage" to try to get my feature noticed, and to get "other landowners to vote for this feature". Bleh. Honestly. These Lindens. What does it take?! Why does it take so LONG and why does it take such incredible persistence with them?!

It's this ignorant and belligerence on behalf of Lindens on the JIRA, who are all tilted toward the code kiddies, that so grates. It's that LOOOOONNNNG road to recognition of an issue that in fact these Lindens should recognize instantly as a matter of common sense instead of JIRAhad literalizing.

And it's their refusal to acknowledge the needs of business inworld that just jars so completely. Every once in awhile, I remember with piercing fury, back before group tool reform, how Blue Linden once told me, when a griefer froze me in my landed, tiered group where I was officer, forcing me with a "vote" into "officer recall" to get me removed from the group I payed for (!), that I should "campaign with my group members" and "make sure they vote for me". Honestly, I can never forgive that. My  never forgetting and never forgiving is vital to them getting over their idiot socialism. The vestiges of the hippies there runs too deep, even if they have gotten rid of some of the main hippies like Cory or Daniel.

What's so OUTRAGEOUS about technocommunism is that a freebie freak can come into this JIRA and claim that fixing this bug -- making the group tools work again as originally reformed -- will break his freebie-dispensing object. Sigh. The fact that the bug potentially breaks or annoys thousands of rentals, businesses, and group projects, is, of course, beyond the ken of this socialist.

Funny, today, this bug that I campaigned on for 10 months, since March 2008, is suddenly and majestically declared as "Critical". Why? Some big corporate dev finally pointed out that it is an annoyance to them? The memo finally got to M's desk? And, yes, skeptics, I'm well aware that in fixing this bug, the Lindens might make it worse, or break some other thing, and what is presented as a vindication will crumble in my hands in 6 weeks. Two steps forward, one step backwards...

Comments

[Gigs]

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.

[Prokofy]

Yes it is, link was incorrect. See here:
http://jira.secondlife.com/browse/VWR-5491

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.

[Prokofy]

Ace,

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.

[Prokofy]

Darien,

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]

Ginnevra,

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.