The objects returned to me are NOT repeat NOT NOT checked off "share with group". They are prefabs that I own that aren't checked off, obviously, nobody does that anymore because "share with group" objects are griefed.

I've now had this happen 3 times on 3 different sims, and it is a bug. Accept that and move on to bugs you can understand and stop trying to undermine someone else's legitimate bug report.

I have the "Second Life has returned" blah blah reports to prove it.

Grow up and stop flaming anybody who comments on your issues.

Futhermore, try to use sense and logic here. It's beside the point WHAT their status is. A person without that role in the group to return group-set prims should not be able to return any prims whatsoever.

Whether or not they are in "share with group" or not is IMMATERIAL to this bug as it is reported. The fact that some share-with-group objects that are not transferable delete when returned is a separate matter from the problem of being able to return them in the first place!

Please stop trolling and stalking my reports and go mind your own business. This is a legitimate bug, it is a known issue from the past, and it is reported accurately. You're merely distracting with an extraneous issue. Stop it. You're the one who needs to grow up and stop pestering any bug I report with extraneous issues just to undermine the report and to show off. It's totally unnecessary, and a dysfunctionality that you should not be inflicting on a system like this.

"Futhermore, try to use sense and logic here. It's beside the point WHAT their status is. A person without that role in the group to return group-set prims should not be able to return any prims whatsoever.

Whether or not they are in "share with group" or not is IMMATERIAL to this bug as it is reported."

It is most certainly not, as stated in SVC-121 any object marked "Share with Group" is returnable by any member of the group regardless of their roles by design, so this is a legitimate point to bring up in relation to this issue.

I would not waste my time trolling and stalking your reports, I would have made the same comment on SVC-121 about this issue regardless of who reported it.

It is not true that "share with group" DEEDED objects are returnable. In fact, most people have a terribly time even taking them back and have to buy them back.

It is immaterial to this bug I am reporting, and is not related to this SEPARATE problem of the ability to return group-set prims when you do not have that right.

This is an old problem, Andrew Linden and other old Lindens know about this, ask any Linden, they will tell you. Seriously, you need to stop harassing other people reporting on the JIRA.

I never said this was not a separate issue, if I truly felt it was related I would have linked it as such. It is just not obvious since you failed to mention it in your description, and therefore relevant.

Seriously, you need to grow up and stop accusing people of things they are not doing, the JIRA is not the place for it.

The copy of the prefab as a whole, linked up, may not be checked off "share with group".

But the group member not enabled for group-set returns may still be able to return it anyway if any component part of it is checked off in "share with group".

If you look at the broken pieces of the prefab, you can see perhaps the maker left a "share with group" on a light or something, and that status then infects the whole build, I guess.

Sigh. Oh, well, I don't care, there are many worse bugs. Obviously I can't go checking every single build to see if any of its prims at all are accidently in share, although I've had to do this before due to griefing.

BTW, deeded versus share-with-group seem to make a difference.

Also, your summary is confusing. Is "share with group" checked for none of the prims, only one, the root or child prim?

There's nothing "confusing" about my summary; it says quite clearly "if share with group is checked on one of the components". Obviously that means if a prim is in "share with group". Whether it is root or child strikes me as immaterial and not necessary to chase down for the purposes of this problem.

Rather than require me to put some object in a freebie box, which would be totally pointless as the group on that freebie area would be different than my group, I would urge you to merely test this yourself with your own group.

I'll test it again myself. I have seen this bug come and go over various versions, it was not fixed, and not even acknowledged.

Torley has a good guide for formatting a repro into easily understood steps: http://wiki.secondlife.com/wiki/User:Torley_Linden/Bug_reporting

I recommend writing a repro in that format and putting it in your description, makes things easier for everybody.

1. Set a group object to "share with group" with the role "officer" in the group which has the right to "deed objects to group" under "object management" which obviously includes the function of "share with group" which is the first step in "deed to group". Return objects from the parcel with this role, which has checked off under "parcel content" "return objects owned by group."

2. Log on an alt who has only "tenant" role in the group, a role for which the box is NOT checked off under "parcel content" for "return objects owned by group" and for which the box is NOT checked off for "deed to group". This role should NOT have those powers as they are NOT checked off in the group menu.

3. The alt, with only the limited role without the powers checked off, is nevertheless able to right-click and return the object from the land, and does NOT get the error message that should occur saying that he doesn't have the rights on this simulator.

4. This should NOT be happening because powers in group roles should matter, and if the power is NOT checked off, the avatar should NOT be able to return an object as indicated in the "parcel content" section.

Obviously, if there is a box to check off or not, the original design in fact conceived of having this power or not. And it did work for a time.

So for it to stop working is a bug, and the failure to acknowledge this baffles me totally.

I could add that the additional factor here is that a prefab house made up of 100 prims might have some prim in it that is put in "share with group" which might not be readily visible, and that can enable the avatar to return the whole thing even without the powers.

I said the item was NOT checked off in share because originally, on a linked object, looking at the object menu, it did not appear to be checked off.

It was only by examining the coalesced returned item, that had split into pieces, that eventually I found one piece that was checked off in "share" with then explained the problem. But it truly is immaterial. As even in a single prim, you can see this bug play out. Or in a linked prim. Immaterial.

I tested it myself again just now.

1. Rezzed two cubes, one with "share with group" and the other "deeded to group
2. Logged on an alt not currently a member of the group and not given permissions for deeding objects or returning objects
3. He was able to return the cube with "share with group" but not the cube with "deeded to group"; he gets an error message that he cannot do that on this simulator with the deeded object, but with the shared object, he can simply return it.

Once again:

1. Root prims have nothing to do with anything. Just try it on a simply plywood cube.
2. This prefab that the creator has put "share" on has an issue of one of its components being shared, but that's beside the point – again try it on a simple cube!
3. Join my group and test this if you don't believe me. It's an open group.
4. This is NOT by design. Read the list of group permissions. The group permissions very defintely have an ability, RETURN OBJECTS SET TO GROUP. This ability is NOT turned on for the role "tenant" in my group Ravenglass Rentals, i.e. to the open membership. It is only turned on for the role "resident". So a role that should NOT have this power has it.
5. Once again, what matters is too things: a) simple cubes put in 'share with group' are returned by group members without that power in their role; complex objects that appear not to be in share, but in fact have a piece in share, also return. Same thing.

Soft says it's "working as designed", but I think the design is wrong. If things aren't behaving as residents expect, then it's a bug.

Members of the group who are not authorized to do so with the existing permissions of the group, as they are implemented in check-off boxes, can access group-set prims and return them, even if not given that role AND they can access "share with group" and return them, AND access group-DEEDED (which you call "group-owned") objects as well. ALL are problems. ALL stem from a bug or flaw that refuses to recognize the RESTRICTIONS available in the control of the object through group roles and their limitations.

Obsessing about the object itself, and whether it is is "set", "share" or "deeded" is irrelevant. The issue is that people unauthorized are able to access group prims even if their role in the group doesn't admit them.

I do hope the Lindens are not only addressing the narrow issue here of the infection of a build with "share". I do hope they are addressing the problem of the roles not restricting as intended, so that roles not intended for access are gaining the access.

I made three prims, red, blue, yellow myself, then logged on alts to test it:

1. Red had no group set at all.
2. Blue had group set and group share.
3. Yellow had group deed.

The member of the group who does not have the power to access group-set objects is able to do so when they are in group-share as well. THAT is the problem.

