Re: Script bugging after sale
Posted: Sun Sep 25, 2016 2:53 am
There are several issues here:
1) How permissions are defined and changed inworld.
2) How does Kitely Market decide which permissions to give a delivered item.
3) How the effects of item permissions change what can and can't be done by a script you own.
Issue 1:
Inworld permissions are changed in Kitely (and OpenSim in general) the same way they are changed in Second Life. Please read about how object permissions are changed when you modify a contained object here: https://community.secondlife.com/t5/Eng ... a-p/700129 please also note how Folded Permissions work (see: http://wiki.secondlife.com/wiki/Debug_Permissions)
As you'll note there are several ways in which permissions do not behave (in Second Life and OpenSim) as you might expect. We would have designed a different permissions system but that is how Second Life / OpenSim was designed and we aim to maintain compatibility with OpenSim when it comes to the basic logic behind object permissions.
In your first scenario you've made changes to permissions of items while they are inside other items, this can result in behaviors that are different from what you expect (again, as per the Second Life wiki). My suggestion is that you only set the permissions of your chair while it isn't inside the table and only then add it to the table's contents. In other words, if you want to avoid surprises don't use features that cause a delayed application of item permissions and if the change you're about to make is going to use the Slam Bit then avoid doing it (again, this is all by Second Life design).
Issue 2:
Kitely Market is not involved in any way when someone buys items inworld, that is handled exactly as it is in standard OpenSim 0.8.3 (i.e. in what is now the latest official OpenSim release). Meanwhile, the Kitely Market delivery system doesn't apply changes to permissions using the OpenSim code so if you want to test how things will work when people buy from Kitely Market you'll need to test it via Kitely Market not via an inworld transaction.
The Kitely Market delivery system uses the Next Owner object permissions that are actually defined inside the object when you add it to a listing. You'll note the exact state of those permissions in the Variation Items table in the product listing. If anything there doesn't match the Next Owner permissions you see in your inventory then your inventory probably includes items with Slam Bits set that will apply changes to your inventory items once those items are rezzed. You'll need to rezz the item to have the delayed permission changes applied then modify the item's permissions as you see fit and only then add it back inside another item or directly into your inventory. If you do it in another way then (a) you're ignoring the Second Life wiki's recommendations and (b) you're not going to get what you expect.
Issue 3:
Given the additional information you provided it sounds like you're encountering an issue that results from a delayed application of permission changes.
In your first scenario the rezzed chair behaved like the permissions you gave it while it was inside the table but the viewer displayed permissions that look different from what you expect (probably the ones the chair had before you made the change to its permissions). There is obviously a difference here between what the server allows you to do with the script-rezzed object (which sounds like the permissions you gave it) and what permissions the viewer displays (whose origin I don't have enough information to determine). In other words, you set the chair to be mod/copy/notrans and it behaves like mod while the viewer is showing something else. In other words, it sounds like the permission system is enforcing the permissions it should but the viewer is not displaying them properly (which is a problem but not with the permissions system).
In your second scenario it isn't clear whether the buyer of the item is the same avatar who created the item and/or the owner of the item on sale. Are you making sure to run this test with an avatar that is different from the owner and creator of the item that is being sold? If the buyer is the same as the seller then the buyer will have permissions that other buyers may not. It is very important that you extract all the relevant items, set their Next Owner permissions correctly and only then place them inside each other and take it into your inventory. Then add them to Kitely Market to see what Next Owner permissions that actually have and only if you see the permissions you expect to see then you should expect the Kitely Market delivered item have the current owner permissions you wanted it to have. (this is one way in which the Kitely Market Variation Items table can help you debug your items, you can see other ways here: https://kitely.atlassian.net/wiki/displ ... g+Products).
TL;DR You've shown that things don't behave as you expect them to but (a) your reasoning that it proves the permission system is broken may be wrong and (b) we haven't ruled out the way you're applying the permissions not being the source of the problems you're encountering. Please test using the Variation Items method I described above and, once you make sure the listed permissions are as you intend them to be, please test using the Kitely Market Test delivery feature.
1) How permissions are defined and changed inworld.
2) How does Kitely Market decide which permissions to give a delivered item.
3) How the effects of item permissions change what can and can't be done by a script you own.
Issue 1:
Inworld permissions are changed in Kitely (and OpenSim in general) the same way they are changed in Second Life. Please read about how object permissions are changed when you modify a contained object here: https://community.secondlife.com/t5/Eng ... a-p/700129 please also note how Folded Permissions work (see: http://wiki.secondlife.com/wiki/Debug_Permissions)
As you'll note there are several ways in which permissions do not behave (in Second Life and OpenSim) as you might expect. We would have designed a different permissions system but that is how Second Life / OpenSim was designed and we aim to maintain compatibility with OpenSim when it comes to the basic logic behind object permissions.
In your first scenario you've made changes to permissions of items while they are inside other items, this can result in behaviors that are different from what you expect (again, as per the Second Life wiki). My suggestion is that you only set the permissions of your chair while it isn't inside the table and only then add it to the table's contents. In other words, if you want to avoid surprises don't use features that cause a delayed application of item permissions and if the change you're about to make is going to use the Slam Bit then avoid doing it (again, this is all by Second Life design).
Issue 2:
Kitely Market is not involved in any way when someone buys items inworld, that is handled exactly as it is in standard OpenSim 0.8.3 (i.e. in what is now the latest official OpenSim release). Meanwhile, the Kitely Market delivery system doesn't apply changes to permissions using the OpenSim code so if you want to test how things will work when people buy from Kitely Market you'll need to test it via Kitely Market not via an inworld transaction.
The Kitely Market delivery system uses the Next Owner object permissions that are actually defined inside the object when you add it to a listing. You'll note the exact state of those permissions in the Variation Items table in the product listing. If anything there doesn't match the Next Owner permissions you see in your inventory then your inventory probably includes items with Slam Bits set that will apply changes to your inventory items once those items are rezzed. You'll need to rezz the item to have the delayed permission changes applied then modify the item's permissions as you see fit and only then add it back inside another item or directly into your inventory. If you do it in another way then (a) you're ignoring the Second Life wiki's recommendations and (b) you're not going to get what you expect.
Issue 3:
Given the additional information you provided it sounds like you're encountering an issue that results from a delayed application of permission changes.
In your first scenario the rezzed chair behaved like the permissions you gave it while it was inside the table but the viewer displayed permissions that look different from what you expect (probably the ones the chair had before you made the change to its permissions). There is obviously a difference here between what the server allows you to do with the script-rezzed object (which sounds like the permissions you gave it) and what permissions the viewer displays (whose origin I don't have enough information to determine). In other words, you set the chair to be mod/copy/notrans and it behaves like mod while the viewer is showing something else. In other words, it sounds like the permission system is enforcing the permissions it should but the viewer is not displaying them properly (which is a problem but not with the permissions system).
In your second scenario it isn't clear whether the buyer of the item is the same avatar who created the item and/or the owner of the item on sale. Are you making sure to run this test with an avatar that is different from the owner and creator of the item that is being sold? If the buyer is the same as the seller then the buyer will have permissions that other buyers may not. It is very important that you extract all the relevant items, set their Next Owner permissions correctly and only then place them inside each other and take it into your inventory. Then add them to Kitely Market to see what Next Owner permissions that actually have and only if you see the permissions you expect to see then you should expect the Kitely Market delivered item have the current owner permissions you wanted it to have. (this is one way in which the Kitely Market Variation Items table can help you debug your items, you can see other ways here: https://kitely.atlassian.net/wiki/displ ... g+Products).
TL;DR You've shown that things don't behave as you expect them to but (a) your reasoning that it proves the permission system is broken may be wrong and (b) we haven't ruled out the way you're applying the permissions not being the source of the problems you're encountering. Please test using the Variation Items method I described above and, once you make sure the listed permissions are as you intend them to be, please test using the Kitely Market Test delivery feature.