• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-4276
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Dale Innis
Votes: 4
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

Don't require "Share with Group" before "Deed to Group" (reduce accidental sharing)

Created: 19/May/09 05:51 AM   Updated: 27/May/09 06:53 AM
Return to search
Component/s: Groups
Affects Version/s: 1.26 Server
Fix Version/s: None

Environment: (All versions, really; this is a design bug more than a code bug; might even be a new-feature request.)
Issue Links:
Relates
 


 Description  « Hide
The object attributes that the UI describes as "Share with Group" (which enables anyone in the group that the object is set to to manipulate the object in various ways) is pretty much entirely different from the action that the UI calls "Deed to Group" (which changes the owner of the object to the group, and allows group members to manipulate the object as specified in the group's settings).

The one place where these two things are linked is in the fact that before an object can be deeded to a group, it must first be shared with the group. This has resulted in various things that are deeded to groups for land-mangement purposes (radios and TVs and other media controllers on group-owned rental land, for instance) ending up also shared with the group more or less by accident, which has various negative consequences (in particular, other renters in the same group can manipulate those objects in various ways, and cause trouble through malice or ignorance or carelessness or simple error).

This JIRA item proposes fixing this design bug by removing the requirement that an object be shared before it can be deeded. This change would break no existing content, or even existing habits; the only change in behavior would be in the case where someone attempts to deed something of theirs to a group without first sharing it. After the change, this would succeed, rather than failing.

(As a separate change, it might also be useful to decouple these two things visually in the UI; but that would be a different JIRA I think.)

CLARIFICATION: The suggestion here is that Residents be able to deed their own objects to a group without first sharing them with the group. I don't intend to suggest that anyone be able to deed random objects belonging to other people. I've edited the wording above to make this clearer. Thanks to Prokofy Neva for pointing out the possible misinterpretation.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Soft Linden added a comment - 19/May/09 09:02 AM
They really are two separate beasts. There's also the concern that a person could be logged out between sharing and deeding, or a packet could be lost, and the object would be left more permissive than intended.

That said, accidentally deeding an object can be tragic. If the object isn't transferable, once deeded it's lost if it's returned. If an object isn't set permissive for the next owner, a build can accidentally be made no-mod and no-copy. The current two-step workflow prevents accidental clicks. Even if this changes, it would be good to maintain some form of protection here.


kelly linden added a comment - 19/May/09 11:54 AM
I agree with this proposal. The link here came into existence before group roles and powers. At that time deeding to the group was a further step of sharing with the group. Sharing gave the group some powers, but left your abilities intact, while deeding removed what special abilities you had as owner. That is no longer the case and they are indeed completely different entities now which should be unlinked.

I also agree with soft. I don't think the current two step process is effective though and we should warn if deeding to a group will result in a more restrictive object, give information on what is changing ("this item will no longer be modifiable" etc) and probably give an option to fix it - an "oops! set it as permissive as possible please!". Lets not add a second step that just says "are you sure your permissions are correct? [deed] [cancel]". That kind of dialog just increases dialog blindness and is not effective.


Dale Innis added a comment - 27/May/09 06:51 AM - edited
(Clarified description to make it clear that this would not allow people to deed other people's objects, only their own.)