The member of the group who does not have the power to access group-DEEDED objects cannot access them (that bug is not present in this version and isn't the subject of this JIRA anyway).

So the problem is that shared objects do not respect group role limitations, even though the power is supposed to be limited in a role.

I next tried making linked sets of prims, mixing one share-with-group prim into a set of non-shared, so that the final linked object looks as if it isn't in share.

and THAT is the problem. You can have a house or chair that looks as if it is not in share, but people return it, without having the power to return group-set prims, like officers, because of the infection.

So I'd like to know: is this narrow issue the only one Lindens will deal with?

Or will they address the problem of people without the power to return group-SET objects being able to return them when they are also group-SHARED.

Was:
"Allow group members to move, modify, copy and delete."

You are closing this proposal prejudiciously, because you don't like my opinion, and you are trying to silence me from another thread, the VWR discussion on mass setting of permissions.

So you are trawling around looking for my proposals and trying to shut them down.

This is NOT repeat NOT expected behaviour.

That's because there is A BOX TO CHECK OFF on the group ROLES that says essentially "give this role access for shared/deeded objects or not".

If there wasn't a box giving that option, as was in the original design, as as it originally worked, then you'd have a case. But there is a box, so you don't.

Putting in an error message is not a solution.

Fixing this bug becomes even more critical now that you are fanning the "mass liberation" feature, as groups will then be even more at the mercy of owners' whims, and conversely owners will not be able to protect themselves from theft of deeded objects by first-level membership in open groups that they have not CHECKED OFF THE BOX to grant ACCESS to deeded/shared objects.

Your resolution of this matter flies in the face of the viewer itself, which shows a check-off box. I'll go get a screenshot.

I've just re-tested this again. An alt without the powers to return group-set objects is able to do that to a group-deeded object:

You have received a message from Second Life:
The object 'Test' you deeded to Ravenglass Rentals has been returned to your inventory lost and found folder by Avatar Name from parcel '' at Ravenglass 33, 104.

Go in my group or any group and see for yourself. This is how TVs get destroyed, because some objects not on transfer destroy upon being returned from group land because the server doesn't know which avatar to return the collectivized object, as it is no longer showing individual ownership. That should tell you something - about many things.

Another glaring fact is that Workingonit was assigned to this. If it is "expected behavior" what is he doing on here? um, just fixing an RX-suggested test? Hardly.

Are you saying that you see a case where a deeded object is returnable without a permissive group role, and without the "Share with group" checkmark being set? As I read this issue summary, the situation was that the checkmark was set.

There is a different way this manifests now on the object than it used to. It used to be that the check stayed appearing in the box in the "deeded" phase. At some point that stopped showing – that's related to this bug.

To characterize an object as "no longer in share" because it is now "deeded" strikes me as absolute sophistry. Of course it's in "share" regardless if you see "a check in the box" – you can't deed an object UNLESS it is first put in "share". At no point do you "remove the check" or 'unshare it" when you deed it – you simply press "deed to group" and it becomes a deeded object. A deeded object is a shared object.

The problem is then that without having the power to return group-shared objects checked off in the group roles, a power usually only left to owners/officers, a group member is able to return deeded objects – deeded objects which are obviously set to the group, because they don't return from the land, they are deeded to the group, and their group shows as that group.

To claim that an item is "no longer shared" because it is deeded seems to wilfully disregard that the group affiliation of the object shows as that group that it was deeded to. It indeed has a group setting!

Go and test it inworld. And I fail to see why this is so hard to accept. The group roles foresee a power which is to return or not return group set objects and to manipulate, sell, move deeded objects.

"Members of the group who are not authorized to do so with the existing permissions of the group, as they are implemented in check-off boxes, can access group-set prims and return them, even if not given that role AND they can access "share with group" and return them, AND access group-DEEDED (which you call "group-owned") objects as well. ALL are problems. ALL stem from a bug or flaw that refuses to recognize the RESTRICTIONS available in the control of the object through group roles and their limitations.

Obsessing about the object itself, and whether it is is "set", "share" or "deeded" is irrelevant. The issue is that people unauthorized are able to access group prims even if their role in the group doesn't admit them, whether in the share or deed status.

Here is the repro yet again which I just tested yet again.

1. Rez one prim, check off "set to group" and then click "deed to group" to make a group-deeded object.
2. Rez one prim, check off "share with group" and leave it, i.e. do not deed it, just leave it in "share".
3. Log on an alt that has only basic group membership, and does NOT have access to the group roles for moving, copying, or selling group deeded objects, and does NOT have access to the group role for "return group set prims".
4. The alt without that group roll is able to return from the parcel group-deeded objects.
5. The alt without that group role is able to return group-shared objects.

This is NOT "expected behavior" in either case, as there are existing check-off boxes for group roles that specify the access to objects, as to their returning or their moving, copying, selling if deeded, that should not be accessible unless that member is checked off for those group roles.

http://jira.secondlife.com/browse/SVC-121

Originally in January 2009 the Lindens revisisted this JIRA VWR 5491 and marked it critical.

Not respecting group roles is indeed critical.

If you are able to successfully return the object, listing the time and the region where it happened would be helpful. We can then look at the simulator logs to see why the return was permitted. Be sure however, that you're not doing this with an alt that may have estate manager access.

This is being done on the Mainland where neither I nor the alt have "estate manager access".

Yes indeed the object is returnable by another group member who is not in that permissive role, as I've been saying for more than a year!

When I have time later I will go and record all the messages of return from the server that come with this and screenshots of the avatars' roles.

Blinks

Did you fix the behaviour or did you just put in some "RX Safety Message" about this?!

Because the behaviour is indeed the bug. It does indeed happen, avatars without the access to the role permissions for returning group-set objects are able to return them.

There's no point to having group powers and access levels to permissions within a group if in fact they are overrided, and we're suddenly informed this is "expected behaviour".

Of course it isn't expected behaviour when you someone who is not supposed to be able to return group-set prims can return them!

Why is this so hard to accept?!

We're not smuggling in a fundamental change of the permissions system's design without appropriate vetting just by calling it a bug fix.

That is not a feature request.

It is not a "tool tip" that is needed.

It's a bug.

Your strange persistence on this really boggles my mind. What does it take? Can you schedule a time to come inworld and see this demonstrated yourself? It's been amply documented 4 times now for you.

In fact, what you're doing is smuggling in a tool tip to pretend there isn't a bug in the permission systems. Look at the groups. Do you ever work with groups and group objects, Soft?

The design would simply begin to function as it is supposed to with a bug fix, which is that someone without the power to remove group-set prims would not be able to do so.

Shared returnable object:

1. Create a cube
2. Any perms
3. Check Share with group
4. Any member regardless of group abilities can return cube
5. This is by design and what is clarified in the tooltip in RC2

Deeded non-returnable object:

1. Create a cube
2. Any perms
3. Deed object
4. Leave share with group unchecked
5. Only members with permissive roles can return object

Deeded non-returnable object:

1. Create a cube
2. No mod, copy and transfer perms do not matter
3. Deed object
4. Check share with group
5. Only members with permissive roles can return object

Deeded returnable object:

1. Create a cube
2. Mod, copy and transfer perms do not matter
3. Deed object
4. Check share with group
5. Any member regardless of roles can return cube

A)

1. Join the open group Ravenglass Rentals, use my profile to find and join this OPEN group with no invitation.
2. Note that in the roles, you do not have permission to access these powers in the group:

o return group-owned object
o return group-shared objects
o return non-group objects

If for some reason you can't see the role descriptions listed, look at the screenshot above, no. 2

3. Proceed to return a group-shared object which you are not empowered in the group to return.

4. Note that you cannot return group-deeded objects or non-group objects which you are not empowered to do.

B) Ask for and get checked off the resident status in Ravenglass Rentals which now gives you access to the following powers (see screenshot):

o return non-group prims

This status does NOT give you the power to return group-set prims or group-owned prims. These are two different statuses. Look at the check-off boxes of power in the group.

1. Try to return group-set objects – you cannot, you get error messages
2. Try to return non-group objects – you can, you have permissions
3. Try to return group-owned objects, you can, although you DO NOT have permissions

So there are two bugs, one evident in the power of those without access to return group-set prims, and those with access to that power, to return group-owned prims that they do NOT have access to.

Just look at the menu of group permissions.

Soft, you are apparently not looking at group roles and seeing the issue here. This is not about tool tips.

If anybody "smuggled in any designs," it's, uh, the Lindens that came before you who, in their wisdom, because we discussed during beta, put in two categories of powers, group-set and group-owned, and made two sets of powers to be checked off in the group.

That is belied by the fact that there is a CHECKOFF BOX and if it is NOT checked then that group member SHOULD NOT HAVE the power to return prims.

That should be abundantly obvious.

You've also made another error, claiming that you can "uncheck" share with group after you've deeded something. You can't. First you check "share with group." Then you deed. Deeding locks in the object as deeded until you can sell it back to yourself for $0 or sell it to another. It does not enable changing "share" or not.

By definition, a group deeded object is in fact shareable in the group as well. But it should NOT be returnable by those NOT accessed to return group-owned objects.

But that's not what this bug is about.

This is about the group permissions, and the role that does not allow RETURNS of group-shared objects.

The main issue is that people in roles not expected to be able to perform certain actions can in fact perform them.

There is no such role ability as "return group-shared objects." Look at your own picture.

If group-owned objects are returnable via the non-group permission, that sounds like a bug. The three permissions above sound like they ought to cover three non-intersecting sets of objects.

That should be covered in a new JIRA, though. It has nothing to do with "Share with group."

No, you've done more than that.

Old Summary: Group Members Not Enabled to Do So Can Return Group-Owned Linked Prims if Any Component is in Share With Group

New summary: Group Members Not Enabled to Do in Group Roles Can Return Group-Shared and Group-Owned Objects

You've added a completely different bug. You should make a separate, new issue if there's an overlap as described in the previous comment. Returning group-shared objects is not a bug - it's expected behavior. Adding a new, unrelated issue into the same JIRA makes a mess.

And I did not create a new bug here.

I merely changed the title which referred specifically to "with any linked prims in share with group" to just "share with group" that's all. It's not making a mess but removing a distraction.

You've also made another error, claiming that you can "uncheck" share with group after you've deeded something. You can't. First you check "share with group." Then you deed. Deeding locks in the object as deeded until you can sell it back to yourself for $0 or sell it to another. It does not enable changing "share" or not.

Attached screenshots of shared and unshared deeded objects.

3. Proceed to return a group-shared object which you are not empowered in the group to return.

This is nothing more than SVC-121 and the feature request to have this changed is SVC-585

Summary: "Return non-group objects" role permission enables returning group-owned objects

There are three role permissions, covering three distinct sets of objects:
1. Return objects owned by group
2. Return objects set to group
3. Return non-group objects

Enabling the 3rd permission also allows a resi to return group-owned objects. This should only be possible if the 1st permission is enabled.

Whether group-shared and deeded, or whether group-deeded and NOT shared, roles without those accesses in the group can still return objects. I just repro'd it again.

Your summary here is STILL WRONG and you are still NOT GETTING IT Soft.

What does it take?

I am reopening it, because I have yet again got a witness inworld to see this:

Group members without the role to return group-shared and group-deeded prims are able to return them – a bug.

This bug affects two types of permissions:

o group-shared
o group-deeded

It enables theft and destruction of private property and group property both. That's wrong, when there are tools that have options to prevent that, and always were.

It means hundreds of real dollars lost in TVs and prefabs especially as they are deeded, or put in share sometimes to be able to texture or move them.

So I want to get clarity on this and I need you to look at the facts and see this is not about tool tips or expected behavior.

The new JIRA you're suggesting is COMPLETELY IRRELEVANT to the BUGS here. It's something from a different issue COMPLETELY.

Your group-shared issues has already been covered in SVC-121, I understand you do not agree that SVC-121 is by design, but the designer insists that it is so a separate JIRA should be opened for the one bug.

Please note the following:

1. You are right that it is possible to UNSHARE a deeded object. Few would get to that point. You must FIRST SHARE IT in order to DEED IT. Then you'd have to GO BACK and UNSHARE it, which would still keep it deeded. YOU ARE RIGHT that is the case. But please keep listening.

2. You are right that it is possible to PUT IN SHARE a deeded object, making it a different status object.

3. But what you are not hearing is that PEOPLE NOT GRANTED THE ABILITY IN THE GROUP TO RETURN GROUP SHARED OR GROUP OWNED OBJECTS ARE ABLE TO DO SO.

In fact they are NOW. This bug does come and go. What was true in March 2008, i.e. that these items weren't being returned by those without powers is NO LONGER true. Now they CAN be returned. I just tested this again with witnesses.

Then you'd have to GO BACK and UNSHARE it

It has not been this way for a long time, it is unshared automatically when deeded.

But what you are not hearing is that PEOPLE NOT GRANTED THE ABILITY IN THE GROUP TO RETURN GROUP SHARED OR GROUP OWNED OBJECTS ARE ABLE TO DO SO.

I do hear you and I agree that group-owned objects should not be returnable with non-group object return permission, is there any other way this can be done?

This is how the software is intended to run, prokofy is refusing to acknowledge this. Not a bug. If you dont share it, it can't be modified by anybody who isn't in the proper role to do so. If you share it, you share it with the whole group.

The real problem is that in the object management ability area, the "manipulated group objects" gives people this ability to return. Always has. What I recommend is that this JIRA be modified to recommend splitting this ability into two abilities, one is to manipulate group objects, another is to return them to their original owner.

Being in group with no permissions I can: return shared objects.

Being in group with ONLY the permision to return NON GROUP OBJECTS I can return objects that are DEEDED but NOT SHARED with group!

This is a nasty bug for land lords.

a) sharing or deeding does NOT enable returning because there is a design in the group tools, with a checkoff box, that enables the owner of the group to DECIDE if he wants that role for residents to include that ability to return or not
b) if what you were saying were true, there would be no checkoff boxes that give or do not give this power
c) furthermore, deeding an object and unchecking the "sharing" (something not everyone realizes you can do) STILL has problems as people CAN return it even without that power to return

Go and read PARCEL CONTENT role abilities, study their powers, repro the bug in your groups with varying powers and you will see it.

Everyone knows that share with group means you can move the object if you are in the group. We get all that.

But it should NOT enable returns *if you are not checked off for that power on the parcel content folder of the group abilities". Full stop. It was designed that way. It functioned that way. It stopped functioning that way.

It is a bug.

• Return objects owned by group
• Return objects set to group
• Return non-group objects
• Landscaping using Linden plants

I temporarily joined Prok's group and none of the above are set (checked).

Prok set out several prims, set as follows:

1 prim => is set to group, no group share, no group deed
1 prim => is set to group, group share, no group deed
1 prim => is set to group, group deed

I can return a group shared and group deeded object, even though those capabilities are not set for my membership level.

This is a VERY SERIOUS BUG. And all land owners who rely upon group settings to manage their land are vulnerable to this bug, in that anyone who belongs to their group, can return their group shared or deeded items. The result? Tremendous loss of time in that they would then have to rebuild.

And, this is not just about griefing. How many times have you been editing and accidentally deleted the wrong item. Well, in this case, a group deeded or group shared item would be returned to owner.

