The question is whether this is worth it. My opinion is a guarded "yes". This may cause some confusion and hassle, but ultimately, it makes a lot of sense. It'll also limit inadvertant granting of permissions when people accidentally share stuff (or rez shared stuff, ie a few of the library items!). People have suggested that shared objects owned by others have been used by griefers as the first item in a grid-bomb, thereby "framing" someone for the crime.

Here's the situation:

I have a sim that my group and I built. All of the structures in the sim were built by us, and we share everything with our group so that we can all modify the buildings. The main plots in the sim are set to autoreturn, and the land is owned by the group, so our build doesn't get returned.

We have a building set aside for vendors, and it's on its own plot. The plot has our building on it and the vendor objects owned by our vendors.

We'd really like to have autoreturn, but we can't. We can't invite the vendors to the same group that our buildings are set to, because we don't want them to be able to edit our buildings. We can't set our buildings to the Vendor Group, because, again, we wouldn't be able to share them with each other without giving modification rights to our vendors. Since there are objects on the land that are set to two different groups, we can't set autoreturn, because one of the sets of objects (our building or the vendor objects) would get returned. So we're stuck, no autoreturn.

If this feature request were implemented, our solution would be straightforward. We'd simply set our buildings to the vendor group, share them, and only grant "modify shared objects" rights to our builders. This makes sense anyway; we don't want our vendors accidentally clicking "share with group" and giving each other the ability to steal "free samples" of products.

I vote yes on this feature. It might be nice to actually add a new group permission for shared objects, rather than lumping this into the one for deeded objects.

I ran into a problem with this once. I built an arena with a friend. Objects shared with group so we could both do stuff with them. That group was then later used for the members of the arena. After a few hours, someone pointed out that group members were able to grab full perms copies of my 1337 scripted tiles...

I've seen them in a few places since that incident. Most worrying. I definitely think only people with the permission to manipulate these objects in the group, should be able to do so.

What on earth is REALLY driving this?!

It breaks the functionality of the perfectly good functioning group roles, that have some checked off to return items and some not based on the status "group set" or "not group set".

And returns this odd bug that was in fact declared a bug!!!

I can't BELIEVE you Lindens are doing this, and returning the hippie crap to the group tools again, and allowing anyone in the group to manipulate group-share objects. Why are you dong this? Out of some false sense of programmer's symmetry in a void, completely cut off from the actual functioning and use in the world???

No one asked you to change this, there is no JIRA proposing this.

The whole reason you have to granulate the right to manipulate group-set objects is to prevent griefing.

Griefers routinely enter open groups and then drop malicious scripts into objects that are set "share with group". The w-hat/b/tard/PN behaviour in repeatedly putting awful obscene particle-spewing scripts into group items that kindely landowners wanted an entire group to be able to use (say, tables and chairs they wanted people to move into seating arrangements, or prefabs that they wanted people to be able to change the wallpaper on). This was all defeated by griefers, forcing people to a) close groups completely and invite people into walled gardens one by one or b) stop putting out shared items for the convenience of group members.

Oh, you say, just don't have an open group. But...Why? This is social media. You should be able to have a group open to all at a general level, to be able to do the most basic thing – set prims – and then work up from there to greater degrees of involvement, being able to return the non-group prims, or return the group-set prims.

That was the whole premise of the reform of the group tools especially for use with land and group builds. Granulate, not have an imposed socialist commune.

There basically is only one wide-spread use of 'deed to group": media, in order for media to work on group land. There is also deeding of security orbs to work on group land; there might very rarely be deeding of a group object to pay an entire group, but most groups don't risk this because it has too many vulnerabilities to griefing and too much buggyness and/or annoyance to it.

Before this reform was implemented about 2 years ago, mainland rental agents were at a terrible disadvantage compared to island agents. Island agents could deed a parcel entirely to a person "buying" land (actually purchasing a long-term lease as a deed) and because that person had their own group with themselves as officer, they could deed their media any time by themselves.

Meanwhile, a landlord on the mainland who couldn't deed away a parcel without losing the property completely (and making the tenant then assume tier to LL) couldn't give the tenant his own group – he had to have the tenant join his group. That mean that he had to do the tv and video deeding constantly himself, as there was no granulation in the roles.

The reforms brought the ability of anyone with a separate status, call it "resident", to handle deeded items to be able to deed their own items.

Currently, most rental agents give only paying tenants that right. I currently have two tiers – tenants who do not have this status, so that griefers joining the open group and gaining tenant status cannot invade deeded objects and drop malicious scripts in them or steal transferable TVs (another problem) and residents who have the right to deed objects, but who still have to set them to sale and buy them back to take them again (an annoyance).

(Share with group is irrelevant. I actively discourage everyone from ever using it as it only leads to griefing and theft.)

The fact remains that the current release version is buggy, even with your DESIRED design (it isn't CURRENTLY designed this way) because those who do not have the right to return group-set prims, for whom the role box is not checked off, are able to do so anyway – currently there is no role box that says "if shared with group, then able to return group-set prims."

What truly torques me about all this, Soft, is that you are proposing this without any consultation with those who actually use groups, and large groups, and run businesses with groups, and get your "consent" about this from a handful of scripters on the JIRA itself.

Lex's comment regarding a new permission is only a comment. I don't agree with it. I think SVC-121 is a valid bug.

"Share with group" is a vestige of the old pre-role system that should not override the newer role system that replaced it.

Any inconvenience caused by some group owners needing to tick a single check box in the "Everyone" role to get the old behavior back (if they want it) is far outweighed by the benefit of fixing this.

Also, you are correct, no one that knows what they are doing deeds an object to a group unless absolutely necessary, like because of media streams.

It's vital to be able to separate within a group the ability to share objects which is the first step in deeding them and then putting them to sale as group objects.

There is absolutely no reason why this can't be kept separate as a role function, there is no whatsoever to merge it, and no Linden has justified it in the slightest.

It is not a "vestige" because it's a function that currently, doesn't work as it used to and is broken. Even if not checked off for the ability to share, 'everyone' can share.

As I remember, my first blog post ever made two years ago was to comment on group permission risks with the current settings.
http://blog.secondlife.com/2006/08/14/when-an-exploit-isnt-an-exploit/#comment-1755

The point being that the current permissions makes any group leader wanting to give mod control having a risk of getting everything returned or deleted on the parcel (basically including permanent builds and items)

In my case I had everything returned a couple times by officers in sandboxes by mistake, which now makes me restrict any permission on group-owned objects completely to avoid possible nightmares of having everything returned. (And to illustrate how easy that is to make such mistake, I would point out that one of my build in Dalton was now returned TWICE by LINDENS, while they were cleaning up the linden village area selecting my object along with it). In the current state I have many objects on welcome platforms of the sandboxes that I can't even deed (for lack of transfer permission) yet I would like to have those protected against such possible "return all" or mishandled "lasso selections" return situations which seems to happen quite often. In my view the permissions are either too loose or too restrictive, we need a middle ground with security measures.

Therefore I would call the need for a "delete/return" permission (in the group settings) of group-owned objects and/or shared object separately from "manipulate" to give more flexibility for a collaborative working environment and mitigate risks of such returns and deletions.

As I've said on other issues that people have tried to reclassify as features, when there is a disconnect between expectations and actual behavior, a bug exists, no matter what the design intent was. There are two general solutions; change the expectations, or change the behavior. A part of "change the behavior" is the option to create a new feature. That option still doesn't eliminate the disconnect between expectations and behavior that existed in the first place. In this sense, the original bug here has never been addressed.

I submit that it may be easier to approach this from the other end, and adjust expectations by making it clearer that group-shared completely overrides all of the fine grained group roles, by changing the UI phrasing or something like that.

Let's go over it again:

1. Lex Neva has a completely convoluted and bizarre solution for the problem of builders and vendors. The elegant and simple solution is to have the bug fixed, and have share powers granulated. Then the builders can share and deed and move objects, and the vendors cannot. That's how it is supposed to work. His solution, bizarrely, is to cripple the granularity, and make it possible for everyone to share, but only granulate moving – a self-referential concept for builders if there ever was one. Most people do not run malls the way Lex Neva does – it reminds me of ancient history, when Anshe Chung used to run two groups for all malls, one for owners and builders and one for vendors, and clear off vendor excess primmage by selling the land back and for to herself in the middle of the night, inevitably inviting ire from somebody who forgot to set to group, or inevitably making mistakes.

2. Most other use cases rely heavily on the distinction of "share". In Ravenglass Rentals, and other rentals, we have open membership for the basic tenant role, which can set prims and set home to here, but not ban or deed media, to prevent misuse of the open group by those griefing or not paying. That enables people not to queue up waiting for an invitation – for malls in particular, this is hugely vexing as often you wait 24-48 hours or more for the group invitation, with the meter running in many rentals.

But even if you do not have an open group, but run your group by invitation only, you still need a distinction between those who can share, deed, move objects, and those who can't. This mainly refers to TV deeding, which is an essential element of group land rentals on both mainland and private islands. You have to make sure that casual visitors who may join or be invited to the group to set prims, build something, be in an event, have a title, etc. aren't also able to right-click and sell back a deeded object for $0 or introduce grief scripts into deeded objects.

3. Thus the whole reason for granulating the roles is to prevent crime. Hippie communal ideals tend to promote crime more than anything else when there are no natural restraints. Right now, the lack of granularity promotes griefing and stealing and wreckage of group builds, not collaboration. I'm forced to vigilantly shut off everything from "share". That means if I used to leave a prefab in "share" to enable my tenant to move or change wallpaper, now unfortunately not only can he return it by accident, people can grief with it – and do.

4. Far from enabling safe and productive collaboration in groups for people managing affairs to prevent crime, and REALLY promoting collaboration, some ideological notion seems to have prevailed here, or else merely Lex Neva's very strange use case.

5. This is not about "expecations" Gig. This change was made to the group tools and worked for more than a year exactly as it appears in the tool set. It used to be that anyone who was not granted "share" could not access it. In fact, one of the bugs I discovered in the beta testing on the beta grid during the group tools beta was precisely this bug, and I immediately explained to Lindens that they weren't thinking through group rentals and the need for deeding and undeeding TVs, and were making it possible to steal TVs or use them for griefing.

In fact, one solution was to granulate "sell deeded object" as a separate power because then officers could further regulate the TV problem – enable people to deed TVs so they didn't have to keep nagging the manager, but discourage theft by having to get the manager to essentially undeed it by selling it to himself for $0 then returning it to them.

The tools functioned normally for a year, before we began to see the shared items first being accessed by griefers, then saw builds returned. And if I'm not mistaken, it was fixed once – and now it is unfixed again.

6. No one has explained whether in fact this is a bug or a feature turned off. What makes it a bug? What are the mechanics of the bug? Why can't a role like this be designated? What is hobbling putting it back?

I'm still confused by your posts. The proposal here is to prevent people without the "manipulate" flag set from being able to manipulate group-shared objects. Setting aside whether this is a new behavior or not, it sounds as though it's what you're asking for.

Here are some things that are in your power to do:

• Lay out a simple, compelling argument without accusations against other residents or rhetoric about hippies and communists. This increases the chance people will read through your post, as they won't assume you're trolling or trying to be humorous.

• Nudge some of your landholders toward either issue to increase the vote. Issues are periodically reevaluated based on high vote counts.

• Show up at a public bug triage and ask that the issue be revisited.

• The usability office hours were created in the time since this issue was created. You can show up there and put forth the argument that the UI is wrong or counterintuitive. Alternately, if you can't attend, make this argument (again, concise and objective helps) in a comment, and add a link to the usability office hours proposed agenda at http://wiki.secondlife.com/wiki/Resident_Experience#Rx_Office_Hours

• You can even bump the priority of a JIRA if you believe you have introduced something new and deserving of attention, or if you believe an important issue has fallen through the cracks. I don't see much argument against this issue, just a low vote count, so I assume this would be safe to do.

Scenario: I have group-set, group-shared and group-deeded objects in a pre-roles context. I use them to give ascending rights to modify those objects. Now roles come along, I go into those and refine my groups rights to match what I expect them to be. But now suddenly "group shared" defies any role restrictions.

New feature X breaks old feature Y. Something like that has been called "bug" in all the centuries we do programming. Suddenly changing the game and calling it a feature-request just makes you look like a fool.

And sorry, Soft, but drop the "bug triage" spiel at once. It's allways been a more non-working than working concept that might help to get some indicators on some bugs that happen to be discussed in the short hour, but it will never be in any way a representative and conclusive discussion of anything. That's what you got the Jira for, it's silly to ask someone working on Jira posts to go to bug triages.

1. Find a group that you either own or know you have permission to deed objects to and manipulate those deeded objects.

2. Rez a plain old cube.

3. go into the object editor.

4. Try to deed the object WITHOUT checking off share with group first.

5. Now check off Share with Group.

6. notice that the Deed option becomes available now.

7. Hit Deed.

8. Delete cube.

Unless I am mistaken here (and I doubt I am) this shows that the current way Second Life handles those options is perfectly fine and normal. With an object set to a group, you are covered auto-return wise on group owned land. With an object set to be SHARED with a group, anyone can alter it. With an object DEEDED to a Group ... The group Owner now gets to decide who can use the object.

Once an object is deeded to a group, the 'share' permission is ignored and can no longer be set at all.

I think a few people here are confused as to what 'share' and 'own' mean.

Sharing is a prerequisite to deeding, so the access it grants should be a subset of the access of deeding. You have demonstrated it isn't. That's wrong and broken.

Mine is that it is fine as is: Only when an object is actually owned by a group should the group's permissions affect who can use or manipulate it.

Lets use a few examples, shall we?

Group A is a group of dedicated builders (either for a specific Sim/Estate or freelance) and their specialty is large scale builds. They would require the ability for an object marked as 'Share with Group' to be moved and manipulated to be able to work as a team and ensure that the build is done on time and with as few mistakes as possible.

Group B is a Sales Group for an in world Company, with holdings across the Grid that rents out spaces for other users to sell their items. This group requires no additional permissions so all they ask is that the items being sold are set to the proper group.

Group C is a rentals business that rents out houses/apartments that are already fully furnished. They only want certain members of the group to have the right to move or alter their objects, thus they have set 'Share with Group' and then Deeded the objects tot he group itself.

With the resent system in place, Groups A, B, and C have just the right permission settings available to make what they are doing possible.

With what some are trying to have Linden Lab do? Group B is unaffected, Group C can now be lazy and remove a step to get their desired effect .... and poor Group A? They now have to take a few added steps to get their old abilities back.

'Broken', 'wrong' and a 'bug'? Depends on your point of view.

I actually was a part of a group like group A. Our task was to get a club built in as little time as possible: we did so.

Kindly do not try to tell me that our ability to move group shared objects around was a figment of my imagination or some odd Second Life Twilight Zone.

Hate ta tell ya this but .... another place I worked for had some issues with newer employees not knowing they could move, alter or even take stuff that was shared with the group. some of them found out about this the hard way: we had a radio, a contest board .... and even a part of the wall accidentally get taken by a group member.

The permissions and abilities exist. The current system works just fine and is really quite simple to use and understand.

Set to Group: No added permissions.

Share with Group: Entire Group gains the ability to move, alter, take, etc

Deeded to Group: Group now owns the object and gets to say who can do what with it.

Oh - and in addition to the examples I gave earlier, the system you want implemented is only beneficial to those who actually created or otherwise run the groups affected by not using the current system properly. Under the system you'd like to implement, a user would lose the ability to do anything with their own object upon hitting Share with Group instead of when they Deed it over to them.

Again, there is a world of difference between an object that is being Shared with a Group and one that has been Deeded (had its ownership changed) to the Group.

That was Soft's proposal, not mine. I merely reported the bug that "share with group" allows actions that surpass what can be done under the group roles.

As I said, at present a Group member has the ability to decide if he/she wants to share an object with the entire group .... or just give it to the Group and let them decide.

I'm sorry, but to my mind the Group should have no say in who gets to use/manipulate an object until it is Deeded.

Now, if there was a way to allow the Object Owner to select which group members are allowed to use/manipulate the object WITHOUT needing to Deed it to the group AND have permission to assign roles and modify role abilities ..... Then perhaps I'd be for changing the current system.

If you join a group that restricts it this way and you do not believe other group members should have that right over your objects, then don't join the group.

As I said: A Group has no right to dictate share permissions, the object is not in the Group's ownership, it is in the ownership of an individual.

Is it so difficult to understand that?

The current system works exactly as the wording would lead a person to think it does: a 'shared' object can be used by the entire group, a 'deeded' object is not at the whim of certain people in the group to decide who can use it as the actual OWNERSHIP of the object has been changed to the Group.

For me at least, there is no compromise on this issue, save one: The ability for INDIVIDUALS to select which members can use a shared object .... NOT those with the proper permissions to make those choices.

Anything less than that is an attempt to remove the choice and control from the user that actually owns the object.

• "Under the system you'd like to implement, a user would lose the ability to do anything with their own object upon hitting Share with Group instead of when they Deed it over to them. "
• "That was Soft's proposal, not mine. I merely reported the bug that "share with group" allows actions that surpass what can be done under the group roles"

There has been no suggestion that the original owner lose manipulate ability - only the question of who gains the ability.

The group should NOT get the ability to 'regulate' anything when an object is shared, that ability and choice should be left to/given to the object owner.

Ciaran, as I've been trying to tell others: retaining ownership of the object is useless if the Group gets to decide who has what permissions for it.

while it would require a complete overhaul of the current system I stand by my suggestion: Have the object owner decide who gets to use/alter/manipulate the object when it is Shared .... not the Group.

Anything less would be akin to telling your real life friends that they can use your computer .... and having them hold a conference in which they decide to set up a user name and password system with someone OTHER than yourself as the Administrator.

to use myself as an example: If I decide to share an object with a Group, I should be able to say "Here, you can use this BUT I don't want John Doe over there to do anything with it, I don't trust him". If this passes it will be more like this: I hit share and the Group is now able to say "Thank you for sharing that with us .... We have decided that you do not get to use your own object. Buzz off."

Now you tell me: Does it sound right to you to give a Group the ability to prevent the actual owner of the Object from doing ANYTHING with a Shared object?

Bug fix versus new feature is a very important point of difference. The latter warrants a much more extensive analysis of current use and potential content breakage. The JIRA and triage sessions are where much of the information for these decisions comes from.

There's also nothing silly about suggesting someone attend a bug triage. If you look at the bug fixes that appear in version changelists, the majority of those were selected in these triage sessions – the triage sessions are very productive. JIRA is where information is gathered for making decisions, and the triage is where the decisions are made based off the information in JIRA. If there's disagreement about the decision made and adding information to the JIRA issue has proven ineffective, attending the triages where decisions are made is a fine way to address that.

And other things wrong with the current system, is share with group gives you more power than just being able to manipulate the object. For instance, any group member can just return the object to the owner. So if the root prim of your 200 prim house was accidentally set to share with group, then any group member can return the whole house to you. And in the case of shared deeded objects, any group member can take the object into their own inventory. So for instance, you have this nice big screen TV deeded to group to play on your group-owned parcel but you want to allow any group member to move it around, so you share it with the group and then poof some other group member has stolen it.

THAT is why I oppose making 'Share' act like 'Deed'. When you Share something, you should not have to give over ANY of your permissions or owner power to the Group.

There is no way to set a Group Deeded object to 'share'. It is either Shared or Deeded, not both.

This would be independent of the manipulate permission, and I believe it would satisfy Prokofy's and Solar's concerns without adding yet another flag to every object.

I respectfully disagree, the object owner is utilising the group, ergo the group permission system should take precedence. Anything group related should be bound to group permissions.

I still have my concerns about this .... after all, my entire objection to this has been that 'Share' would make the Group responsible for permissions and setting who can and cannot alter an object.

Ciaran: It's really quite simple.

The object owner's rights take precedence over the group. "Possession is 9/10 of the law".

If I am still the Owner of the object .... Why, then the Group has to abide by my wishes as to who should use it or be allowed to alter it in any way.

You. Cannot. Unshare. The. Object. If. Share. Is. Set. To. Act. Like. Deed.

When an object is Shared with a Group the GROUP is given permission to use the Object. That is ALL they have been given.

Until the Object is Deeded to the Group, the group does not own the object and should not be able to tell the original owner to buzz off.

Now again, I am all for this new flag that Soft has proposed ..... so long as it does not act like the original permission set which can lock out the original owner upon Deed. So long as the Owner's access to the Object trumps the Group's ability to set these permissions when the object is Shared .... Fine.

If it's what you're asking for - I don't think attaching a list of permitted users or roles to every object can happen unless you can come up with some really compelling use cases. This would be much more difficult to implement and would create several new UI components

I suspect the role ability would cover most needs with a simple code change.

Yes. The owner's ability to unshare would not be changed.

No offense soft .... but since when did LL require 'compelling' case examples to implements new features or change things around? One of the last updates to the server side code BROKE the use of solid vertical walls acting as ladders in a few places. My favorite spot to go to, explore and relax in now has a few areas that cannot be accessed at all (it's a no fly zone).

That aside .... Setting up a system where the owner controls who in the group can have Share access would not be as difficult as you're making it out to be. If adding such a thing to the object itself would require so much work, then alter the actual Group component itself to include a per-user tab allowing anyone in the Group, regardless of role, to select which roles or individual group members can have access via 'Share'. That would not be as difficult to do now would it?

This has nothing to do with trust and everything to do with maintaining the rights of the actual object owner. I would NEVER let a group of friends tell me I cannot use my own computer ... or dictate who else may use it, so why should a Group in Second Life be allowed to dictate this when I'm still the object owner? Maybe there are certain individuals in the Group in roles that allow them to use and alter the shared object that I do not personally trust? I'm not about to leave such a choice in the hands of someone who may not understand the concern. Additionally why should I punish the entire group because of one or two people?

Taking your computer analogy further, if for example you take your computer to someone else's home, you shouldn't be able to dictate that anyone can use it any time they wish just because it's your computer, the home owner can come to an agreement with you but you're using their home and they should be able to say "no" to you if they feel it's in their best interests.

I'm not going to Share an object, especially not one in my home, with a Group and allow someone else to tell me who can use it and who cannot ... and that includes telling ME I can no longer use my own object. I own the Object, I decided to allow the Group to use it, and I should be able to dictate who uses it ESPECIALLY if they have to come to my Home to use it!

Not true, deed an object to a group and then click Share with Group again. And a shared deeded object can actually be taken into your inventory even when you are not the previous owner.

Now, if what you say is true Harleen, then the solution to THAT problem is dead simple: Code out the ability to have a Group Deeded Object Shared among the entire Group.

I am not in any way advocating that a shared object should mean someone gives up ownership, that's what deed is for. If an object owner doesn't like the way an object is being shared then they should very much retain the ability to unshare that object.

The real problem with this comes in some of the examples I've given and REALLY comes in when a group Shared Object is in the home of the original owner. This difficulty is further compounded when a group has no home base (as my own Role Play group for example).

I personally would never expect my Group members (what few of them I have at the moment) to hand over the decision making on their Object usage for a Shared Object to me. I have enough stress as it is: I work at one Club as a DJ, am a Senior Staff Member at another, I run a (currently small) Role Play Group .... and I have a baby here at home.

If anything I'm advocating something that would take another responsibility OUT of the group Admin and Officer's hands.

But another avatar can take into their inventory a shared object, that is not deeded, for which you get next owner permissions.

So, say you just rented a parcel on group-owned land and joined the open enrollment rental group so you could begin to rez objects on your new land. You rez your TV and then go to deed it, so you check Share with Group. But alas Deed is grayed out because you do not have deed rights. So you IM your landlord asking them to deed the object for you, but in order for them to do that you must leave it checked Share with Group. Or you simply forget to uncheck Share with Group. Since the group is open enrollment anybody can now just stroll along and steal your TV.

Let's use a similar scenario except we'll be removing the whole rental agency thing from it .... and much of it for that matter: You own land on a Sim and want your Group of friends to be able to use your TV and add stations to it. You set it to Share with Group and alter the proper settings to allow them menu access. However there are some members of the Group that you feel might try to take advantage or steal the TV. What can you do? Well, if there was a special tab or some such within the Group Information area (for example) that allowed individual members the ability to set which roles/other members could alter or use a Shared object, you'd just select all of them and then weed out the ones you had doubts about.

Of course this assumes that you are just a Group MEMBER and not a Group OWNER or Officer.

Sorry if I seem at all jaded or aggressive on this: Been screwed by individuals members of a Group before and do not want a repeat (Group Owner and Officers refused to believe it happened too!)

The current state present an actual security risk where any guest member can copy an object while transitioning between "share with group" and deeded status. The flaw in itself require the function to be altered for security reasons in my view.

It is not expected for an object to have to transistion through a less restricted state to get to a more restricted one.

In unix terms this is like forcing someone to chmod 770 minimum before they are allowed to chown a file. It might have made sense some time in the distant past to keep people from accidentally losing control of their objects when they deed them, but now that deeding overrides the sharing permission, it again no longer makes sense.

I'm almost surprised there's no JIRA proposal specifically for it (or containing this possibility in its description); it would fix the awkward behavior here quite simply and tidily indeed. We'd have two levels of object permission (or maybe better than levels, assignable separately), with no messy details, and no loss of old capacity.

(Do I have to vote for this instead? 0.o)

1. The tools themselves show you that the intent and implementation of the design, before the bug, was to have "share with group" as a function (power) of a role. It is a checkoff box. Surely you can concede that if "share with group" was a checkoff box, and worked as designed and implemented, then if that stops working, it's a bug? Why talk about this as a "new feature" when the checkoff box in the interface clearly manifests this as an old feature that pertained, but developed a bug?!

2. I absolutely reject the idea that JIRA governance can be achieved by having "public triage meetings". Then only people with no jobs/lives/families/etc in RL who have all the time in the world to obsessively hang out at Linden office hours would rule. And that's such a tiny sample of the already tiny sample of JIRA users that it simply has no legitimacy. Public triage is useful merely for people to coordinate what they feel like working on; it is in no way useful as some kind of governance committee that makes decisions. A proposal or bug find should be governed on the JIRA itself, asychronously, where people can vote it up or down or keep it open.

3. The proposal is to have the checkoff work as stated. It's not only about "manipulate" or "move" but "share," which is a separate box. This is very important in rentals because of the TV deeding – and TV stealing problem, and the problem of griefing with malicious scripts in shared and deeded objects. Go look at the tools and you will see "share" is separate from "manipulate" and "move".

4. I've laid out this argument over and over again, it is clear enough, and it is such an astounding defiance of logic and science, that I'm sorry, only references to hippies and communists become appropriate in such a situation. Look at Barney's post – perhaps if you hear it from your fellow coder, it will be persuasive to you?

"This definitely is a bug and not a feature request and arguing otherwise defies any form of logic. There is a classic rights hierarchy with the "group set -> group shared -> group deeded" options and after introduction of group roles (to further limit access on a fine grained scale), suddenly the "group shared" tops "group deeded". Which is not only non-intuitive, it's just plain a bug."

You have not answered this concern, Soft.

5. I will not be showing up at public triage meetings, I prefer to get to RL work, sorry.

6. I will not be flash-mobbing people to the JIRA because something that is logic, and broke from a bug, should be able to be grasped especially by Lindens as logical, and broken by a bug. We need to get somewhere on that basic issue, Soft.

7. The UI isn't wrong or counter-intuitive; it was right, worked as planned, and developed a big? Why do you fail to recognize this? That's the problem here. A complete difference of perception despite the obvious fact of the interface in front of you.

It's a relatively simple freebie vendor allowing group members to drop in items they want to make available to everyone.

The group does not allow everyone to edit group-owned objects, for reasons beyond the scope of this discussion. Sharing with group allows any group member to drop an item into the vendor, not just those with authority to edit group-owned objects.

No doubt there are similar cases that rely on this behavior, so implementing this JIRA would break content (other than just my freebie vendor).

There is no objective way to discriminate between bugs and features, because LL didn't document SL sufficiently to be able to do that. Bug vs. Feature is a matter of consensus, and not "right vs. wrong". Personally, I feel that there are good arguments for both sides, but none that are compelling enough to decide the issue outright.

http://wiki.secondlife.com/wiki/Permissions_FAQ

Share with group

This setting is usually used on rezzed objects. When this box is checked, anyone who is a member of the group can use the object as though they were the owner. Limits on this is that you cannot link the object to another.

Also, the Knowledge base includes this text under
Second Life Info > Groups > I want to build something with other people; how do I let them edit my objects?

"Click on the box next to Share with Group." ... "Note: Any other group members will also be able to edit the object."

As a tip - Google's search is much better than our own knowledgebase search. Searching for a term and adding site:support.secondlife.com can be a real time saver.

That Permissions_FAQ shows no distinction between group 'shared' and group 'deeded' objects. So the questions that have to get answered (and possibly behaviors to match) are:

• Are 'shared' and 'deeded' objects the same currently?
• Should they be the same?
• If not the same, does sharing trump permissions when both shared and deeded?
• How do we communicate this to those learning? (Cuz I was confused as hell until I spent an hour with it.)

Whatever the path and resolution. This needs attention because, despite any warnings, any land lord or corporate client wishing to share development using a combination of shared and deeded objects will likely NOT end up with what they are expecting based on role permissions as displayed. Many will be too naive enough to know they are open to griefer attack, or worse, unexpected inconsistencies during development with their own team.

If the specification calls for a function to perform in a way that confuses users, then the specification is wrong.

Defining a bug as "not performing to specification" rather than "not performing to users expectation" is not really a good road to go down. The user expectation is what matters.

My response: Well, almost. Deletion privileges should be explicitly set as opposed to implicitly assumed. This, is but one reason there is a problem in the first place.

Such a change should not include enabling the ability to set objects for sale, however. A group owner shouldn't be able to let a designated class take personal property.

In a nutshell, this would make "share with group" operate exactly as "deed" does, but without changing ownership, without enabling the sale role, and without granting the parcel privileges (ejection, media, etc) only available to deeded objects on deeded parcels. This would also make the share-then-deed UI progression make a hell of a lot more sense.