Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007836opensim[REGION] OpenSim Corepublic2016-03-06 13:092019-02-06 11:29
Reporterdanbanner 
Assigned Tomelanie 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformPCOSopensimOS Version0.9.0
Product Versionmaster (dev code) 
Target Versionmaster (dev code)Fixed in Version 
Summary0007836: transferring full perm mesh object arrives no copy no transfer
Descriptionfull perm mesh object given to another avatar item shows "No copy No transfer"
Steps To ReproduceUpload mesh object, set full perm and give to another avatar item shows "No copy No transfer"
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineODE, BulletSim
EnvironmentMono / Linux64
Mono Version3.2
Viewerany
Attached Files

- Relationships

-  Notes
(0030067)
danbanner (manager)
2016-03-06 13:16

To complicate matters, some models transfer full perm
(0030140)
danbanner (manager)
2016-04-03 12:39

This is still happening and event setting all permissions and "anyone can copy" the objects still arrive no copy no mod when sending to another avatar. If I rez the model it shows full perm but after taking into inventory again it only shows no copy
(0030141)
Mandarinka Tasty (reporter)
2016-04-03 17:27

Hi Dan. I have checked it. When I upload mesh and it appears in my inventory, then permissions for next owner are:no copy, no mod, transfer.

When I change them ( inside my inventory )to full perm: copy, mod, transfer, and next i send mesh object to another resident, then when resident rezzes it in-world it becomes: no copy, no mod, transfer.

But issue refers to improper changing permissions at once after mesh is uploaded.

It is suggested, that permissions of item should be always set, when it is rezzed on the ground. Do not set permissions for objects inside the inventory.

When You upload mesh and rezz it on the ground and then you set permissions to full perm : copy, mod, transfer, then when you send it to another resident, everything wil be ok.

So avoid setting permissions of an object in inventory, just rezz it, set permissions in-world, take it and send it.

Reason is, next-owner permissions are only applied when the object is rezzed inworld.
It's best practice to rez any object you receive before making additional in-inventory permission changes.
An object's permissions as seen in your inventory (a database handle pointing to an asset) are out-of-sync with the asset's permission itself.

Regards
(0030691)
danbanner (manager)
2016-06-23 03:18

Yes i have noticed that it works as long as i rez the object and then set permissions, take copy back to inventory, send to user (4 steps). It would make much more sense and require less steps to be able to set permissions in inventory. I believe this should work either way.
(0030703)
Diva (administrator)
2016-06-23 12:03

Is this a regression? Did this work in 0.8.2?
(0030716)
danbanner (manager)
2016-06-23 15:40

i did not notice this issue until we went to 0.9
(0030717)
Mandarinka Tasty (reporter)
2016-06-23 15:48

I've been taught by myself to never rely on setting permissions

inside my avatar's inventory. But that's knowledge from SL.

Anyway, if we allow for setting permissions inside inventory in same way as

it is processed via rezzing prim on the ground,then appears the question:

what about with SLAM bit ?

I only remind few facts concernign correct defintion of slam bit:

A "slam bit" is an informal term which refers to the "*" which appears next to the N (next owner) when changing permissions of an object in your inventory. For this reason, you'll only see the slam bit on inventory objects, not inworld ones.

This is shown because next-owner permissions are only applied when the object is rezzed inworld. For example: you've given what you think is a no-copy gift to a friend but are surprised when you visit them and they have multiple copies out on their lawn. The rezzed copies have been restricted to no-copy since when each is rezzed, permissions are applied, but their inventory version (the one you gave them directly) doesn't have such restrictions.

It's also important to note, object transfers between avatars can result in unexpected permission behavior, if an object isn't rezzed to 'slam' the currently set permissions befor making changes. It's best practice to rez any object you receive before making additional in-inventory permission changes

Reproduction Model:

For those that are wanting to use "Slam Bit" as a tool for games such as breedables and trading card games; in the way that you have object B inside the inventory of object A and you desire object B to be rezed many times out from object A but then be No Copy after it has rezed; follow these steps.
1. Rez object B in world.
2. Set the script inside the object to no copy (don't forget No Mod if you need it).
3. Pull prim into inventory (you will now notice the No Copy perm has been set automatically).
4. Edit permissions (object B still in inventory) and set object to Copy.
5. DO NOT rez object B. Edit object A and put object B into Object A's inventory.

Certainly, I like "slam bit" so if you want to change it.

then please also remain actual behaviour

Regards
(0030719)
Diva (administrator)
2016-06-23 16:44

Does this affect only mesh? Or any uploaded item? Or any item?
(0030720)
Mandarinka Tasty (reporter)
2016-06-23 16:51

All this discussion concerns only object's permissions.

So meshes too, since mesh object is an element of Objects' set.

But that does not refer to any other item like: animation, texture, clothing layer etc.
(0030721)
Diva (administrator)
2016-06-23 16:53

Basically, I'm trying to simplify the scenario, because I don't want to upload a mesh object everytime I test it. So what's the simplest item where this bug shows?
(0030722)
Mandarinka Tasty (reporter)
2016-06-23 17:00

In my opinion, that requires incredible big attention to not destroy = change permissions of objects, that have been created in the past by users.

Eventual changing behaviour of permissions can have unexpected influence on

those objects, it implies danger that objects created by ppl in the past lose

permissions = lose expectation of their creators.

For examle , I have created line of boots, and deliberately i used

slam bit trick, to make box be non-copyable and transferable, but

content of the box, copyable and non-transferable.

That is trick used by creators in aspect of giving = selling gift boxes.
(0030723)
Mandarinka Tasty (reporter)
2016-06-23 17:01

Diva, You can simply create:

object = one primitive and also please test it with some content inside of it.
(0030724)
Mandarinka Tasty (reporter)
2016-06-23 17:02

Then, please set permissions on the ground and paralley in inventory.

and then observe how permissions are being chanaged when you send object to other

avatar = your alternative account.
(0030725)
Mandarinka Tasty (reporter)
2016-06-23 17:06

Meshes, are such objects, that after uploading, their default permission,

that appear in inventory is: NO MOD, NO COPY, TRANSFER.

So maybe it is enough to make viewer upload them fully-permissive

without destroying other things.

But exercises you may do with ordinary objects = setting permissions and sending it.

Then you are able to compare how behaviour is changed and what differecences are

between setting permissions in inventory and on the ground.
(0030726)
Diva (administrator)
2016-06-23 17:06

Got a repro. Thanks. Much simpler than uploading mesh.
(0030735)
Diva (administrator)
2016-06-24 07:54

@Melanie, when you get to this, I confirm that the single prim scenario works differently in 0.8.2 than what it works in 0.9 dev. Do this:

1 - Rez a prim. Do not change its perms, so its next owner's perms are none.
2 - Take the prim to inventory. Edit its inventory properties, mark it next owner copy+transfer+modify
3 - Give the prim to another avatar.
4 - Have that other avatar accept the prim and rez it inworld. Check its properties inworld.

In 0.8.2, the prim is marked full perms. In 0.9 dev, it's marked no perms.
(0030736)
Diva (administrator)
2016-06-24 08:14

FYI I found the part of the code that is responsible for this change in behavior: SceneObjectPartInventory, GetRezReadySceneObjects. There's a block of code commented out that was responsible for changing the permissions of the object as it is being rezzed:

/* reverted to old code till part.ApplyPermissionsOnRez is better reviewed/fixed
                group.SetGroup(m_part.GroupID, null);

                foreach (SceneObjectPart part in group.Parts)
                {
                    // Convert between InventoryItem classes. You can never have too many similar but slightly different classes :)
                    InventoryItemBase dest = new InventoryItemBase(item.ItemID, item.OwnerID);
                    dest.BasePermissions = item.BasePermissions;
                    dest.CurrentPermissions = item.CurrentPermissions;
                    dest.EveryOnePermissions = item.EveryonePermissions;
                    dest.GroupPermissions = item.GroupPermissions;
                    dest.NextPermissions = item.NextPermissions;
                    dest.Flags = item.Flags;

                    part.ApplyPermissionsOnRez(dest, false, m_part.ParentGroup.Scene);
                }
*/
(0034463)
BillBlight (developer)
2019-02-06 11:29

Marked as Resolved but never closed, can be reopened if needed.

- Issue History
Date Modified Username Field Change
2016-03-06 13:09 danbanner New Issue
2016-03-06 13:16 danbanner Note Added: 0030067
2016-04-03 12:39 danbanner Note Added: 0030140
2016-04-03 17:27 Mandarinka Tasty Note Added: 0030141
2016-06-23 03:18 danbanner Note Added: 0030691
2016-06-23 12:03 Diva Note Added: 0030703
2016-06-23 15:40 danbanner Note Added: 0030716
2016-06-23 15:48 Mandarinka Tasty Note Added: 0030717
2016-06-23 16:44 Diva Note Added: 0030719
2016-06-23 16:51 Mandarinka Tasty Note Added: 0030720
2016-06-23 16:53 Diva Note Added: 0030721
2016-06-23 17:00 Mandarinka Tasty Note Added: 0030722
2016-06-23 17:01 Mandarinka Tasty Note Added: 0030723
2016-06-23 17:02 Mandarinka Tasty Note Added: 0030724
2016-06-23 17:06 Mandarinka Tasty Note Added: 0030725
2016-06-23 17:06 Diva Note Added: 0030726
2016-06-23 21:08 Diva Assigned To => melanie
2016-06-23 21:08 Diva Status new => assigned
2016-06-24 07:54 Diva Note Added: 0030735
2016-06-24 08:14 Diva Note Added: 0030736
2017-01-06 15:45 melanie Status assigned => resolved
2017-01-06 15:45 melanie Resolution open => fixed
2019-02-06 11:29 BillBlight Note Added: 0034463
2019-02-06 11:29 BillBlight Status resolved => closed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker