|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 15/Apr/07 09:00 AM
Even before roles, sharing with group allowed people to return (or take, or delete) your shared objects. The roles you're referring to allow group members to return objects even when they're not shared, so long as they're on group-owned land. If you don't like this, I think you should rewrite the issue as a feature request that sharing does not allow group members to return your objects (and incidentally, I LIKE this behavior!).
Lex,
All this group of bugs/features that I filed around this time are not issues I personally encounter, rather they are filed as part of an investigation of MISC-40. I personally am neutral on this. However this is an unexpected behavior, so I believe it should stay bug. One possibly fix might be to change the expectations by making the role ability name more specific. this is a huge group bug.
You make the roles to control the group, and to be sure..that the different roles, HAVE different functions. For example, for builders in a group who have an own role, its very important that only they can build an object and then move or manipulate it. There have to be a solution, that the share with group function works together with the role functions...so..when u deactivate move and manipulate objects.... in a role..that it is REALLY DEACTIVATED for that role. I think this is a big issue, we want to have only certain objects be able to be moved by members of the group and all of a sudden they can return, take and delete the object. Share with Group should respect the Parcel Content abilities of the group.
You can also copy objects shared with group. This means if you are part of a shopping/mall group in order to place your items out and accidently set Share to Group your object can be copied by every other member of the group.
**
Then maybe the bug is in the design, Soft. It's not rational. Nobody needs to have group-set prims returning by those not enabled to return them. It defeats the whole purpose of granulating group roles.
It's also completely bogus, Soft, to suddenly declare "This is by design" when in fact it WAS NOT the design for at least the 3 years I've been in SL, came up as a BUG in the past and was squashed, and now has come BACK in a new version "just because".
Could you explain why you decided to change the design and introduce this bug and flaw in the granulated group tools?! I'd like to get a clear answer on this please,
This bug – yes, BUG, as it breaks functionality deliberately designed in the group tools three years ago, is causing TV theft. If you create a role that you assign to people as "resident" in a group that enables only paying tenants to deed and undeed TVs, what is happening now is that people who are just "everyone" in the group to set prims on the "basic" membership can access a shared, deeded object. Worse, they can now RETURN any shared object set to the group – which is totally destructive. This bug is costing me and tenants thousands of Linden dollars in the occasional stolen TV and the much more frequent returned house, which can sometimes delink or delete. Sorry, but a bug enabling theft and destruction doesn't get to close.
This is indeed a bug, and suddenly blessing it with the name "design" after it was originally coded completely differently is just preposterous. I have yet to hear an explanation for this. Furthermore, the expected behaviour – and the behaviour that in fact obtained before this nonsense – is that you check off a function within the role, then that role has that function. Currently "everyone" who is NOT checked off to have the function "share" or "deed" or "return" or "sell group object" *is getting that function. Prokofy, I didn't declare this "by design" unilaterally. This was the result of a public bug triage in August '07. The change people asked for would be a new feature, not the repair of a bug, which is why I created a separate JIRA representing the feature request.
How on earth is this by design? Surely a design shouldn't undermine other group features in this manner.
The first and last time I ever deeded an object to a group I had to first check off 'Share with Group' before the 'Deed' option was allowed. In doing so this meant - though I did not know it at the time - that I could choose to let everyone in the group use said object or only those with specific access in the group roles. In the end I had to have the group owner come by and fix my mistake - I could no longer do anything with my own object because it had been deeded to a group that I did not have the right permissions in.
Unless someone can prove this behavior as no longer being present this issue is being set back to closed again - I note the REPORTER set it to 'closed'. Kindly respect their wishes. 'Share with Group' was designed before Groups had roles and abilities, so it was never designed with these in mind.
When the group roles and abilities were designed, they consciously overrode the global "share with group" and made it one of the powers of the roles.
That can easily be seen by looking at the interface, where it is a checkoff box. It originally worked as designed, and checking it off gave those with that role access to put items in "share," and did not give access to those not in that role. It ceased working, because it had a bug. To invoke some old feature of the software that preceded a conscious overriding of the software really seems like a lame argument. The curious ideological closing of this JIRA confounds me, and I really would like to get to the bottom of this and hear from Lindens who worked on the design of the group tools a good explanation as to why their work, which developed a bug in it, suddenly got destroyed and got re-named as a "feature". "When the group roles and abilities were designed, they consciously overrode the global "share with group" and made it one of the powers of the roles."
I never remember this ever being the case, and Soft Linden looked to see if the code had ever been that way and responded on SVC-585: Prok Dearie I see that you haven't actually looked at the check box.
It is within the object itself - not within the group permissions system. It is not a "power of the roles" but an object property. By design it overrides the group permission system and is therefore operating as designed. The Lindens revisited this and marked it critical.
Look at the group tool boxes, Universal, the design is obvious. The object properties are a related, but secondary issue.
http://secondthoughts.typepad.com/second_thoughts/2009/01/the-history-of-group-tool-reform.html This is as designed. To make this more clear, the tooltip text will be changed to indicate that share with group affects all members, and will explain the need to deed in order to enact group restrictions.
Use SVC-585, which is categorized as a new feature if you wish the behavior to change. Bug fixes and design changes go through very different approval and development processes. The issue is not a "tool tip" that explains that "share with group affects all members". Obviously, "share with group" means...um...share with group.
That is not the issue. The issue is the permission to return group-set prims or not return group-set prims. That is separate. Someone who can RETURN group-set when they are not entitled to do that is embodying a bug in the group permissions system. The tooltip explains more than that, it explains that the group abilities only apply when Share with group is checked to deeded objects.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Share with group does not respect Role Limitation