Very bad. Very very bad.

Please fix this. Thanks!

The only solution would be to physically delete the checkoff box granting the powers as options in PARCEL CONTENT under group ROLES.

The presence of this checkoff box with its granulated perms lets us know this is a design, not to enable people to return items unless empowered to do so. It used to work, after the bug was noted, and fixed in beta testing of group tools in 2005.

The group permissions bug returned in 2007-2008, is not a feature, and is not expected.

So change your design if you must so as not to mislead people into thinking they can provide granulated powers when they really can't, due to a bug, but don't keep banging me over the head claiming "the software is functioning as expected" unless you expect me to remain wilfully blind to a checkoff box that has granulated powers.

Here are my viewer details, although viewer should have nothing to do with this since permissions should be server-side:

Second Life 1.23.1 (119104) May 4 2009 17:53:10 (Second Life Release Candidate)
Release Notes

Built with MSVC version 1400

You are at 261159.1, 256479.8, 759.3 in Scafell located at sim3013.agni.lindenlab.com (216.82.20.2:13002)
Second Life Server 1.26.3.118673
Release Notes

CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3158 MHz)
Memory: 3071 MB

You can't put a tool tip or notion saying "share with group doesn't respect role limitations" when you have a role limitation "return share with group" or "don't return share with group"

Unless of course you are planning on taking that box, with those powers, and those options, under PARCEL CONTENT and lobbotomizing them out of the group tools to pretend there is no bug.

My personal advocacy of rugged individualism and inalienable personal property rights come into play here? You assume far too much. Keep this about the issue. Not the individuals involved.

It's sounding like the problem is indeed https://jira.secondlife.com/browse/VWR-5491#action_111461 - if that's not the issue here, please say specifically how. I'll go on to create that and put this JIRA to rest otherwise. This is turning into a huge waste of everybody's time.

No, that was eliminated long ago. "Manipulate" is not checked off, and yet people not authorized to return shared objects are able to share them. In a separate function, if manipulate is checked off, they can return deeded objects even though they are not authorized to return group owned objects.

>My personal advocacy of rugged individualism and inalienable personal property rights come into play here? You assume far too much. Keep this about the issue. Not the individuals involved.

If that's so, open up any group you are in, go to group> roles and examine the group abilities, look at the folder PARCEL CONTENT, look at the four kinds of abilities there, represented as check-off boxes:

PARCEL CONTENT

[ ] Return objects owned by group
[ ] Return objects set by group
[ ] Return non-group objects
[ ] Landscaping using Linden plants

And now answer this question:

If returning objects is not an optional power that the owner grants or does not grant, why are their checkoff boxes, Soft?

Once again, is what you're saying different than https://jira.secondlife.com/browse/VWR-5491#action_111461 ? This would cover Angela's second case. The first case of returning a group-shared object is expected.

If this is not what you are describing, try a set of repro steps. Just say what happened, what you expected to happen, and what happened instead. Don't include group-share commentary, don't create a series of objects and interleave commentary. Keep it clear.

Abilities in the group are optional - - you check them on or off.

One of the abilities is "return objects from parcels".

Under Parcel Content, the abilities are divided into:

[ ] return objects owned by group
[ ] Return non-group objects

Those are options. If they are not checked, i.e. you are not granted those abilities, you should not be able to return objects. Yet you can.

It's been documented here several times.

1. Join a group that is open.
2. Note your role does not have the ability to return shared objects.
2. Return a shared object.

This is not expected behaviour.

An object that is shared is an object that is set to the group.

In order to be shared with a group, obviously, an object has to be set to that group first.

Then shared.

All shared objects have the status of a set object.

Therefore, being able to return objects set to the group when you are not granted that power is NOT an expected behaviour.

You are saying that the status "share with group" should override the rules for "set to group". Why? Set to group is set to group. The rules say you cannot return group-set prims unless you are checked off with that power to do so. Why do you think "share" overrides the intentions of the group owner for abilities?

Could you describe the use cases where you'd need to return an object set to the group AND the group owner had not authorized your role to be able to return group-set objects?

If the owner wanted you to be able to do that, he'd check you off to be able to return group-set objects.

You do realize that returning group-set items often destroys builds by delinking them. Things often get lost on the servers when returned from parcels and you never get them back. Deeded items on np-transfer, when returned with this bug against the original designer's rules, are destroyed permanently. So this is a destructive bug, the tools are not functioned as they should be under their original design, and "share with group" is being over-privileged as some kind of exception.

"Share with group" was intended to assist group builds, enable people to change textures on prefabs, move objects around. It was not intended to assist in returning them from parcels completely, risking their loss, by people not authorized in the group with the role of making decisions about what to return from parcels.

And your objection to SVC-585 is that you want the same policy used only for returning objects. You still want "Share with group" to permit edit, move, copy, etc under the current rules. It's only the return policy you would want changed per SVC-585.

This isn't a judgment or an evaluation of that request. I'm trying to get clarity on this.

It's that *the group tool permissions work that way by design".

They allow choice.

I can "want" or "not want" to give someone permission to return things. It's a granular permission.

Once they have permission to return group-set prims, they can, when they wish, when they are shared – or even not shared!

Ditto group-owned prims (group-deeded prims).

Why you would construe these obvious design features with very clean intent and granular permissions as something easily overriden by the "share" action is beyond me.

Please answer this question: Could you describe the use cases where you'd need to return an object set to the group AND the group owner had not authorized your role to be able to return group-set objects?

And your objection to SVC-585 is that you want the same policy used only for returning objects. You still want "Share with group" to permit edit, move, copy, etc under the current rules. It's only the return policy you would want changed per SVC-585."

"Share" means "Share". Share means "edit, move". It has never meant "return".

No, individual residents should not be able to override the owners' rule for non-returns from his land he owns and pays tier on on objects that either he decides to share and return, or objects that are already in share and he accesses them and then decides to return them.

This isn't some sort of "tyranny" of the group owner, because you can make a group owner or owners or officers all of whom have the power to return group-set prims, then they are free to do so.

The purpose of this feature, already in the group tools, is to prevent loss or destruction or theft of property.

Please outline the use case where you feel that a group member should be able to override the owners' wishes regarding the safeguarding of shared property such as to be able to return anyone's prims in the group on a whim.

Shared objects are not only one resident's own object set to the group he decided to share; they are shared objects from anybody in the group. And allowing any one person in the group to override the group owners' wishes regarding group-set object returns defeats the rules set up for group-set objects. A shared object is first and foremost a group-set object. A shared object is meant for sharing, not returning/loss/destruction.

The use case for allowing object returns with "Share with group" is the same use case for editing and modifying. It allows an unprivileged group member to collaborate with another unprivileged group member. Removing extra prims is part of building.

Thinking about this, I can't see wisdom in separating return ability from edit or movement ability. If we removed the ability to return group-sahred objects, the objects could still be returned by moving them above 4096m, moving them below ground, deleting them, setting them temporary, or adding an llDie() script to the prim if it's modifiable. All the change would do would do is remove the pie menu option without removing the ability to accomplish the same thing by many other means.

On his own land in his own group, he can do what he likes. On someone else's land or business, he will face limitations. That's not being "underprivileged" like the poor, that is simply facing restrictoins due to good management. If you want someone to be able to remove stray prims in your group, you can easily privilege them by checking off the box that says "return group-set prims". That's all. There's no reason to put the burden of that on having "share" override all the rules.

