|
|
|
[
Permlink
| « Hide
]
Zi Ree added a comment - 02/Apr/07 12:07 AM
To be precise, the changes on permissions you're seeing are applied to the copy, not the original. The way SL works is, that the object you move with Shift-copy is the original. The object "left behind" is the copy.
I voted for this - I had the same problem - we have a few people collaborating on building things and we ran into this. We ran a series of tests to isolate it and try and find a way around it but all had the same result.
We have had to rebuild a lot of things!! It has also stopped us working together until we find out if this will be changed in any way. We had experimented with group ownership etc but nothing seemed to make a difference. Even an easy workaround would be better! This is not a bug, this is a misunderstanding of how the system works.
To correctly allow an object to be manipulated and copied by a group sharing modify rights: 1. Create an prim, verify that ALL next owner permissions are checked. NOTE: I've noticed that some builders use this functionality intentionally on their items. The original they give you is modifiable, but if you make copies, you can no longer modify them. Changing how this works might break some things in-world, or at least how builders expect their goods to behave.
I've lost an item due to this recently.
A friend with modify rights shift dragged an item, played around with it and deleted it afterwards, unknowing that he had the original and the copy was the one left behind and had no mod permissions. I think the behaviour of shift-dragging should be changed so the original is left behind in the old position and the copy moved, like one would expect it to be. There needs to be some better intuition here. I've accidentally modified an original before, thinking that I had the copy after the shift-drag.
I believe the simple solution would be to avoid the ownership differentiation all together on 'modify rights' type operations.
This would not only fix this 'bug' (It's a function) but it would address scripts and notecards in an object being unviewable/editable by anyone but the object owner. To word it differently, I believe what's needed is for SL to equate the actions of the person granted rights as if they were the object owner himself. I mostly deal with scripted builds and this is very high on my annoyance meter. One big problem this causes I ran into whilwe working on a landscaping job. We were using sculpted rocks and water, which were copyable, but no transfer. since my contractor owned theser object, that meant he had to make a vast quantity of them for me to use, and be on hand to duplicate more if I ran out, as I was unable to copy them myself.
In internal triage - shouldn't be assigned to me
This does prove to be quite a problem when building collaborativel. I'm currently building an extremely complex and large scale project with my partner, and had we not figured out what process was causing this behavior we might have had to rebuild a lot more than we did... and with a ~700 prim project that could get really messy really easily.
This is really a feature request to change the current behavior. Definitely has my vote. I'd love it if copying people's objects I have modify rights for didn't trigger a transfer, that way the two could be linked.
VWR-8049 should also mitigate some of the frustration this behavior causes. Ux triage determined that, although this behavior is confusing, changing the actual permissions behavior at this point would significantly break content. However, there is a JIRA proposing a change to the copy behavior itself: VWR-2820 that might be worth a look.
VWR-8049 and similar issues may also help ease the pain. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Copying someone else's prim triggers a transfer