Second Life is made up of many people who share their owned land with strangers – in commerce, rentals, non-profits, educational contexts that are not based on close-knit groups of people. This is a form of collaboration that may not be the "magic" of open source described on your profile, but it is magical in its own right because it pays the bills. People with group land and group businesses wish for the tools to work as designed in 2005, and not defeat the purpose of business management.

Your use case hinges on a notion of Second Life as merely a sandbox, or a place where people do collaborative builds where their collective collaboration on the build is the only concern, and property issues are less of a concern or no concern at all.

But the bug is reported due to its adverse effect on another very widespread use case of Second Life which is for group rentals, group businesses such as malls or clubs, etc. In those cases, you do not want an "unprivileged" group member "collaborating" with another "unprivileged" group member to return management prims or another tenants' prims. That causes destruction and loss of property. The putative good of enabling group builds is definitely outweighed by the hundreds of real dollars lost due to property destruction.

There is a very different dynamic between a close-knit group of friends working on a collaborative build and people who rent or shop or find entertainment on group land. The former have chosen who they associate with in a group and don't worry about things like deliberate or accidental return of prims and their destruction ,and think of "share" as a "builder's convenience". The latter need to have good management of people to ensure that one person doesn't destroy another person's property.

This bug is reported – and it is a bug – because it departs from the definite re-design of the group tools in 2005 which took them away from their exclusively collectivized format, where there was little limitations on group members, and griefing and theft of land and objects were rampant . The changes in 2005 made group tools fit for business and other collaboration that doesn't require an outlook such as one would have in a beta test in a sandbook with likeminded pioneers.

This bug is reported because it destroys property. TVs are constantly being returned, accidently or on purpose, and if they are on "no-transfer" they are destroyed. Prefabs and entire builds and infrastructures are constantly being returned, accidently or on purpose, because one prim in "share" means the entire thing because vulnerable to such returns, causing lots of destruction between the build can delink when returned, and be impossible to fix if it wasn't copyable.

People who need to build and return other people's "extra prims" who feel they are underprivileged do not need to be in group rentals. They need to be in public sandboxes or at friends' sims who let the underprivileged build. Or they can go on Wikitecture's Island. Group builders are a tiny percentage of SL residents' use. The bug that enables this tiny percentage to flourish cannot be privileged and allowed to defeat rules established in groups for awarding or not awarding the right to return prims.

This is thinking like a scripter or even a griefer, and it is not the use case of returns that happens in the overwhelming majority of use cases in SL which have to do with rentals, businesses, clubs, etc.

The majority of people in SL do not script or know what ' llDie() script" is or how to get it to act; they don't even know how to put things up in the air at 4096; they also tend not to realize they can even push things in the ground. This is sandbox culture, not the culture of the overwhelming majority of settlers in SL now.

In those cases, people do not know enough to cook up something like adding llDie() script , nor do they think to move things below the ground, as most people tend to accept the ground metaphor. The majority of cases of return are accidental, or deliberate in the sense that the person who maliciously returns an object doesn't have the abilities to think up things like putting it above 4096 or llDie() script , but merely has the will to right-click and select "return" when he sees it is possible because of the bug in the tool's design.

@prokofy - "Tyranny" would be a silly term to use when the group is opt in in the first place. Tyranny necessitates force. And building happens in creating residents' homes and businesses, not just in sandboxes. I don't see anything that deals with the fact that restricting pie menu return ability still leaves five other methods of object return and destruction available for editable and movable objects. This makes it hard to understand why a change would help here. It seems like it would only partially obfuscate the available options, creating a false impression of "Share with group"'s abilities.

That being said, while I designed the test to check all potential paths, since the lowest common denominator failed, all others will fail as well. The lowest common denominator, in this case is a group member with absolutely no permissions whatsoever, outside of just being "in the group." The results for this case is as follows:

Viewers tried:
Second Life 1.22.11 (113941) Mar 6 2009 12:50:02 (Second Life Release)
Second Life 1.23.1 (119104) May 4 2009 17:53:10 (Second Life Release Candidate)

ROLE: everyone
ABILITIES: none

NOT SET TO GROUP
Pie Menu: delete & return options inactive (i.e.,grayed out)
Also tried: delete key
RESULT: did not return/delete
Messages: None

SET TO GROUP
Pie Menu: delete & return options inactive (i.e., grayed out)
Also tried: delete key
RESULT: did not return/delete
Messages: None

SHARED, DELETE,
Pie Menu: delete & return options active
Also tried: delete key
Popup: with following message
At least one object is not copyable.
You do not own at least one object.

Are you sure you want to delete this item?
Selected: OK
RESULT: item returned/deleted
Message: None

SET TO GROUP
Pie Menu: delete & return options inactive (i.e., grayed out)
Also tried: delete key
RESULT: did not return/delete
Message: DEEDED, DELETE, Removal of the object 'DEEDED TO GROUP' from the simulator is disallowed by the permissions system.

As you can see from the above, the return has not a thing to do with the manipulate object ability under the object managment section for member roles.

For those who wish to recreate it, please contact me inworld, and I will give you the Group Object Test build, that comes with instructions, so that you may test it out for yourself.

Unless someone can prove otherwise, as far as I can see, this is still a bug.

Again, this has not a thing to do with any role abilities, as none whatsoever were activated for this generic group member.

Take an unshared, deeded object. A member with no abilities cannot return/delete the object. Now give the same member Object Management->Manipulate group-owned objects ability. They can now return/delete the object. This is what SVC-4259 is about.

The share with group is a problem, as it stands today. For a number of reasons. One being, obvious, the definitive meaning, as you so note. So... let's consider some proposed use cases...

Case one:

I am managing group land which contains a variety of builds. I wish to rent space to various individuals. Therefore, I have created a group for my renters. In this case, outside of the ability to rez objects, I am not giving my renters access to my builds (i.e., share with group). Therefore, they cannot modify or otherwise change these builds. This one is simple, of course, as my objects can simply remain unset (or, if I am using parcel return, set to group).

Case two:

Similar case one, however, I do have group members who are part of my team. Therefore, I want them to have modification access to my builds. In this scenario, I would set the object to group, and assign those members to a role that includes modify group objects, under object management. I would also need to deed the object to group for this case to properly work.

Nota bene: In this scenario, an individual who has mod access to group deeded objects can return those objects as well.

Case three:

Similar to case one, however, I do have group members who are acting as rental managers as well. These members must have the ability to return group set objects in my absence. In this scenario, I assign those members to a role that includes "Return objects set to group" under the parcel powers. These members would not be able to mod the renter's objects. However they would be able to return them if the renter say, defaulted on rent payments.

Case four:

Similar to case one, however, I do have group members who are acting as say, parcel administrators as well. These members must have the ability to return group deeded objects in my absence. In this scenario, I assign those members to a role that includes "Return objects owned by group" under the parcel powers. These members would not be able to mod the group owned objects. However they would be able to return them if say, the group needed more prim space for a group build.

Case five:

I hired joe content creator to help me with my build. However, I do not want to deed the build to the group. In order to address this case, I decide to set the build to "share with group" and invite him to the respective group. This way, he can modify the objects as necessary. However, by doing this, not only can he modify the shared objects, so can everyone else who is in the group. This leaves me, with a conundrum. How can I resolve this? One possibility is to create a sister "construction" group. However, I have already used up all of my available group slots.

One potential solution to this is to remove the "delete" capability from the share with group pathway. Think of this in terms of the OS read, write, execute, delete access to a file. In this proposed scenario, the "delete" capability would only be available to those members whose roles include "return objects set to group."

And this scenario would nicely provide the needed granularity for managing group objects.

You're not responding to the obvious point that for the lion's share of people in SL, putting a script in an object, and giving it a command to make an object die, is not possible because they will never know about it nor seek knowledge about that. That's not "obfuscation". That's just not everyone and his brother being a scripter. Most people aren't. The same can be said for the notion of moving an object to 4096, which requires arcane knowledge of server abilities what 98 percent of the people of SL do not know.

You're not responding to the other very real property issues: destruction and loss of property in real-life cash businesses.

You're expecting people who do not every look at the knowledge base or look at tool tips to somehow access and use this information. That is not the usage of SL. They don't. They click and chose "return" accidently or on purpose because they can. And there is no reason for them to be able to when the group owner has used a check-off box for group powers not to grant them the right to return group-set prims.

The original coders of the group tools put in granulated rights such as "return group-set prims" or "don't return group-set prims" after enormous amounts of input from inworld businesses. And that is how it is supposed to work.

People building in rentals are building on their own property as a rule and have no burning need to "share" and join building collectives. This is an obscure use of SL. There should be choice to opt-in to such an obscure use, and there is: the group owner can specify that a resident has the right to return group-set prims. For the majority of uses, the tools should work as indicated without this bug, so as to prevent forcible opt-in to a collectivized experience against someone's will, that destroys private property. That's all.

You want people to deed TVs, but not return their own or others' TVs because if they do, and the TV is on no-transfer, it will destroy. You also don't want them stealing TVs.

You want people to use management's houses, but not return management prims. If a house is in "share" to enable texture change, it shouldn't also be returnable/destroyable/delinkable.

And so on. All of these group tools were put in to remove SL from the era of the collective, when everyone was just in sandbox groups and bring it into the era of business, where management could make decisions about restricting roles so as to maintain the integrity of private property and yet open it up to public use. It is the most basic form of collaboration in SL – and the most widespread.

Renters in groups do not need to be able to return any management prims or other renters' prims. That isn't making them "underprivileged"; it's just using common sense to prevent destruction of property, that's all. And an individual renter can build on his own land and set prims to that group. The lion's share of renters want their own house, and don't want to be forced into a "wikitecture" group build.

Those that want that experience have choice within the group tools to grant all members the right to return group-set prims without having to strip away the choices for those in rentals, forcing them to endure the destructiveness of "share" for the sake of a few collective builders.

So I won't be taking part in this discussion, forcibly silenced from disagreeing, just the way "share" forcibly makes us collectivize and destroy property despite the rules of civilization that earlier Lindens did in fact put in the group tools to give people more free choices for commerce.

My response: Expected behavior on the part of your designers does not equate to correct behavior. Especially when the very code contains provisions for granularity that, by your claim, is really non-existent. Furthermore, an accidental or purposeful delete could cause countless problems in the form of time and money for property managers who believed leaving the "return objects set to group" deselected for their default group members would actually protect their objects when it does no such thing. Otherwise put, at the very least, this is a gross design flaw. Which, in my three decades of enterprise engineering experience, equates to a bug. That you seem unable to understand this admittedly mystifies me..

Obviously, I am of the very strong opinion this issue should remain open.

For something that's a change to existing behavior, and where there's significant contention about how it should work, it needs to be classified as a new feature. New features are examined and designed with the participation of senior Lindens and the resident experience team. These can't be evaluated and implemented by single Lindens operating on their own, as bug issues are.

The corpus of comments here would also be a liability - there's not a clear, well-written call to action here. A new issue asking for exactly the behavior you want, and filed as a new feature in the server (not viewer) category would be the surest way to proceed. There would be no harm in citing this issue and similar other issues if you want to highlight the fact that the current design does cause confusion.

The permissions described and the process undergone within the posted text file?

The permissions only affect objects actually owned by the group, the only exception to this is an object with a group set to it that is not deeded and is not being shared. Even when I joined in late 2006, "Share with group" has always given the entire group the same permissions as the object owner!

Any attempts at reproducing this 'bug' are doomed to be flawed by this fact and by the fact that the current permission system is set up in such a way that the only way to allow the user who set the object out in the first place to return or take back his/her object is to have it behave in this manner! The object owner should not have to have special power granted to him/her after the object is shared, in order to take their object back!

This is how the system works and how it has to work until such a time as the Lindens code in a more complex permission system that actually allows an undeeded object that is set to "Share with group" to be taken back or otherwise returned by the object owner.

https://jira.secondlife.com/browse/SVC-4259

a) objects set to group and SHARED can be returned by any group member, simply setting them to group won't do it. This is useful for multi-person building projects, particularly where you dont want to trust every other builder with mod rights over all your content in SL. The down side is that this allows a tenant on one parcel to return objects belonging to other tenants on other parcels owned by the same group if the objects are set to share with group (necessary, for instance, to operate scripts in the objects like tvs and security orbs). There are two conflicting needs here so I've proposed a solution in my jira on this.
b) anybody with a 'manipulate group objects' ability in their role can return group deeded objects and shared objects, even though this is not described in the ability description.

Solution:
1) leave the shared with group feature alone. this will preserve the ability of group building.
2) divided the 'manipulate group objects' ability into three abilities:
a) to operate/reset scripts in group deeded objects
b) to modify prim parameters and content of group deeded objects if perms are set to allow
c) to return and/or delete group deeded objects

Thus, landlords and tenants can use ability 2(a) to allow tenants to operate group deeded scripted objects while preventing one tenant from returning another tenants things (tenants should not share their stuff with the group unless it is deeded).

Furthermore, there is a third bug in returning group deeded objects in that they are frequently lost by the inventory system and are not returned to the person who deeded them.

I've always found the group tools, and group share / deeding, very confusing, and never really understood the controversy about this bug, but I think maybe I'm starting to get it. Two questions occur to me:

First, is there any reason that you have to set "Share with group" before you can do "Deed to group"? They seem to do two entirely different things: "share" means "I want to still be the owner, but I want to give every member of the group total power over it for some reason"; whereas "deed" means "I want the group to become the owner, with the powers of individual group members determined by the group's rules".

It doesn't seem sensible, and only increases the confusingness, to require Share before you can Deed; is there a JIRA on fixing that? It wouldn't break any content. And if the Share checkbox goes grey, but is still manipulable, after one Deeds, that's a UI bug at the very least (controls that work should not be grey).

Second, is it the case that the heart of the disagreement in the JIRA is what should happen if both Share and Deed are done? Whether the "every individual member can do anything" of Share should override the "group owns it, and group rules apply" of Deed?

In all the cases that cause people trouble, is it the case that someone has turned Share on more or less by accident, and if Share was off and the object was just Deeded, without being Shared, it would behave as desired? Or is there a case where for some reason you want to have Share on, but still want to have the group rules apply?

Seems like the best solution to this, that wouldn't break any content, would be to break the confusing link between Share and Deed, allow non-Shared objects to be Deeded, and maybe put the Share and Deed controls further apart.

Then people would have less reason to check Share by accident, and the explanation of them would be pretty simple: "Share with Group means you trust every individual member of the group implicitly, whereas Deed means that you give the thing to the group and the group rules will apply; it's unlikely that you want to set them both, unless you really know what you're doing."

Or have I missed an important point somewhere?

(I think it'd also be sensible to be able to mark a parcel as "anything set to group can control the media settings", so that people wouldn't have to deed their TVs and so on in the first place. I wonder if there's a JIRA on that. It would open up a certain class of annoyance attacks, but since all those attacks would do would change your radio station or TV program, might not be a huuuge deal.)

Getting rid of the requirement to share before deeding has come up in comments before, but I'm searching and I can't find where anyone has created a JIRA for the proposal. If you wanted to write that up, it probably would reduce a whole lot of confusion.

(And oh yeah, I always forget about that "IP address stealing" worry. I'm still not entirely convinced it's violating any reasonable user expectation, but I don't have a strong opinion, and will leave that discussion to others.)

Now, back to this issue at hand. I've spent some time doing a bit of research with regard to the history of the group features, and I still hold that this is a bug. Why? Because it was recognized as a bug and corrected several years ago. Unfortunately, there is apparently no historical bug tracking record to support this, and the developers who were involved in that bit are largely missing (i.e., no longer work for the lab). So, all that I have are recollections from people who were there. Hence, my opinion is largely based upon discussions with various individuals who have been around long enough to recall the nightmare around group feature implementation.

That being said, while a temporary work-around to manage this problem can be done with real documentation and tool tip warnings, those are only stop gaps to the underlying issue. And though, numerous ideas have been raised, I am thinking a productive approach would be to create a requirements matrix that highlights object permissions as they pertain to both group and edit panel settings, as well as containing definitive information regarding expected behavior. The requirements matrix should also reflect the use cases that are addressed with each setup.

This would give people a frame of reference for further discussion, being on the same page, and even potentially proving beyond question that it is indeed a bug (or, for that matter, refuting said contention). The goal here, would be to winnow out specifics, including bug areas to target, potential GUI changes, and documentation areas to clarify. The result would provide useful knowledge base documentation for end users as well.

My comment: Okay, fine. Reopened.

I do however respectfully disagree with your contention that this is related to SVC-4259, Afaics, this is not the same as SVC-4259 as that is specific to modify abilities and return deeded object abilities. SVC-585, otoh, seems to be more on target to this issue. And I'm sure that, if any of us have time to scour this pJira, we can find other threads that are hauntingly similar. Which is yet another reason why I am of the contention that pJira is largely useless. Simply due to the organization, or lack thereof. No matter, I remain of the opinion that we need a requirements matrix to ensure all potential use cases and resulting ramifications are covered. Outside of doing that, at the very least, this and other issues will repeatedly raise their ugly heads.

Prokofy Neva added a comment - 15/May/09 11:18 AM
Please confirm with any group with permissions set that you can see, if you refuse to do it with my group, that group members without the power to return GROUP-SHARED objects CAN return them.
This bug affects two types of permissions:

o group-shared
o group-deeded

group-shared part is SVC-121
group-deeded part is SVC-4259

My response: Not quite. It is a matter of simply setting the object for sale and checking give original object. And yes, it should take some effort to delete an object once it has been deeded to group. After all, at that point, it no longer belongs to the original owner.

Furthermore this issue explicitly revolves around the access control list (ACL) model, which in all other systems include the following rights => read, write, execute, delete. The reason the ACL model has been so long standing is to avoid inadvertent deletion of critical data.

In this case, objects are the critical data, and should only be deletable by a) the owner and b) ACL members whose privileges include "delete." Unfortunately, people who think modify should automatically include the ability to delete are sorely misinformed wrt the long standing history behind the original purpose of ACLs.

Whether you or anyone else agrees, coders should, at the very least, understand this simple concept, as well as recognize why this is a classifiable bug.

Prokofy Neva added a comment - 15/May/09 09:51 AM

A)

1. Join the open group Ravenglass Rentals, use my profile to find and join this OPEN group with no invitation.
2. Note that in the roles, you do not have permission to access these powers in the group:

o return group-owned object
o return group-shared objects
o return non-group objects

If for some reason you can't see the role descriptions listed, look at the screenshot above, no. 2

3. Proceed to return a group-shared object which you are not empowered in the group to return. This is SVC-121

4. Note that you cannot return group-deeded objects or non-group objects which you are not empowered to do.

B) Ask for and get checked off the resident status in Ravenglass Rentals which now gives you access to the following powers (see screenshot):

o return non-group prims This is wrong it is actually manipulate objects that gives you this ability

This status does NOT give you the power to return group-set prims or group-owned prims. These are two different statuses. Look at the check-off boxes of power in the group.

1. Try to return group-set objects - you cannot, you get error messages
2. Try to return non-group objects - you can, you have permissions
3. Try to return group-owned objects, you can, although you DO NOT have permissions This is SVC-4259

So there are two bugs, one evident in the power of those without access to return group-set prims, and those with access to that power, to return group-owned prims that they do NOT have access to.

Just look at the menu of group permissions.

And on SVC-4259 Intlibber says this:

IntLibber Brautigan added a comment - 15/May/09 01:00 PM
5491 does not properly troubleshoot the source of the problem, but this one does.

Also if this issue only relates to members with no abilities, then how are unshared group-owned objects returned?

It has been proven that a member not empowered to do so cannot return Group Deeded objects - it has also been proven that the only bug in that is giving them the ability to return non-group objects.

Now then ...

"Share with Group" is operating within the confines of the system. Kindly go back and read the entire comment you quoted .... and if it is not clear that I was referencing "Share with Group" ... ask for further clarification.

I will tell you this however: "Share with Group" does not change the object owner to the Group.

Here's my attempt to summarize the various bugs and issues (from a recent Second Thoughts comment thread):

It looks to me like there is one pretty definite bug here: that a linked object with one child prim set to share-with-group acts as though the whole object is share-with-group even though if you look at the object in edit the box doesn't appear checked. (Haven't confirmed this myself, but sounds like it from the JIRA.)

And another bug, just mentioned in passing in this JIRA entry, where group-deeded objects entirely cease to exist when they are returned in certain situations (without a warning to the person taking the action that will cause that?); that seems bad, and it should have its own separate JIRA entry.

And another possible bug, if people can return objects that are group-deeded, but not group-shared, even though they don't have any group role that should permit that.

And a UI bug, if the "Share with group" checkbox is greyed once an object is group-deeded, even though in fact at least some people for whom it is greyed can still check/uncheck it.

And a design flaw (imho anyway) that you have to share with group before you can deed to group, even though the two things are really completely different (I've opened SVC-4276 to suggest untangling those).

And a difference of opinion about what should happen if an object is both group-deeded and group-shared, where the current design (as pretty clearly stated by Soft) is that group-share takes precedence in that case and anyone in the group can do anything to it. To get the design changed one would have to change the Lab's mind by calm and careful argument.

Is that a pretty complete untangling of the bugs at issue? It would probably be helpful if there was a separate JIRA for each possible bug, rather than a single one that talks about them all; they could of course be linked together as related. But having them all talked about in the same JIRA makes it less likely, I think, that any of them will get properly focused on.

(I'd be glad to help out anyone attempting to pin down repros for any of the above that don't have them yet.)

And another bug, just mentioned in passing in this JIRA entry, where group-deeded objects entirely cease to exist when they are returned in certain situations (without a warning to the person taking the action that will cause that?); that seems bad, and it should have its own separate JIRA entry.

This happens when they are no transfer and is mentioned in SVC-111

And another possible bug, if people can return objects that are group-deeded, but not group-shared, even though they don't have any group role that should permit that.

SVC-4259

And a UI bug, if the "Share with group" checkbox is greyed once an object is group-deeded, even though in fact at least some people for whom it is greyed can still check/uncheck it.

VWR-443

And a difference of opinion about what should happen if an object is both group-deeded and group-shared, where the current design (as pretty clearly stated by Soft) is that group-share takes precedence in that case and anyone in the group can do anything to it. To get the design changed one would have to change the Lab's mind by calm and careful argument.

SVC-121 it does not have to be group-deeded and group-shared to be returnable group-shared alone is enough

Before continuing on however I first hold that a non-root prim group settings should never, ever, trump the root prim group settings. At the very least, this is a glaring bug that needs to be immediately addressed.

That being said, let's review object group properties and some extant use cases.

a) set to group => Original owner retains ownership of object. Members can neither move, modify, copy, delete, or return objects.

Use case(s) addressed:

1. Provides a group hook for group based scripted control.

2. Objects remain on group set/owned land that is using auto-return.

Issues: None

b) shared with group => Original owner retains ownership of object. All group members can move, modify, copy, or delete objects.

Use case(s) addressed:

1. Tenants can move and/or modify a dwelling to meet their desired tastes. An example might be to turn a structure so that the renter can see the sunset from their bedroom window. Or, in the case of a merchant, change the layout of a store.

2. Tenants may wish to use their own build, and would therefore want to delete an existing build.

3. Group members may want help with their build while retaining object ownership.

Issues: Group members may delete and/or copy objects

c) deeded to group => Transfers object ownership to the group. Requires group control for object returns and/or modification. Members who have object modification abilities can move, modify, copy, or delete the object. Members who have object return abilities only can return the object.

Use case(s) addressed:

1. The group wishes to delegate object management to specific members thereby sharing duties between multiple people, so they deed the object to group and assign those members to a role that includes modify and/or return.

2. Selected group members need to be able work together on a build, , so they deed the object to group and assign those members to a role that includes modify.

3. Deeding the object to the group allows linking of objects whose parts are created by different members, so they deed the object to group and assign those members to a role that includes modify.

Issues: See SVC-4259

With the above in mind, this issue boils down to expected behavior for the "modify object" behavior in the context of group shared/deeded objects. Or more specifically, the question of whether the "modify object" behavior should implicity include deletion.

I hold that deletion should be explicitly provisioned via the group management tools by utilizing the roles and abilities matrix. This is especially so, since the roles currently includes "return object" which implies that this ability must be checked for the assigned member to execute this function, while at the same time, allowing objects to be returned via object deletion. The catastrophic deletion scenario is, of course, that the object is simply deleted as opposed to being returned to the original owner.

The implication here is clear and should be of concern to anyone who is utilizing group functionality to manage objects.

That being said, I would suggest the following possible implementation approach:

1. Remove the implicit deletion ability from the "modify object" behavior for group shared/deeded objects.

2. Add the following ability to Parcel Content (under group roles):

a. Return objects shared with group

3. Add the following ability to Object Management (under group roles):

a. Delete objects deeded to group

b. Delete objects shared with group

NB: Individual owner object abilities should remain. Therefore the owner should always be able to delete their own object, even if they share it with group. Obviously, if they deed the object to group, they will need to belong to a role that allows them to delete or return the object.

Though unless you are the owner deleting objects shared with group is the same as returning them. So maybe just graying out Delete if you are not the owner of a group-shared object that is not deeded.

1. Remove the implicit deletion ability from the "modify object" behavior for group shared/deeded objects.

what do you mean by "group shared/deeded objects"? Do you mean "all objects that are both deeded to the group AND shared with the group", or do you mean "all objects that are deeded to the group, and all objects that are shared with the group"?

There are lots of ways that this could be resolved. Personally, I think that "share with group", which was originally a very simple function back before there were group tools, aimed at letting a small group of mutually-trusted builders collaborate closely on a build, is much too broad a brush to be used in large untrusted groups (like rentals), and would require such huge changes to be useful there as not to be worth the trouble.

The group tools should be improved so that they are useful to rental groups, using group deeded (but not group shared) objects. The concept of "share with group" should be left as it is, maybe made less obvious in the interface so that people don't use it by accident. Just my two cents.

An owner, in the case of a shared object, would of course, retain full access rights. As far as implementation goes? A robust solution will involve both server-side and client modifications.

For example, the group policy matrix (i.e., roles & abilities) would need to be changed to reflect the additional abilities. This would obviously be a database change. Sever changes would involve enforcing the new policy. And changes to the client would involve checking the policy for group shared or deeded objects against the member's abilities, to, as you so note, gray out the delete in the object pie menu of the UI, as well as popping up the obligatory "you do not have permission to delete object" message for those members who click the delete but are denied object deletion abilities.

@Dale writes in part: "what do you mean by "group shared/deeded objects"? Do you mean "all objects that are both deeded to the group AND shared with the group", or do you mean "all objects that are deeded to the group, and all objects that are shared with the group"?"

My response: One, Shared with group and deeded to group should be mutually exclusive. Two, please try to disabuse yourself of the notion that group tools are just for rental groups. Such sweeping and mistaken generalizations are the bane of good design principles and practices.

That being said, I am mystified why you feel obfuscating this problem by making the share with group feature "less obvious" will help anything at all. The problem is that "share with group" allows all members to delete the object regardless of whatever group abilities they may (or not) have. To compound this, the "modify object" ability allows people who do not have the "return objects" ability, to delete deeded objects. And both of these have to do with the "modify object" behavior. (i.e., modify object = move, change, copy & delete).

So, again, if an object is either a) shared with group OR b) deeded to group, deletion of the object should only be allowed for members who belong to roles that allow deletion and/or return of objects. Hence, my suggestion to completely remove the deletion capability from "modify object" behavior for group shared OR group deeded objects and rely upon the roles & abilities matrix to determine a group member's ability to remove and/or delete said objects.

The original use-case for "share with group" was a group of mutually-trusted collaborators. It came before the group tools, and doesn't really get along with them that well presently. It seems like there are two things (at least) that could be done now that there are group tools:

The use-case and the function could be left as is, but disentangled from "Deed to group", since as they are now they are quite different (see SVC-4276). This doesn't break any content or any existing uses of the function. In this case it might be good to move the "Share with group" function further away in the UI, or even "obfuscate" it to some extent, since it's really just a legacy function from pre-group-tools days, left in for those who are used to it. Hope that helps with your mystification.

The other possibility would be to make "Share with Group" basically just like "Deed to Group" (with all of the group member abilities applying), except that the original owner is still the owner, and has owner powers over it. This would be a large change, and would disrupt some current usage, but it could certainly be done.

In either case, I agree with you that when anything ("deed to group" as it is now, and "share with group" as it might or might not be in the future) uses group member privileges to determine what a member can do, it might make sense to have deletion as a separate function from modification, and that idea deserves its own JIRA (SVC-4259?).

(It would still be the case that someone with modify powers could stick in a script that does llDie(), etc, but at least that's unlikely to happen by accident.

From Andrew Linden's office hour:

[11:29] Angela Talamasca: Andrew, have you had any time to look into VWR-5491? Although that was originally posted as a viewer bug, i hold that the problem spans both server and client side.
[11:30] Andrew Linden: Angela, I was talking about that bug earlier. I did try to read it
[11:30] Andrew Linden: It looks like there is a real bug or design flaw there. Yes it would require a server-side fix.
[11:30] Angela Talamasca: i did try to outline the issue to better clarify it.
[11:31] Andrew Linden: Ah yes Angela, actually thank you very much for your comments. Yours were the ones I was reading that helped me actually understand what was being talked about.

Full transcript: http://wiki.secondlife.com/wiki/User:Andrew_Linden/Office_Hours/2009_05_26

Note that SVC-585 is couched as a change or feature request rather than a bug, since in SVC-121 it was pretty well established that, in the current design, group ACLs intentionally apply only to things that are deeded to the group, not to things that are shared with the group. (And also not to things that are both deeded and shared.) I don't have a strong opinion as to whether or not that makes any sense myself but that seems to be the current status, given SVC-121 and SVC-585.

If there is no such specific JIRA entry right now, would someone like to open one? (I could, but I expect others probably have more experience with that specific bug than I do.)

How do you keep track of it all?