The problem i found is when I set permission on item and just send to another AV. The permission does not the same.
Item that mark NC,NM,NT can edit and copy. and sometime I set C,M,NT then send to another AV it just show NC,NM,NT?!?

Some item I made with permissions C,M,T if I send to other AV, he rez it inworld but he can't copy (press shift and drag) It say he has no permission to do? but in Inventory he can copy freely.

Sometime even owner can't change the permission on the attachment item. I must rez item on ground and change permission but then again if I take it back to inventory and check property (right click item in inventory) the permission is not what I set before!

• • • Nothing really work It's all mess up. ****

I just release my new product and have try 5hrs to fix problem just to change permission on 22 objects. This is my solution for now If your item have been using Buck Permission Setting and it mess up..

1. Rez item on the ground and unlink it, change permission one by one before link it back.

2. Take it back to Inventory, right click on item one by one see property if it's correct setting, if not just check the box correct the permission you want to set.

3. Send item to your alt AV to see if permission work correctly. click on all item and check one by one see if it working as their permission set or not.

4. If you have bad luck like me some of item is not working.. I choose to delete it and build another one to replace. (I use sculpty so i don't have to rebuild everthing).

Good Luck.

However, I tried to reproduce this on a server-1.27 simulator on the aditi grid and it failed – my final "Item for sale" showed up no-modify + no-transfer. I was using viewer-1.23.4 on Linux.

Meanwhile, the repro object that Latif gave me a few days ago reproduced the problem – the resulting permissions were not the same as the final ones when I rezzed "Item for sale" from my inventory.

When I pulled the assets of the two wrappers and examined them side by side in detail I found that a little bit in the permissions of the inventory item was not set in Latif's version – the bit that instructs the simulator to apply next-owner-perms when the item is rezzed. I don't yet know why that is happening, but it happened when Latif performed the "preparation for sale" step. I'm going to try to run the full repro on a server-1.26 simulator and see what happens.

Ok, I see now that it's listed in environment. Anyway, I'm pretty sure this isn't an issue for viewers 1.22 and earlier, so one might want to fall back to avoid the bug till its fixed.

In my case I was using the same viewer (1.23.4 on linux) for both server-1.27 and 1.26 tests, so I think it is NOT a client bug and I would expect it to be independent of the viewer version.

I think the "fix pending" status is correct, however any content built with this method in server-1.26 will continue to rez with incorrect permissions in server-1.27... sorta. The flaw lies in the "shopkeeper prepares the item for sale" stage, so if the shopkeeper redoes that step in server-1.27 the final asset should rez correctly in server-1.27 and 1.27.

If anyone verifies or invalidates my findings please post the info here. Thanks.

I have just reproduced this in server 1.27 following the steps above (all done in 1.27). Using three different avatars, the third avatar's item was full perm item when it was rezzed.

Second Life 1.23.4 (123908) Jun 11 2009 15:16:56 (Second Life Release)
Release Notes

Built with MSVC version 1400

You are at 250692.8, 286378.7, 27.0 in Crux Isle located at sim7612.agni.lindenlab.com (216.82.36.220:13001)
Second Life Server 1.27.0.127440
Release Notes

CPU: Intel Core 2 Series Processor (2200 MHz)
Memory: 3583 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9600 GT/PCI/SSE2
Windows Graphics Driver Version: 6.14.0011.8585
OpenGL Version: 3.0.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.25442 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 0/13894 (0.0%)

Anything packaged on 1.26 has to be repackkaged so it is yet another massive strike by LL on the economy while content creators have to halt selling everything and repackage from scratch all products.

And we still don't know if it is actually just some code that applies whatever your bulk permissions are to anything you transfer which seems to me to be another possibility.

So set your bulk permissions to mod/copy/no transfer and let the complete end of customer transferable content begin.

1. Rez two boxes, one named "Inner", the other one "Outer" (just for identification purposes)
2. Give full permissions to the "Inner" Box.
3. Take the "Inner" Box and put into the "Outer" Box.
4. Edit the "Outer" Box and use the Bulk permission feature to make everything within the "Outer" Box Transfer only.
5. Review the permissions of the "Inner" Box within the "Outer" Box by rightclicking and choose Properties, it will show as Transfer only.
6. Rez the "Inner" Box directly out of the "Outer" Box (or open the "Outer" Box to get it contents)
7. Review the permissions of the newly rezzed "Inner" Box. It will have all permissions.

I also made another interesting observation: If you reset the permission manually in step 5, by just enabling and disabling the copy and modify checkboxes again, and proceed with the remaining steps, the permissions are correct.
If you then use the Bulk Permission feature to give any permissions to the "Inner Box", these permissions remain correct when rezzed too.

After further experiments i found out that the Bulk Permission Features only works on the "Inner" Box, if its permission has been manually at least once set via rightclick>Properties like described above.

I tried it with several inner items too, and all of their permission need to be set manually within the Outer Box at least once before Bulk permission works.

We've went into our servers, pulled out the boxes, opened the contents and rezzed them on the ground. A few of our things were suddenly set to full perm. We had done the permissions on these months ago. Something else that is even more bizzare.

When I box my stuff up I create two folders; a full perm and a seller folder. The full perm has a full perm verison of the items while the seller has the permissions set for stuff that I want to sell. This making it easy for me know what to give out to people and what to update.

Well.. one of my items in my seller folder when rezzed was full perms too. So either I goofed on that one or there is another bug related to this one.

Things like scripts and animations that are generally permed in inventory, are unchanged, however prims which are permed in world.. are the ones that have changed.. And appears to be random items. Anyone notice anything to the contrary ?

edit; Afterthought.. after i spend all weekend checking perms and re-perming a few items, ......How do we know they will stay that way ?

All done on 1.27 (no objects created on earlier servers involved in the repro).

Reopening.

Anyone want to risk a ban by upgrading to showstopper?

I guess the usual office hour mob is the only way to get this discussed and get the facts out in front of the right people. Seems to be the only way to get anything done anymore. I have a great disdain for mob governance but if that is what LL wants then that is what LL gets.

So the first level would be Andrew's Office hour I guess.

Andrew's office hours are:

Tuesdays from 11am to 12pm California time
Thursdays from 5pm to 6pm California time

http://slurl.com/secondlife/Denby/213/45/34/?&title=Simon+Linden%27s+land+in+Denby

Edited to add:

You know this could be blogged extensively and make it onto all the feeds and become a serious public relations problem. I wonder if Linden Lab would care to address this properly before that eventuality happens. The residents have dutifully follwed the pjira procedure and we don't see the level of concern being applied to this that is called for.

The fact that this could have been going on since April when 1.26 was released and subsequent patches addressed perm-ing or at the very least June when it was reported, IS a major concern. Especially now that it has been 1 month since reported.
Linden could possibly be facing subsequent lawsuits so I cannot imagine why it has not been resolved.

I was up to the wee hours attempting to check my inventory last night and I still have another 2-3 servers to go through. I then will have to cross check the items in question against sales since April. This is what I have found SO FAR:

• I have found this seems to be affecting OBJECT permissions. (in my case the main concern is animations and scripting, which appears to be safe from what i have observed)

• Scripts, animations, textures for clothing generally is pre-permed in inventory or on upload and i have not found any to have been affected, HAS ANYONE ELSE ???

• Prims become full perm, whereas the scripts & animations within them hold their correct perms.

• It effects RANDOM items... Things boxed prior to 1.26 (in my case as far back as things boxed in Nov) , as well as, presently being able to be replicated with bulk permissions ....IMO The original "glitch" affected random previously permed items and now is isolated to bulk perms only.

• Items i found with full perm prims, have been re-permed and appear to be keeping the correct permissions. So items were affected prior to certain fixes they did during 1.26. See SLWiki on updates and fixes for 1.26 - there are several concerning object permissions

• Using bulk permissions replicates the original issue - Items appear to have one set of perms while in a BOX.. when ressed the permissions change... (see Maygray Heron's post, that test works) Items show one permissions in the box, another when ressed both in items boxed in Nov and tests done with bulk perms

• so far all that i have had to fix .. re-perm have kept the correct permissions, however we do not have any guareentee that they will not change or others that were previously unaffected will not change. Perhaps it was the original glitch that caused the changes in previously permed items ?

• there is NO clear pattern, date of creation, or certainty which items have or have not been affected. Bulk Perms account for more recent items but it IS NOT A VIEWER SIDE ISSUE , it also includes previous non-bulk-permed items that are showing a change when ressed. The only thing for certain seems to be it is Object Permissions & SERVER SIDE

People who make PRIM only creations.. clothing with sculpts & attachments, jewelry, shoes, hair, etc. will be the ones facing potentially disastrous problems. Yes, I am recommending to friends to painfully pull every item made out of servers/vendors/slx and take out of boxes. I have found 10/100 to date

Its great that Andrew has office hours.... On Tues.... but in the US...its only Sunday... do we need to wait 48+hrs to get his attention ?
TOO MUCH Publicity to this situation is a CATCH 22 and the longer this waits the more that WILL happen ......
There is a theory in the service industry... a good experience a person will tell 2-3 people.. a Bad experience.. 10. So in other words.. this will be pretty much grid wide knowledge by Monday.

The item MUST have the perms changed with the BULK PERMISSIONs button via the contents of the box etc

AND

The item MUST go through to a third party - that is when the perms change.

The item which is then boxed, must also be rezzed in world before being boxed by the second person.

I have tested sending the item to just one other person - the perms remain correct even using the bulk permissions.

I have tested sending the item to a third party having changed the perms manually (not using the bulk permissions) - this resulted in the perms remaining correct.

I have also sent my alt a full perm desk, then boxed the desk without rezzing it in world, and then used the bulk permissions to change the perms - it did NOT revert to full perms.

The end result for me is this: Don't use the bulk permissions until this is fixed, especially where a third party will be taking the object.

EDIT: I have now managed to reproduce the bug by following the steps for the Inner/Outer box as described above. For me, it is still the bulk permissions which is the main factor in things changing permissions. When I do the same test with changing the item's perms manually, it maintains the correct perms.

Also - It has only been objects which change perms, not scripts/anims etc (as per Mystiphi Ghia's findings)

The Bulk Permissions button appears to mask the true permissions on the object, such that the original permissions on the prim prior to hitting the Bulk Permissons button on an enclosing prim remain with that prim upon transfer to a second or third party.

SO: in the case of SVC-4529 - creator makes prim objects, does not change perms from no copy/no mod/transfer, takes to inventory and changes permissions via bulk permissions change in a box; final item transferred to customer is no copy, no mod, transferrable.

In the case of SVC-4444 - creator makes prim objects, makes them all full permission (presumably while rezzed or in inventory) so that second hand distributor (or fellow builder/scripter) can work with it - second hand distributor changes item permissions via bulk permissions button, sets box for sale; final item transferred is full perm regardless of what the second hand distributor has done.

I wonder if Linden Lab would care to address this properly before that eventuality happens. The residents have dutifully follwed the pjira procedure and we don't see the level of concern being applied to this that is called for.

If you thought there was M-induced tunnel-vision slamdunking new code to support Zindra, wait till you see how getting fixes for stuff broken by the slam is outside the developer vision tunnel. I expect it will be much worse than all the H4 and Mono breakage.

Because the phenomenon you see "Objects become fully permissive when rezzed under certain conditions" is just a result of Bulk permission error.

Some residents already miss understood this problem by summary title, and panicing around like "You have to stop all the selling item and have to check them!". It's not true, the shop owner have to recheck the items only which they use Bulk permission change through packaging their items.

So, all we have to notice around is:

• Don't use bulk permission change system until fix released.
• Recheck your item if you use item packing with bulk permission change function.

PS.
I reprod this bulk permission system error too.
You don't have to do this with 3 persons, you only need 1 or 2 to repro this.

Additionally, if you read the comments, you will find that people are experiencing the same issue with objects that were packaged before the introduction of bulk permissions. I have confirmed this myself. Its only that we now have a clear repro case that utilizes bulk permissions to show the problem.

1) Rez a box.
2) Drop in any item that you don't have full perms for.
3) Use the permissions button in edit to set the content full perm (also for extra value set anyone can copy/share with group).
4) Examine the enclosed item by right clicking and examining its properties.

Although there is obviously some hacky catch/patch code in there now to stop the item being rezzed in the full perm state, The item DOES STILL show all checkboxes marked.

THUS this is a fatal bug waiting to resurface owing to the sick implementation of "bulk permissions". The developer who made this change obviously was not aware of the differences between base permissions and owner permissions.

The only sensible approach would be to ROLL OUT bulk permissions entirely and review the underlying permissions system before the ability to game the perms system surfaces again.

LL should also strongly consider what they can do to address the losses already incurred by residents who may have irrevocably lost control of some or all of their items when the permissions exploit was available to the world at large.

I am DISGUSTED.

• Simplifying it to JUST a Bulk Permissions issue is ridiculous, Bulk Perms are Viewer Options,

This Issue affects both Items permed WITH Bulk Permission but more importantly it has affected items permed PRIOR TO Bulk Permissions
It is not contingent on which viewer you are using OR whether it has Bulk Perms or not.. which means it is more than JUST BULK PERMS aka Viewer issue, it is a SERVER issue

Yes using Bulk perms will cause this, but it is NOT the ROOT of the problem

to QUOTE Latif Khalifa added a comment - 19/Jul/09 11:09 AM @Nock - please refrain from changing the summary of the bug report without consulting OP Additionally, if you read the comments, you will find that people are experiencing the same issue with objects that were packaged before the introduction of bulk permissions. I have confirmed this myself. Its only that we now have a clear repro case that utilizes bulk permissions to show the problem.

I formally and urgently request comment/action plan from LL.

LL; in case you have not gotten the message yet - this is a money / legal issue! The very future of SL is at risk, along with your bank balance!

Talk to us!

Basically, using Bulk Permissions does not change any permissions unless you manually change the permissions first either in your inventory OR within the contents of the object. Therefore if you do nothing to the permissions before doing a Bulk Permissions change OR you change the permissions on a rezzed object prior to picking up and putting into the contents of a gift box and then using Bulk Permissions, the permissions will be incorrect.

For example, if you create an object but do not change the permissions (from the default NM/NC/T) prior to picking up and putting into the contents of a gift box, using Bulk Permissions to change it to something different (e.g. NM/C/NT) the resulting permissions on that object will not have changed (i.e. NM/NC/T) which is obviously incorrect!

Similarly if you have changed the permissions on an object to full (M/C/T) prior to picking up and putting into the contents of a gift box, again using Bulk Permissions to change it to something different (e.g. NM/C/NT) the resulting permissions on that object will still be full (M/C/T) which again is incorrect!

Notes: The permissions of the Gift Box does not make any difference to the results. Also changing the permissions manually after a Bulk Permissions change will fix the problem.

3 Examples on how to reproduce problem:-

Example 1 - Steps to Reproduce Problem (doing nothing to permissions):

1. Create a simple Gift Object
2. Do NOT change permissions of Gift Object (i.e. leave at default of NM/NC/T).
3. Pick up Gift Object.
4. Put into contents of a Gift Box.
5. Change Permissions of Gift Object to something different (NM/C/NT) using Bulk Permissions.
6. Take copy of Gift Box and send to ALT.
7. ALT rezzes and opens Gift Box to copy contents to Inventory.
8. ALT rezzes Gift Object.
9. ALT checks permissions of Gift Object and discovers than permissons are WRONG (i.e. NM/NC/T).

Example 2 - Steps to Reproduce Problem (changing rezzed perms to full):

1. Create a simple Gift Object.
2. Change rezzed permissions of Gift Object to Full (i.e. M/C/T).
3. Pick up Gift Object.
4. Put into contents of a Gift Box.
5. Change Permissions of Gift Object to something different (i.e. NM/C/NT) using Bulk Permissions.
6. Take copy of Gift Box and send to ALT.
7. ALT rezzes and opens Gift Box to copy contents to Inventory.
8. ALT rezzes Gift Object.
9. ALT checks permissions of Gift Object and discovers than permissons are WRONG (i.e. M/C/T).

Example 3 - Steps to Reproduce Problem (changing rezzed perms to copy only):

1. Create a simple Gift Object.
2. Change rezzed permissions of Gift Object to Copy Only (i.e. NM/C/NT).
3. Pick up Gift Object.
4. Put into contents of a Gift Box.
5. Change Permissions of Gift Object to something different (i.e. NM/NC/T) using Bulk Permissions.
6. Take copy of Gift Box and send to ALT.
7. ALT rezzes and opens Gift Box to copy contents to Inventory.
8. ALT rezzes Gift Object.
9. ALT checks permissions of Gift Object and discovers than permissons are WRONG (i.e. NM/C/NT).

Summary:

The most likely reason why people have noticed this problem more when sending to an Alt/Agent/Seller to sell onwards is probably because they are changing the transfer permissions on a rezzed object prior to putting into a Gift Box so the Alt/Agent/Seller can then sell or transfer that item. Most of us have learnt to change permissions on a rezzed object rather than within ones inventory which ironically is part of the cause to this problem.

Andrew Linden:
...the bit that instructs the simulator to apply next-owner-perms when the item is rezzed.

I think that would make sense given the reproduction steps. It would seem to me that any time you set the permissions while an object is in inventory, the "apply next-owner-perms" bit should be set. For example, if the object has a no-copy notecard in it but is set to copy after taken into inventory, the system should update permissions to no-copy when it is rezzed for both next and current owner. Right?

But in any case I think it is separate from the symptoms of this defect.

the correct way for the shop keeper is to rez "item for sale" on ground, right click and change the permissions while the object is being rezzed.
This is, because object permissions are stored in the asset itself.
Another dangerous assumption is that changing permissions on an object (with task inventory) also changes the permissions on the task inventory. This is not true. That's why Bulk Permissions was added.

So, when you activated the option "Debug Permissions" from Advanced, then whenever you change the object permissions while it is being inside inventory, you can see, how an asterisk is added to the N: permissions. This is a sign, that inventory permissions don't match the permissions as in the asset. Do not rely on the simulator to correctly apply permissions, as this has been broken and changed in the past, in a way that broke permissions on items as well, making them no modify for example when worn. The only safe steps that can be done with next owner permissions, while the object was taken to inventory is to give additional permissions, like making the object in agent inventory modifyable, when it contains items that are no modify.

As a conclusion, never take next owner permissions away on an object, when it's inside inventory.
Maybe to correctly fix this issue is to prevent the viewer to take away next owner permissions on objects, when they are inside inventory. Only allow to add next owner permissions to them. (This will force people to rez the object into world to change next owner permissions)
Well, one feature is that I'd like preserved. That is the adding permissions to full perm, after an object has been taken to inventory. Giving it to a seller, who then removes those additional permissions back to how they should be, without rezzing them in world.

Here's the correct procedure that I used to not allow objects being full permission:

• Make your product and set all permissions as you want them for the end user
• Take your product and box it (very important step here)
• perm the box for the end user while it's still rezzed
• take the box into inventory
• add next owner permissions to the box to make it fully permed inside your inventory
• give it to seller

The seller then does these easy steps:

• remove the additional next owner permissions from the box while still being in inventory
• never rez the box and never attach it
• put the box into a vendor or server

in this case, it doesn't matter if the permissions system messes up and makes the box prim itself full permissive. The product is set with correct permissions. Giving a box that contains no transfer inventory that was rezzed and taken (with permissions glitch) will be empty when someone else rezzes it.

The golden workaround rule:
ALWAYS SET PERMISSIONS ON THE GROUND.

The inventory permission bugs go back so long,... well let me put it this way..
https://jira.secondlife.com/browse/VWR-984
https://jira.secondlife.com/browse/VWR-6901
https://jira.secondlife.com/browse/VWR-8618

Etc.

The root of ALL of these problems is simply this. That thing in your inventory.. it's not the thing you rez. it's a "token".. or an "alias" or "shortcut".. it's a database entry, not an object. (not that the object is actually an object either.. but I digress) Think of it like a zip file. You can change the permissions on the zip file, but when you unzip it, the contents will have the original perms.

The fact is, that your inventory window can't "see" or "talk to" the object. When you change permissions on the inventory entry, that's all you're changing permissions on.. the entry. When you rez the object, it's going to revert to the permissions it had the last time it was rezzed.

Simple as that.

Ever seen one of those objects (we all have) where it's modable until you rez it.. then when you take it back, it shows as nomod. That's because the asset system has "talked to" the object again, and now knows it's correct permissions. (and the permissions of all of it's assets.) At that moment, the object becomes "stored" and the asset server can't see it anymore.. so it just refers to the permissions it had last time it was taken.

This Jira comes from the mistaken beleif that you can change permissions on an object without rezzing it. You can't.. and as long as I've been in SL, you haven't been able to. This is how so many of those wildfire "stolen objects" happen.. by a mistake in setting the inventory entry to full perms, or by some coding error that allowed that entry to become full perms.

Clothing, textures, sounds.. none of them can actually be rezzed.. only Objects.

This is an old bug, and it's hardly an emergency worth typing in all caps. The simplest solution would be for the client to "grey out" permission checkboxes on objects in inventory. Other, non rezzable assets do not have this problem.

You are both missing the point entirely. The issue is that if I set my permissions "ON THE GROUND" using the bulk permissions tool in 1.23 then the permissions are incorrectly set. The Bulk Permissions tool is broken and will not change the permissions properly. LL should send out a fix immediately removing this tool from the viewer.

This is an old bug, and it's hardly an emergency worth typing in all caps.

Then why did LL post this warning: http://status.secondlifegrid.net/2009/07/19/post696/

Bulk Permissions ONLY sets the task inventory permissions. It doesn't change the permissions of the prim itself. And okay, the bulk permissions seem to glitch on objects that are inside the task inventory. But that is setting permissions on objects that are INSIDE inventory then.

" * Create a new prim on the ground

• Renames it and calls it "Item for sale"
• Sets full next owner permissions
• Takes it into the inventory
• Sends it to Shop Owner
  "

At no point does the "Shop Owner" ever rez the object.

http://web.archive.org/web/20070113223510/http://secondlife.com/knowledgebase/article.php?id=336

Well, it can actually change the perms of the object itself as well if you select that option .. but you do have a valid point. )

My issue is that i have an object that autodies on rezz unless it receives the correct channel so its a pain in the neck to reset the perms. As well as that I send my objects to my colleague who does the final packing, so I make them full perms and then she reduces the perms to the final perms. If she does it with the Bulk Permissions tool it doesn't work. When the item is sent to an ALT it appears to be correct perms in inventory but on rez (in this case its an autorezing door) it reverts to full perms.

If she does it manually by selecting in prim inventory it works fine.

I edited my comment and added instructions on how to safely set permissions on items to sell by others.
the trick is to never have rezzed objects full permissive by themselves.

and the other trick with those instructions are, that you enforce the slam bit to be set on the boxes, so the boxes can be bulk permed back and still have the slam bit set.

1. full permissions prim - taken
2. given to avatar b
3. permissions changed in inventory (let's say no trans)
4. "no trans" prim sold to avatar c.
5. avatar c sees perms as "no trans"
6. avatar c rezzes
7. object reasserts it's stored (full) permissions.
8. avatar c takes "new" object, full permissions.

It's the same story again and again and again.. inventory permissions on objects, when changed in inventory, don't affect the objects when rezzed later. Place all the "put in box/take out of box" blinds in there that you want.

Thanks for that. I'll try that next time we have a major update of our product line. Will be a lot easier for her. Still, this Bulk Permissions tool needs to be ditched :S

You are confusing prim inventory and avatar inventory. Step 3 occurs on the prim inventory on an object rezed on the ground, not the avatar inventory.

Prior to this section, we had a full perms ball (product), inside a full perms cube (box).

Now onto preparation of the item that will be given to the customer:

• Rez "Boxed item for sale-full"
• Rename it to "Boxed item for sale"
• Right click and select edit
• On the edit window switch to content and press "Permissions" button
• Under content types select objects (or all, does not really matter) and under next owner permission turn off modify and transfer leaving only copy active
• Click on apply, you should see that Item for sale's permissions were modified. You can verify this by right clicking on the Item for sale in the contents of the object afterward and selecting Properties to see that it only has Copy active under the next owner permissions

Rez the full permissions box on the ground...
Go into the Box's INVENTORY
Change the permissions on the sphere IN THE BOX'S INVENTORY.

See what's happening? the sphere never gets rezzed. So the reporter is still changing permissions only on "aliases" of the object. That sphere may be inside a rezzed box.. but the "real" sphere's permissions can't be compared aganst the sphere's alias (in the box's inventory).. The asset server doesn't care whether the permissions are being changed in an avatar's inventory or in an object's contents. it's still just an asset token you're changing permissions on, not the "real" object.

so the same thing is happening here as in this example.

1. make sphere.
2. set it full perms
3. take it
4. set perms on sphere to no-mod.
5. give to friend
6. friend sees sphere is no-mod
7. friend rezzes sphere
8. friend sees that sphere is mod now.
9. friend takes sphere.
10. friend sees full permissions in inventory.

It works the other way too.

1. Make a complex object (a chrome sphere).
2 set permissions to no-transfer, no modify.
3. take sphere.
4. in inventory, set permissions to full.
5. give to friend.
6. Friend sees full permissions.
7. friend rezzes sphere
8. friend sees that sphere is now no transfer, no modify
9 friend takes sphere
10. friend complains that once he rezzed it it became nomod notrans.

Want to know something disturbing? Your friend can give that chrome prim away infinitely until it's rezzed.
This is why we ALWAYS SET PERMISSIONS ON THE GROUND.

The "Bulk permissions Tool" has just made this mistake easier to make.

To reiterate: you can not change permissions recursively on objects. Always rez the object on the ground, to change permissions. To do otherwise is to invite disaster.

My test showed that there is a difference between using the bulk setter vs the old "selectThemAllAndClickClickCtrlW" through all the assets method.
Using bulk perms setter: Any object asset type would revert to full perms when rezzed by a third party
(first party creates full perms, second party sets perms, third party tests)
Using normal ClickyClicky method : Any object asset type would show its intended perms even after being rezzed by a third party
In both cases the asset appears to have its intended perms until rezzed.

So there is a slight difference here, albeit it's still the same old "dont set perms on objects unless rezzed on ground" issue. The bulk perms setter does certainly seem to add a new level of 'broken' to the current situation, and an even more seriously large hole for the unwary to fall into.

Perhaps this jira should be closed to address a more specific jira on :
a) entirely removing the object type from bulk imbedded perms setting
b) making "next time it's rezzed!!!!" really aparent on the bulk perms setting for imbedded objects (after it's fixed, because right now its just broken) sorry for the edit Lex
c) making ANY AND ALL references to permissions setting to objects that arent rezzed on the ground SELF EXPLANATORY (not entirely easy, I know)

Or maybe this jira is right on the mark and we just want object assets to behave the same as anything unrezzable... if thats even possible?

This old bug/feature is useful in many ways, but its VERY difficult to know how to handle it even in legitimate and intentional situations. But is completely unintuitive to new users and the vast majority of SL creators.

test sequence

Second Life 1.24.4 (126103) Jul 7 2009 21:05:09 (Automated Trunk Build)
Built with MSVC version 1400
You are at 144581.0, 248357.0, 21.9 in Off The Wall located at sim8637.agni.lindenlab.com (216.82.39.196:13008)
Second Life Server 1.27.0.127440

rez new box on ground
set new box to full perms
name box "TEST-SVC-4444"

create new TEST folder in avatars inventory
create one new asset of every type (except object)
set full perms on each asset using old method

create new object on ground
set full perms
leave object named "Object"
take Object to avatar inventory and place in TEST folder

select all assets in TEST folder
drag all assets to "TEST-SVC-4444" object that is rezzed inworld
(note: did not hold ctrl, so script is active)

take "TEST-SVC-4444" to inventory

give "TEST-SVC-4444" to alt1

Second Life 1.23.4 (123523) Jun 9 2009 08:32:14 (Second Life Release Candidate)
Release Notes
You are at 144526.6, 248357.7, 21.1 in Off The Wall located at sim8637.agni.lindenlab.com (216.82.39.196:13008)
Second Life Server 1.27.0.127440

alt1 rezzes "TEST-SVC-4444" inworld (same simulator)
alt1 renames object to "TEST-SVC-4444 perms set using bulk setter"
alt1 sets perms of contents of "TEST-SVC-4444 perms set using bulk setter" to -mod/+COPY/-xfer using bulk setter
(swapped sequence of these two)
alt1 sets perms of "TEST-SVC-4444 perms set using bulk setter" to -mod/+COPY/-xfer
alt1 takes object "TEST-SVC-4444 perms set using bulk setter" to avatar inventory

alt1 rezzes "TEST-SVC-4444" inworld (same simulator)
alt1 sets perms of contents of "TEST-SVC-4444 perms set using select all and clickClickCtrlW" to -mod/+COPY/-xfer using select all, unclick(mod) unclick(xfer) CtrlW (repeat through all assets)
alt1 sets perms of "TEST-SVC-4444 perms set using select all and clickClickCtrlW" to -mod/+COPY/-xfer
alt1 renames object to "TEST-SVC-4444 perms set using select all and clickClickCtrlW"
alt1 takes object "TEST-SVC-4444 perms set using select all and clickClickCtrlW" to avatar inventory

alt1 gives both objects to alt2
"TEST-SVC-4444 perms set using bulk setter"
"TEST-SVC-4444 perms set using select all and clickClickCtrlW"

Second Life 1.23.4 (123523) Jun 9 2009 08:32:14 (Second Life Release Candidate)
Release Notes
You are at 144526.6, 248357.7, 21.1 in Off The Wall located at sim8637.agni.lindenlab.com (216.82.39.196:13008)
Second Life Server 1.27.0.127440

alt2 notes perms in avatar inventory (should be -mod/+COPY/-xfer on both)

• • • OBSERVATION ***
      assets are both -mod/+COPY/-xfer AS EXPECTED

alt2 rezzes both objects
"TEST-SVC-4444 perms set using bulk setter"
"TEST-SVC-4444 perms set using select all and clickClickCtrlW"
and notes object's internal contents perms (should be -mod/+COPY/-xfer on both)

• • • OBSERVATION ***
      assets are all -mod/+COPY/-xfer AS EXPECTED

alt2 takes asset "Object" from
"TEST-SVC-4444 perms set using bulk setter"
to avatar inventory and notes perms (should be -mod/+COPY/-xfer)

• • • OBSERVATION ***
      asset is -mod/+COPY/-xfer AS EXPECTED

alt2 rezzes asset "Object" from avatar inventory to ground (same simulator) and notes perms (should be -mod/+COPY/-xfer)

• • • OBSERVATION ***
      asset is +MOD/+COPY/+XFER [edit: /me slaps himself really hard on Lex's, and everyones, behalf]
      NOT AS EXPECTED <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

alt2 takes asset "Object" from
"TEST-SVC-4444 perms set using select all and clickClickCtrlW"
to avatar inventory and notes perms (should be -mod/+COPY/-xfer)

• • • OBSERVATION ***
      asset is -mod/+COPY/-xfer AS EXPECTED

alt2 rezzes asset "Object" from avatar inventory to ground (same simulator) and notes perms (should be -mod/+COPY/-xfer)

• • • OBSERVATION ***
      asset is -mod/+COPY/-xfer AS EXPECTED

If you edit permissions of an object IN, that is inside a rezzed object REZ, you're still changing the permissions of object IN inside inventory (task inventory). You'd have to take object IN out of the object REZ and turn it into rezzed state by rezzing it into world alive to work on it's permissions.

Editing permissions of objects in world applies only to life objects. Objects that are not contained but actually rezzed in world.

Maygray Heron added a comment - 17/Jul/09 10:36 PM - edited
I can reproduce this on 1.27 sims with only one avatar using following steps:

1. Rez two boxes, one named "Inner", the other one "Outer" (just for identification purposes)
2. Give full permissions to the "Inner" Box.
3. Take the "Inner" Box and put into the "Outer" Box.
4. Edit the "Outer" Box and use the Bulk permission feature to make everything within the "Outer" Box Transfer only.
5. Review the permissions of the "Inner" Box within the "Outer" Box by rightclicking and choose Properties, it will show as Transfer only.
6. Rez the "Inner" Box directly out of the "Outer" Box (or open the "Outer" Box to get it contents)
7. Review the permissions of the newly rezzed "Inner" Box. It will have all permissions.

Again if you manually change the "inner" box to Transfer only instead of using the bulk permissions feature it does not reproduce.

1. Rez two boxes, one named "Inner", the other one "Outer" (just for identification purposes)
2. Give full permissions to the "Inner" Box.
3. Take the "Inner" Box and put into the "Outer" Box.
4. Edit the "Outer" Box and use the Bulk permission feature to make everything within the "Outer" Box Transfer only.
5. Review the permissions of the "Inner" Box within the "Outer" Box by rightclicking and choose Properties, it will show as Transfer only.
6. Rez the "Inner" Box directly out of the "Outer" Box (or open the "Outer" Box to get it contents)
7. Review the permissions of the newly rezzed "Inner" Box. It will have all permissions.

Okay, so in this example.. "inner" (let's say it's a sphere).. is made full permissions.
Then taken
Then placed inside "outer" (let's say it's a box).
Then the bulk permissions tool is used, to try and change the permissions on "Inner".. WITHOUT REZZING IT
The permission appears to be changed, in inventory...
but when rezzed it's back to full permissions.

Even the examples you hold up keep reiterating the main problem I'm pointing out again and again and again.

The Sphere.. and the thing that says "Sphere" inside the Box's contents, aren't the same things. It's just a token, an alias, a pointer, a shortcut.. it's not the "real thing". You can't change the permissions on the token and expect it to change the permissions on the object when it's rezzed later. The Permissions system simply doesn't work that way.

To quote aric linden in his response to VWR-6901,

This is as designed. We could change it but it would necessitate a re-write of the entire permissions system. We're not ready to undertake that right now.

I think Harleen is right about the slam bit, since any other inventory items that are not objects seem to work anyway.

From what I understand the bug only applies to objects "prims" (not to clothing layers)
people shall not use bulk- or inventory permission settings nor change permission when it is attached to the avatar!

If I got that right then this isn't a bug... prims were behaving this way for at least 2 years.
What they should do is write a note underneath the bulk permission button that informs creators that this won't change prim objects or grey out prim objects when the bulk permission button was pressed and highlight those that has been actually changed.

You can't change prim objects inside your inventory!

ps the inside of a box is considered inventory since it is not actually rezzed in world!

Just to clarify, as this isn't clear either in your comments or the Knowledge Base FAQ's regarding permissions...

Does "wearing" an object count as "rezzing in world"?

For example, I make jewellery. If I set permission on a ring in inventory, then wear the ring, does that set those permissions on it?

This can and should be fixed on the viewer side. Bulk Permissions should set the slam bit on objects, whenever it'd change the permissions.

Explanation why already broken boxes can't be fixed server side:
rezzing an object can't ignore the slam bit (which would be neccessary to enforce permissions of so broken inventory) as it'd cause a bug that happened a while ago where objects turned no modify for apparently no reason. It's deep in the design of the permissions system for objects.

The sad conclusion is, fixing this mess is left to merchants. Only they can check their vendors/servers using an alt account to verify permissions and repairing whatever is broken.

A clear understanding of how permissions really work could maybe help and it could have prevented this. What the slam bit is, how it affects perms on objects. What task inventory is and how permissions affect that. What configurations allow people to have unlimited copies of no copy items. Why it's bad to design content with both restrictions together no copy, no transfer.
I think it's time to give easy step by step instructions to use cases and spreading these amongst all content creators. Knowledge base wiki maybe?

This does suggest that changing permissions within an objects inventory does work but just not with the Bulk Permissions feature without the added manual step.

This also suggests that the bug here is that Bulk Permissions is not setting the slam bit (as mentioned by Harleen) and therefore if Linden Labs is actually still looking at this Jira (a comment from a Linden would be nice) they should now know the problem and be able to fix it easily unless the code is so badly designed (which it could be of course - lol) this can't be fixed.

@Winter - whilst I agree with you that the thing which says "Sphere" inside the Box's contents is just a token/alias/pointer, you are suggesting that there is no way you can change the permission on that token and expect it to change the permissions on the object when it's rezzed later.

This suggestion just makes me ask:

1. Why is there the ability to manually change the object within the contents of another (outer) object unless LL has code to make this happen?

2. Why add a Bulk Permissions feature if there is no way this should work due to the current design (ignore the fact that this feature is a broken implementation at the moment). I don't think LL added this feature just for the fun of it

3. Why can I change the permissions of an object manually (within an objects inventory) to something and then use Bulk Permissions to change it to something else and have it work correctly?

4. How does one rezz a script or notecard? I am sure that they are just tokens as well and the only way you can change the permissions on those are within the inventory and not through rezzing. Granted object work differently but code can be added (and probably has) to allow for the difference.

Taking Maygray's repro (I hope you don't mind me copy/pasting and editing your repro Maygray) and adding an extra step to manually set the permissions prior to using Bulk Permissions supports the slam bit theory:

1. Rez two boxes, one named "Inner", the other one "Outer" (just for identification purposes)
2. Give full permissions to the "Inner" Box.
3. Take the "Inner" Box and put into the "Outer" Box.
4. Edit the "Outer" Box and give Copy Only permissions manually (don't use the Bulk permission feature) to the "Inner" Box within the "Outer" Box.
5. Still editing the "Outer" Box, use the Bulk permission feature to make everything within the "Outer" Box Transfer only.
6. Review the permissions of the "Inner" Box within the "Outer" Box by right clicking and choose Properties, it will show as Transfer only.
7. Rez the "Inner" Box directly out of the "Outer" Box (or open the "Outer" Box to get it contents)
8. Review the permissions of the newly rezzed "Inner" Box. It will have the correct Transfer only permissions.

The Bulk Permissions feature bug should be able to be fixed otherwise LL should disable it completely if a fix can't be found quickly or if at all.

In fact i did tested it with a script created within a box, running bulk permissions over it, copying the script into avatar-inventory and back into a new box. That at least seems to work, however i did not yet tested it by handing the box over to another avatar yet.

This can and should be fixed on the viewer side. Bulk Permissions should set the slam bit on objects, whenever it'd change the permissions.
/quote

concur the slam bit issue needs to be addressed.

Slam bit predates me by a long time and I never understood what the purpose of the slam bit is.
The way it works in reality in world leads me to believe:

a: content subject to slam bit should not be allowed to have permissions set at all unless rezzed in world
or
b: Setting a permission anywhere on anything "slams the slam bit". (preferred resolution)

This would eliminate a lot of accidental content (and subsequently revenue and trickle up tier) loss.

But I do not know why the slam bit exists in the first place.

Basically the user intuition is that given a method to set permissions anywhere it is assumed to be safe to do so and not result in catastrophic losses simply because the creator was not magically blessed with the nearly undocumented fact that setting permissions on objects needs to be done only when rezzed on ground in world. There is nothing about this anywhere unless one digs for it. That situation is not admirable at all.

no, you set the permissions of the ring while it was not rezzed and being in inventory
to set the perms correctly have it rezzed in world, then set the next owner permissions (which doesn't work while it's attached)

in this order:
1. rez the object, set the permissions as you want the end-user to have them
2. take the object, (only) add permissions you want to additionally give

the only permissions practical to add for an end user is modify (if you intend to allow modifications of the prims)
if the object taken has neither copy nor transfer enabled for next owner permissions, then something in the inventory of the object itself is contradicting and can cause effects like giving someone unlimited numbers of no copy items. So repeat from step 1. Rez it again and check permissions of all prim/task inventory.

So I guess what this comes down to is:
1) we like the features offered by BOTH slam and regular, and it's basically essential to being able to transfer things through relatively untrusted second and third parties with whom we do business.
BUT to prevent the usual bi-annual angry mobs that are usually ready to kill over these issues:
2) interface needs to clearly show users what they are setting, and difference between slam and regular perms methods
3) documentation needs to tabulate what perms and set methods result in what outcomes to first, second and further owners...this needs to be reflected in, or easily linked to 2)

also: another test case written for my own edification:
START 'OLD' PROCESS TEST
avatar1
avatar1 creates object and name: "TRANSFERPACK-Mod/Copy inside" (default NoMod/NoCopy/Transfer is correct)
avatar1 creates object and name: "PRODUCT-Mod/Copy object"
avatar1 sets permissions Modify/Copy/NOTransfer on "PRODUCT-Mod/Copy object"
avatar1 takes "PRODUCT-Mod/Copy object" to avatar1 inventory
avatar1 drags "PRODUCT-Mod/Copy object" from avatar1 inventory to contents of object called: "TRANSFERPACK-Mod/Copy inside"
<<<<<<<<<<<<<<<<<<<<<< process differs here <<<<<<<<<<<<<<<<<<<<<<
avatar1 right clicks on "PRODUCT-Mod/Copy object" in contents tab of object: "TRANSFERPACK-Mod/Copy inside"
select "Properties"
<<<<<<<<<<<<<<<<<<<<<< process differs here <<<<<<<<<<<<<<<<<<<<<<
and set permissions: NoMod/NoCopy/Transfer
avatar1 takes "TRANSFERPACK-Mod/Copy inside" to avatar1 inventory
avatar1 gives "TRANSFERPACK-Mod/Copy inside" to avatar2

avatar2
avatar2 notes apparent perms of "TRANSFERPACK-Mod/Copy inside" in avatar2 inventory
*NoCopy/NOModify/Transfer *
avatar2 rezzes "TRANSFERPACK-Mod/Copy inside"
avatar2 notes perms of "PRODUCT-Mod/Copy object" in contents tab of "TRANSFERPACK-Mod/Copy inside"
*NoCopy/NOModify/Transfer *
avatar2 takes "PRODUCT-Mod/Copy object" to inventory
avatar2 notes "PRODUCT-Mod/Copy object" perms in avatar2 inventory
*NoCopy/NOModify/Transfer *
avatar2 rezzes "PRODUCT-Mod/Copy object" to ground
avatar2 notes "PRODUCT-Mod/Copy object" perms on ground
*NoCopy/NOModify/Transfer * <<<<<<<<<<<<<<<<<<<<<< outcome differs here <<<<<<<<<<<<<<<<<<<<<<
END 'OLD' PROCESS TEST

START 'BULK' PROCESS TEST
avatar1
avatar1 creates object and name: "BULK TRANSFERPACK-Mod/Copy inside" (default NoMod/NoCopy/Transfer is correct)
avatar1 creates object and name: "BULK PRODUCT-Mod/Copy object"
avatar1 sets permissions Modify/Copy/NOTransfer on "BULK PRODUCT-Mod/Copy object"
avatar1 takes "BULK PRODUCT-Mod/Copy object" to avatar1 inventory
avatar1 drags "BULK PRODUCT-Mod/Copy object" from avatar1 inventory to contents of object called: "BULK TRANSFERPACK-Mod/Copy inside"
<<<<<<<<<<<<<<<<<<<<<< process differs here <<<<<<<<<<<<<<<<<<<<<<
avatar1 clicks the "Permissions..." button in contents tab of object: "BULK TRANSFERPACK-Mod/Copy inside"
<<<<<<<<<<<<<<<<<<<<<< process differs here <<<<<<<<<<<<<<<<<<<<<<
and set permissions: NoMod/NoCopy/Transfer
avatar1 takes "BULK TRANSFERPACK-Mod/Copy inside" to avatar1 inventory
avatar1 gives "BULK TRANSFERPACK-Mod/Copy inside" to avatar2

avatar2
avatar2 notes apparent perms of "BULK TRANSFERPACK-Mod/Copy inside" in avatar2 inventory
*NoCopy/NOModify/Transfer *
avatar2 rezzes "BULK TRANSFERPACK-Mod/Copy inside"
avatar2 notes perms of "BULK PRODUCT-Mod/Copy object" in contents tab of "BULK TRANSFERPACK-Mod/Copy inside"
*NoCopy/NOModify/Transfer *
avatar2 takes "BULK PRODUCT-Mod/Copy object" to inventory
avatar2 notes "BULK PRODUCT-Mod/Copy object" perms in avatar2 inventory
*NoCopy/NOModify/Transfer *
avatar2 rezzes "BULK PRODUCT-Mod/Copy object" to ground
avatar2 notes "BULK PRODUCT-Mod/Copy object" perms on ground
*Copy/Modify/NoTransfer * <<<<<<<<<<<<<<<<<<<<<< outcome differs here <<<<<<<<<<<<<<<<<<<<<<
END 'BULK' PROCESS TEST

The slam bit exists to differ between intended permissions changing and the mere representation of combined permissions.

One example is an avatar part. Let's say a furry head with a no modify eye blink script inside

The creator made the head, but wants it to be modifyable. After taking the head to inventory they set the permissions to modify/copy/no transfer. This also sets the slam bit.

After the object being sold to the end user, they see the head as modify/copy/no transfer in their inventory. They can rename the head to their likings. They can rez the head and modify prims. But the script itself stays no modify/copy/no transfer.

The moment they take the head back into their inventory will make the sim to calculate the combined permissions for the inventory, which will be the least permissions given by all base permissions and owner permissions. As the script has the least permissions, the head will now show as no modify/copy/no transfer, but it won't have the slam bit set any more.

If this new head is rezzed to world, it will not be set no modify, because the slam bit is not set. (There was a bug server side once, which ignored the slam bit and rendered many items for people to be no modify)

One important thing to note: The slam bit only applies to the prims of the object. It doesn't change nor force any permissions of items (and objects) that are inside those prims.

Winter Ventura added a comment - 20/Jul/09 01:29 AM - edited
@Harleen... just consider that you might not be correct here.

1. Rez two boxes, one named "Inner", the other one "Outer" (just for identification purposes)
2. Give full permissions to the "Inner" Box.
3. Take the "Inner" Box and put into the "Outer" Box.
4. Edit the "Outer" Box and use the Bulk permission feature to make everything within the "Outer" Box Transfer only.
5. Review the permissions of the "Inner" Box within the "Outer" Box by rightclicking and choose Properties, it will show as Transfer only.
6. Rez the "Inner" Box directly out of the "Outer" Box (or open the "Outer" Box to get it contents)
7. Review the permissions of the newly rezzed "Inner" Box. It will have all permissions.

Okay, so in this example.. "inner" (let's say it's a sphere).. is made full permissions.
Then taken
Then placed inside "outer" (let's say it's a box).
Then the bulk permissions tool is used, to try and change the permissions on "Inner".. WITHOUT REZZING IT
The permission appears to be changed, in inventory...
but when rezzed it's back to full permissions.

Even the examples you hold up keep reiterating the main problem I'm pointing out again and again and again.

The Sphere.. and the thing that says "Sphere" inside the Box's contents, aren't the same things. It's just a token, an alias, a pointer, a shortcut.. it's not the "real thing". You can't change the permissions on the token and expect it to change the permissions on the object when it's rezzed later. The Permissions system simply doesn't work that way.

To quote aric linden in his response to VWR-6901,

This is as designed. We could change it but it would necessitate a re-write of the entire permissions system. We're not ready to undertake that right now.

Again the issue is if in the example above you manually changed the permissions of your sphere, the permissions would be correct, they are only wrong when bulk permissions is used. So if you are correct then why does it work when not using bulk permissions?

• 2. Give full permissions to the "Inner" Box.

setting the item to full permissions in world is making it full permissive to everyone you giving it to, as permissions are stored inside the object asset itself. There's a slam bit, but it's a mere workaround for the inability to change assets. Assets cannot be changed by design. If you don't want people to have primwork full permissive, don't set the next owner permissions of rezzed objects full permissive.

The permission system has worked like this as long as I've been in SL. Rez that item and take it back, and watch it become magically full perms.

Care to meet me on the beta grid to try it?

I guess its difficult to understand what I am saying, so here are the reproduce step.

• "Creator" creates the cube on the ground, makes it fully permissive and calls it "Item for sale"
• "Creator" then takes "Item for sale" into his inventory and sends it to "Packager"
• "Packager" creates a new box on the ground, makes it fully permissive, and renames it to ""Boxed item for sale"
• "Packager" then drops "Item for sale" that he got from "Creator" into "Boxed item for sale"'s contents
• "Packager" changes permissions of "Item for sale" inside "Boxed item for sale's" contents (task inventory) by right clicking on it, selecting properties, and making next owner permission to No mod/Copy/No transfer
• Packager" takes "Boxed item for sale" back into his inventory

• "Packager" gives "Boxed item for sale" to "Customer"
• "Customer" unpacks it, and rezzes "Item for sale"
• Rezzed "Item for sale" is No mod/Copy/No transfer to them, so all is well

Now the funky bit:

• "Packager" gives "Boxed item for sale" to "Creator"
• "Creator" opens it and rezzes "Item for sale"
• "Creator" observes that he now has full permissions on "Item for sale" on the ground even though it shows No mod/Copy/No transfer in his inventory. "Creator" also observes that next owner permissions of the rezzed "Item for sale" are marked as No mod/Copy/No transfer.
• "Creator" takes rezzed "Item for sale" into his inventory where it now shows full permissions in there as well

Why would permissions be different based on creator is beyond me.

Here is a simple repro to see the issue:

1. Create a prim box
2. Create two sphere prims, make both full perms, call one "Sphere Bulk", call the other "Sphere Manual"
3. Take both spheres into inventory
4. Edit the box, place "Sphere Bulk" in the contents only
5. Click on the Permissions button and bulk change the permissions to No mod/No Copy/Transfer
6. place Sphere Manual into the box
7. Right-click on "Sphere Manual" and choose properties, change the permissions to No mod/No Copy/Transfer
8. Set box for sale copy
9. Have another avatar buy a copy of the box
10. Buying avatar rezzes box on the ground, opens box, and copies conts into inventory
11. Buying avatar sees both spheres as No mod/No copy/Transfer in their inventory
12. Buying avatar rezzes both spheres
13. "Sphere Bulk" is rezzed as full perms
14. "Sphere Manual" is rezzed as No mod/No copy/Transfer

I welcome anyone who wishes to test this with me, to contact me inworld.

The answer is simple. When transferring an object, the task inventory doesn't get transferred until the object is finally rezzed.

Example: The creator boxes up something and gives the box to someone else, then he gets the box back.

What happens:
the box contents are still owned by the creator, even that the box itself is now in someone else's inventory. If this person would rez the box, the ownership of the object would immediately change and next owner permissions applied, on that copy in-world. If a copy stays in inventory, that one will not change. If you give that item back to the creator (or the person who owned the task inventory), then when they are rezzing that box, the ownership on the task inventory won't change and next owner permissions won't be applied. (And the slam bits should not take effect either as the ownership stored in the asset is the same as the person rezzing it)

If you read my repro steps you will see that Creator never packages object. He just creates a prim, makes it full perm, and sends it to Packager. No object contents are being transfer there, just plain old default cube without any contents.

1. create object with default transfer permission only = no mod, no copy, transfer.
2. in edit mode under general tab, change permission ( for next owner, of course ) of if to fully permissive = mod, copy, transfer and change name , for example: A
3. take object A to your inventory
4. create next object and analogically set it to fully permissive = mod, copy, transfer and change name, for example: B
5. edit object B under content tab, drag object A to content of object B

Let's make short resume, now: Actually we have two objects: A and B, both set as fully permissive ( for next owner) = mod, copy, transfer.
Object B is rezzed in world, and object A is contained in content of object A ( object A is not rezzed in world, as we can see, please pay attention now !!!)

6. under edit mode of object B, in content of B, please change permission for next owner of object A to only copy = no mod, copy, no transfer.
Please do that in two ways ( you will see same = identical results in a moment):
a) set permissions manually for next owner at bottom of general tab in edit mode
b) use bulk system through pressing button: Permission and setting permissions then

Actually we have two objects: B ( rezzed in world) = mod, copy, transfer for next owner
A ( contained in content of B = not rezzed in world !!! ) = no mod, copy, no transfer for next owner

7. take object B to your inventory and pass it = give it, etc,, to your friend, to your alt, = to another avatar(resident)
8. Now, when that second person recieves object B, she/he can see permissions of it in inventory ( for her / him ) = no mod, copy, no transfer.
Let's notice, now, that is proper behaviouring. Permissions of B ( in inventory ) are determined by permissions of A. All is still ok.
9 Second person rezzes object B in world, nowl she / he can notice, under edit mode in general tab, that permissions of B are =
= mod, copy, transfer ( transfer permission of B is little greyed, it is caused that A is no transfer, that is ok)
and when she / he opens content tab of B under edit mode, still she / he can observe in properties of object A that permissions ( for her / him )
of A are = no mod, copy, no transfer, that is still ok.
10. Now that second person copies content of object B = creates folder in her / his inventory with name=B, folder includes object A.
Or simply drags object A form content of object B to her / his inventory. Since now, we will not be interested in B.
11. In her / his inventory, second person can see still proper permissions of object A= no mod, copy, no transfer
12. Now she / he drags object A on ground = rezzing of object A in world!!! And !!!
She / he can notice that object A ( rezzed in world) is fully permisive = mod, copy, transfer!!! LOL. Personally, i do not know if i need to laugh or cry,
it depends on who would be second person.Ufff ( little hard work with this entire process with A and B .. )
Now, when second person will take object A to inventory, she / he will see that it is fully permissive = mod, copy, transfer for her / him and
for next owner too.

What i noticed, if first person ( creator of objects A and B) would change permission of object A in world = rezzed on ground!! ( not in content of B !!! )
all would have been ok.Please do such process, you will all see that all will be ok with permission of A.

Resume:

Changing of permissions of object depends on if it is rezzed in world or it is contained in content of some other object.
As we all can see now, whole = entire process of setting proper permission in SL, is complicated. It shows many situations that we can do some very serious mistakes. I will not introduce now, but i am certain that majority of you, knows that changing permissions directly in inventory of object ( not rezzed ) has curious behaviouing too!!!
It cant be like that resident needs to remember if object is rezzed , or is included in some other object, or it is only in inventory and all those situations may cause different settings of permissions. It is very uncomfortable. Personally i do not belive in miracles, some hackers etc...
95% of mistakes in permission system is caused by residents, but now we can see that 5% can appear too!!
We can't rely on bad system!! how may we believe that our creations will have proper permissions or not , if it is not dependent of us, that is crazy!!

Suggestion: Please ever, always and forever, set proper permissions of object, only if it is rezzed on ground=in world !!!
Never if it is in your inventory or it is in content of some rezzed other object!!!

I consider that we must and should require signifcanly more attention for such problems like setings of permissions from Linden Lab!!!
That is pinciple thing!!!!!

Best Regards to All Eugene Thiebaud

As people learn about this, they are assuming their items are safe if they did not use Bulk Permissions, which is not the case !
Many people have reported this happening to items permed without the viewer option. Many who do not use the viewer that has the bulk perms option also have had issues with permissions changing.... randomly.

I had it appear on object (prims) that had been permmed in world, prior to bulk perms as did others, which is the major issue at hand.

Please make sure others are aware this is not a viewer issue related to the bulk perm option, which only reproduces the initial bug. It has affected prior items made and is basically a prior breach in the perms system which others may have already taken advantage of. This broadens the timeline for which items could have first been affected back to the introduction of 1.26 in April , and effects items made prior to that release.

I will add my screenshot to demonstrate it appearing on an item PRIOR to Bulk Permissions ..

it's still the same, if the object asset has you stored as the current owner, the inventory permissions (no matter if slam bits are set or not) are not applied.

The object asset is the representation of the prims structure, flags, task inventory aso. in a file stored on the asset servers. It contains creator, permissions and owners for every single prim of the linkset. Your inventory also stores the creator, owner and permissions as well as some flags incl. the slam bits (where there are more than just next owner, there are group and everyone slam bits as well).
Only if the inventory metadata and the object asset disagree on who's the owner, the slam bits and next owner permissions are applied.

i have looked at this when i got a notecard in world, and it is my opinion that the bug is, in fact, user error. and yes, i am guilty of making this error too.

as we all know by now, in-world permissions are totally different from in-box/in-inventory permissions. you've all probably seen that you set some permissions in-world, take an item into your inventory, then right click, properties, and see THOSE permissions are different, and need to be changed to match the in-world permissions.

note that this is separate from 'folded' permissions, where contents of an object affect whether it is listed in-inventory as no-copy, etc.

notice what the 'shopkeeper' in the repro example is doing:

1. Create a new prim on the ground
2. Rename the prim to "Boxed item for sale-full"
3. Set next owner permissions to all
4. Drag "Item for sale" received from Content Creator into this object's contents

note that AT NO TIME did the shop keeper rez the items in-world. therefore, the in-world permissions were never changed. ONLY the in-box/in-inventory permissions were touched. when the object is rezzed in the world by the "customer," yes, it will have its in-world permissions. again, in the example, these were never changed from full permissions.

its a pain in the butt, but actually in sl's crazy kind of way, it DOES make sense.

if anyone can show an instance of an object NOT set to full perms in-world, and then later reverting to full perms in-world (whether rezzed from a box or from inventory), please do so. i have not seen an instance of this in my work.

the instances i have found of in-world perms being full in my boxed items were traced to me using the bulk permissions tool (in cool viewer) to change the in-box permissions of items and i forgot to set the in-world permissions on those items. dopey me, i thought the cool bulk permissions feature would do the in-world perms too. that was wrong. but it is still only user error.

This screenshot would be more helpful if you had "Debug Permissions" activated during making them. As it'd show the slam bits, if they were set. Which I assume they were not set.

1. Harleen's example works precisely as she describes.
2. The boxed item in my example still rezzes full perms for my alt. I used 3 accounts in my test
3. I wasn't using View Admin Options while editing.

I'm trying to backwards examine what i did to create it.. to see where the bug is hiding. What I can say is this:

• The box was made of mixed creators prims. (Using some prims from the full perms object.)
• The box's permissions were set separately from the contents
• I'm finding that the results don't yet reproduce.

Yes that's right.. there's a piece of information I'm missing in my own reproduction. I didn't do a lot of renaming in my test, but the results in the image really are the results I reached. And they were the results I expected to reach.

I didn't expect to find different results... but I'm seeing now a repeating pattern of the final object becomming permed "properly" (as INTENDED) for avatar C (as Harleen suggests).

Clearly there's some inconsistency, and to be honest, I'm getting really tired. I think some of you have seen what happens in my cartoon, happening in SL.. It's clearly not 100% reproducable with the information provided. I wish it was airtight, but it's not.

What I keep coming back to, however, is my packaging mantra.
ALWAYS SET OBJECT PERMISSIONS ON THE GROUND

Regardless of what all is or is not able to trigger what clearly happened in my cartoon (I didn't use the bulk permissions tool for that).. or even what's happening with the bulk permissions tool.. it's clear that Objects are funny items and mucking around with their permissions without rezzing them isn't reliable.

And in SL business.. unreliable, is unacceptable. Especially when the workaround is so simple and reliable.

I hope at least that my comments and example will set some people on the track of finding this unexpectedly inconsistent issue. I was sure it was simpler and more reproducable than this. I clearly stepped in just the right way to trigger it during my demo.. I wish I'd taken better notes.

http://status.secondlifegrid.net/2009/07/19/post696/

(quote)
Permissions Issue

[9:30pm PDT] We are aware of potential problems with Bulk Permissions as documented in https://jira.secondlife.com/browse/SVC-4444. We are investigating. We recommend that creators and merchants avoid using the Bulk Permissions feature until further notice. More details will be available when we have them.

If you take objects to inventory while they're set to full permissive in world, you don't need to wonder that the end user can have those items full permissive, too. Better not rely on the slam bit here.

I agree with Bloodsong that this is a user error. But no one told them about, how permissions work, yet. The permissions system is unintuitive and opaque. It's too easy to make it behave unexpectedly.

Suggestions to fix this on the viewer side without changing any of the design and behaviour:

• Make the slam bits more visible to the user interface, allow setting next owner permissions without modifying slam bits.
• Warn the user when they are placing additional permissions on an object, that represents itself as non-permissive about implications that no copy items in copyable objects can cause.
• Document the permissions system thouroughly including when happens what and where the quirks are with object assets.

Never do I perm items in the box or inventory once they are made. Firstly because, I cannot as various contents of that particular loveseat are no copy, no mod, trans. (Animations, Scripts and notecards)

I have myself & 1 or 2 others check all permission outside and inside any item I make, while it is in world. This was one instance of what myself and OTHERS have found.

If Linden Labs takes the feature out again and says "Whoops, we didn't realise that you can't change permissions within the inventory of an object" then fair enough but until they do that then this is a bug with the way permissions work.

To put it another way if you have an application that allows you to save a file (through File | Save) and every time someone saves a file it doesn't get saved, is that a bug or user error because they they are selecting File | Save?

Having a feature which isn't supposed to t work just leads to confusion.

As per our chat on IRC, i totally agree that this is the root cause of the issue with the bulk permission settings

Reading the comments in llfloaterproperties.cpp:-

// If next owner permissions have changed (and this is an object)
// then set the slam permissions flag so that they are applied on rez.

etc...
this was missing in the original code in llfloaterbulkpermissions.cpp

so on rez the asset servers version of the permissions (eg what it was when the inventory was taken to inventory) were not being updated to the inventory servers version (eg what the bulk permissions applied) because that only happens on rez with slam bits set

I passed the item that had these in, to a friend and she removed them and passed them back to me , to see if we noticed any changes... Only greyed perms remained and the object with the notecards in , showed as no trans in her inventory.

This is not even a bug this is as designed ans long my avatar exists this behavior exists. Choose to ignore it and come up with explanation nobody can follow, the rule is simple and always was.

.. permissions changes of prims only when it is rezzed on the ground!

it's just coming to light now because of the bulk permission thingie

Don't change permission in your inventory
Don't change permission while they are attached

rez the prim or the linked prims on the ground, apply the permission and take it back to your inventory and the permissions will stay for good

this is not a server relevant issue, this is common sense since prim or linked prims are just a token in your inventory and not the actual master item!

To point out where the problem lies:

1. Rez two boxes, one named "Inner", the other one "Outer" (just for identification purposes)
2. Give full permissions to the "Inner" Box.
3. Take the "Inner" Box and put into the "Outer" Box.

These steps are, where the "Inner" Box is set full permissive. This is the "user error" that caused the third person to have a full permissive item.

Now I look back to Torley's recent blog post hailing the bulk permissions thing as a "time saver" and laugh. Yep, all the time I saved can now be used setting my permissions the right way. :>( Gee, thanks a bunch. How come THIS didn't end up as a useful video tutorial!?

@Torley: not to be taken personally, I'm just sayin'.

Please take the time to actually READ everything before coming off with assumptions. Mostly every person here has been in business in SL for the last 2-5 years, none of them are stupid, and most are aware how to correctly perm items.
Look behind the curtain of the bulk perms...

Otherwise, there would not be as much attention to this if it was isolated to only human error. There is no way for me to perm any of my items in a box or in my inventory because my scripts are given to me by my scripter as no mod and set to no copy before i even put them into the base item. I must perm the finished item (prims) in world. THEN pick it up..and put it in a box.

Skimming over these posts will lead to incorrect assumptions, as we have seen. Please slow down, take your time & need to feel right, and ...read.

Having said that, I have never assumed that bulk permissions will change my prim objects, a prim in a box is not a rezzed item it is just another database entry in the asset server.
You can argue that it should change it's permission to me it is common sense that it won't.... if they wanna "fix" that I am happily using it in the future!

However nothing is wrong with the basics i have listed above, as long as you rez your items on the ground and change the permissions from there you have nothing to worry about and since many people can't follow any of the above because they are no techies I'd say this is useful information's for those that want to fix it their items NOW.

The more convenient they make the permission settings the better, however the behavior of prim permissions hasn't changed a bit, it just came to light now that inventory changes are not effective! I say it again a prim inside the content folder of a box equals an item inside the inventory (behavior wise) If they wanna change that ..YAY..

Let's remind now, what reason had been that bulk permission system was applied. Many people complained that changing permissions in content of object ( prim or linkset ) is quitely hard work ( long time ), especially if we have many items in object:Scripts, animations, objects, textures, etc...

We had been so glad when we noticed that Linden Lab has applied bulk permission system. Aim of that was so clear, it had to improve speed of setting permissions. There was no doubt in it. But nearly no one noticed that bulk system would not work properly with setting of object permission, because all action-operation takes place in content of object, so it is useless in actual model. Certainly all items like: animations, scripts, sounds, gestures, textures etc, all what is not rezzed in world work properly with bulk permission system. Only one thing has problem: OBJECT!!!

Now i little smile, because i suppose that during trials, various testings, etc, within all procedures of inputting new bulk system no one from LL checked correctly entire new thing. It seems like they made few objects with different items inside ( in content of prims) , they passed them to themselves, opened folders in their inventories and they saw: all is ok, because in inventory permissions are seen properly, due to earlier settings, BUT no one from them rezzed objects, and no one from them saw that after rezzing, we have problem!!! For me it is human error, issue, improper application of new bulk system.

Very easy solution would be that LL could remove from bulk system one problematic thing:objects. All other works ok.
And next step, they need to construct new idea: how to clearly and safely set object permissions through bulk system.
We need clear, safe , understandable model of setting permissions in SL, to avoid such troubles in future.
Now we loose time, because it is so principal and basic thing like permissions, that it shoud have been set years ago!!!! SL is 6 years old! Not one month, that we need to think about such fundamental things like permissions.

Now, do not make panic, let's work. We have warning now. such lesson for future.

Best Regards

I tried to give this box for my friend, who was able to get shirt frim box - however my friends box didn't have full permissions anymore. End result was that I have now in inventory t-shirted box that I can give anyone - they can take a t-shirt from box - but can't give box further away.

I can only speculate that person who did load box to lucky chair did change box's permissions in lucky chair's content window.

Meahwhile, Hewee Zetkin was correct when he/she suggested that the perm slam bit be set on the server whenever the NextOwnerMask changes. I've found the right location in the code and implemented the logic – this makes the viewer fix obsolete. It is in server-1.27.1, however it will only take effect on content that has its permissions set in server-1.27.1 or later.

We have a Snowglobe test build that we think addresses this problem. We're hoping that you all can help confirm that we have a workable fix here:

Direct links:
Windows:
http://secondlife.com/developers/opensource/downloads/2009/trunk/2523/Snowglobe_1-1-0-2523_Setup.exe
Mac
http://secondlife.com/developers/opensource/downloads/2009/trunk/2523/Snowglobe_1_1_0_2523_SNOWGLOBETESTBUILD.dmg
Linux:
http://secondlife.com/developers/opensource/downloads/2009/trunk/2523/Snowglobe-i686-1.1.0.2523.tar.bz2

Note, this is a pre-release of Snowglobe, which has some known crash issues in it, so bear that in mind as you download this. This isn't recommended as a long-term solution for people looking for a fix, but rather as a short term way of helping us make sure we've got the fix right.

Latest version of Snowglobe can generally be found here:
http://wiki.secondlife.com/wiki/Snowglobe

Let me get this straight ....

There is a tentative viewer fix or test viewer we are using to test the fix first...

Andrew states.. server fix is ".... in server-1.27.1, however it will only take effect on content that has its permissions set in server-1.27.1 or later."

So we still will all need to reset permissions to any questionable bugged items in a server running 1.27.1 ????

And are these being rolled out , when ?

Should we use both the Snowglobe until it is released or what would be the best order to do what ?

If I understand things correctly:

• All objects set with bulk permissions prior to the snowglobe viewer Rob just released must have their permissions fixed. The most sure-fire way to do this would be rez out all objects affected, and rez all objects in their inventory, and set permissions on them manually while they're rezzed, before taking them back.

• All objects set using bulk permissions in the snowglobe viewer rob just mentioned will be good now, on server 1.27.0.

• All objects set using bulk permissions in any viewer (not just snowglobe), on the to-be-released 1.27.1, will be good.

Those last two are, of course, provided that Rob's and Andrew's fixes work properly.

And are they recommending to everyone check for that in all their items even if they did not use bulk perms and follow up and handle it in the same way, since it is also a server issue as well?

• All objects set using bulk permissions in the Snowglobe viewer I just posted should be good now, on server 1.27.0. Please please please test this and either confirm this is true or report that its still broken

And yes, sorry about that Rob. Folks, don't take my summary as an indication that Rob's snowglobe is a guaranteed fix yet

Latif Khalifa added a comment - 19/Jul/09 11:09 AM......... Additionally, if you read the comments, you will find that people are experiencing the same issue with objects that were packaged before the introduction of bulk permissions. I have confirmed this myself. Its only that we now have a clear repro case that utilizes bulk permissions to show the problem.

As I was also witness to finding the same bug in items packaged in Nov. Presenting in the same change of permission

We're really counting on getting your help to make sure we get a good fix here.

Thanks
Rob

I noticed Bulk Permissions now sets the slam bit in Next-owner permissions like manually changing the permissions does. But unlike manually changing, the Velocity bit is cleared, this doesn't seem to have any effect on anything though as the bit is turned back on as soon the object changes hands.

I have never used bulk-perm when boxing smthg up, but I have had to close all my vendors down (and remove hunt items from gifts) because some (too many) are going full perm to next user. I always set perms on individual items.

Boxed up both under 1.26 and 1.27

Regards.

Norsk Himmel

However, it seems clear to me from all the comments that there is a LOT of confusion amongst creators and developers surrounding the permission system, myself very much included. Up until this issue I thought I had a fairly good understanding, but now I'm seriously not sure - and reading this thread, with hardly two people agreeing, makes me even less confident. I'm sure I'm not alone.

In view of this I wonder if one of the great and good would write an "Idiot's Guide to SL Permissions" article and publish it on a blog/the SL wiki/the Knowledge Base, presuming that the reader knows NOTHING - so explain things like "task inventory", "debug permissions", "slam" and so on. I'd much rather be patronised than still be clueless

I've ended up with many more questions than have been answered, despite this issue having prompted me to re-read the Knowledge Base regarding perms and play around with passing boxes from alt to alt. For example, in what way does passing items in a folder differ from placing them in a box and giving them to someone? Is it only Bulk Permissions that has been affected - some people are reporting this happening with manually set perms too. How exactly do I need to go about setting correct perms when I want to pass items, in a folder, to my store management alt., for her to place in vendors and set for sale? Answers very much welcomed

I also agree with Skinkie, evidently we need some training! I have been in SL for quite some time, I always assumed that if I set permissions, no matter where or how, it was absolute.

A suggestion: if setting permissions using the proqerties dialog does not really and absolutely set permissions, please remove the check boxes and replace them with a simple information only format.

https://wiki.secondlife.com/wiki/Snowglobe

If Snowglobe 1.0 is working well for you, and you don't feel like taking chances, then give Snowglobe 1.0.3.2537 a spin. If on the other hand, you're willing to help us out, or if you have had problems with Snowglobe 1.0 in the past, you may want to give Snowglobe 1.1.0.2548 a spin, since there's a couple of crash fixing bugs that just landed in 1.1 that MAY solve the problems you were previously experiencing.

WORD OF CAUTION: neither of these builds has had any testing to speak of, beyond the brave souls in the community who have downloaded it and used it on a regular basis. The Snowglobe 1.0.3.2537 build is made from the same well-tested source as Snowglobe 1.0.2 and ONLY contains the fix for SVC-4444, so there should be very little additional risk over using Snowglobe 1.0.2, but Murphy's Law suggests there's always something. Snowglobe 1.1 contains a fair bit of additional work beyond Snowglobe 1.0 which could have introduced new problems.

So far with snowglobe permissions set seem to be working. Only difference that is apparent is that perms done manually show a check in the box on properties whereas with bulk permissions the boxes are only greyed out. I do not know if that matters or not.
Items permed prior to bulk perms, that exhibited this behavior appeared normal (checked boxes also). However, I had used bulk perm on items that i had released the end of June, and noticed the greyed out box vs checked boxes appear on those as well, and frankly I think give a heads up to those with dubious intentions which items are bulk permed.

I also was wondering when we will see 1.27.1 servers as referred to by Andrew :

....." Hewee Zetkin was correct when he/she suggested that the perm slam bit be set on the server whenever the NextOwnerMask changes. I've found the right location in the code and implemented the logic - this makes the viewer fix obsolete. It is in server-1.27.1, however it will only take effect on content that has its permissions set in server-1.27.1 or later."

Thanks for the hard work, hope we see this fiasco come to an end soon.

Some items made on 2nd March have appeared to have their permissions changed when they were fine until now, same permissions, copy, mod, no trans are now just trans in my inventory and when rezzed/worn.

The Snowglobe viewer is still being tested and concerns fixing bulk permission option in the last viewer release from what i am understanding.

I have recommended to friends to check all their items and compare them to your sales records since April when 1.26 was released and appears to be the starting point for which this "bug" appeared. We really have not been told what happened and how far back to check. I am just giving a guess-timate

It would be nice to know from LL what happened and how far back merchants should check items. At the moment we have no clear picture of how far back to check, how to protect ourselves, and how many or types of items that could have been breeched.

Undoubtly, there has got to be some people that were trying to take advantage of this bug and now we need to know how LL plans to deal with that.

I think the server-1.27.1 with my fix is currently deployed to most of the regions on the Preview Grid (I commited my final changes last Wed and the preview grid currently has stuff that was deployed on the following Thursda6). It should be possible to test the fix in the 1.27.1 regions there. Note, not all regions on the Preview Grid are 1.27.1 – when in doubt use the Help-->AboutSecondLife menu option to get the server version number.

BTW, this fix does NOT retroactively fix any content made prior. Due to ambiguities in how the data is stored is is not possible for the server to determine the full intent of the content creator by the bits stored after such a NextOwner permissions change occurs. From what I understand this permissions bug was introduced when the bulk permissions User Interface was added to the SL client.

(1) make a prim by yourself (rename it as Loveseat ).
(2) give the Loveseat full perm in edit window > general tab.
(3) put a no-mod script (or animation) which is created by someone else into the content tab of the full perm Seat.
(4) click on the script/animation, and open the property window. then give another click on the copy perm checkbox.
>> so now the script/animation is no copy/no mod.
>> instead, you can add no-copy perm on the script/animation in your inventory, then put it into the content tab on (3)
(5) take the Loveseat into your inventory.
(6) make a vendor box prim. and put (5) into the content tab on the box.
(7) take the vendor box into your inventory.
(8) try to set the vendor in your shop, so grab the vendor box out from inventory and rez it.
(9) you check the permission before it goes on on-sale. click on vendor to open edit window and see under the content tab.
(10) click on the Loveseat's object icon and open the property window.
>> it shows exactly same in screenshot-1.jpg (left). grayed-out mod/ no copy/ grayed out but checked trans.
>> creators name goes like (unknown).
(11) let's unpack the vendor box and rez the Loveseat in-world. then open the edit window.
>> you'll find the Seat alone is still full perm like that.
>> in edit window, creator name shows your name.

someone has already mentioned it though, 2 of the informations which you see in "property" window and in "edit" window are completely different. again, take a look on your screenshot-1 above. the property window says it's created by "(unknown)" =means 2 or more, however in the edit window, it says you are the creator of this item. they are different, obviously.
it's a very confusing feature but not a bug.

so i firstly saw your screenshot has nothing wrong.
if you have never had full perm on the linked seat objects, or if it's sure you gave no copy perm on the objects from edit window before you packed it into the vendor box, then i go hmmm...
and your another issue about the notecard though, i think it was happened because you have set "trans only" perm on it. means the next owner couldn't change the perms, neither you as the 3rd owner.

This one limits next-owner perms on shift-copy.

In short:

I make a structure, mod&cop, some scripts involved (like texture anim, touch sound on/off, simple stuff).

-Linksets are set to mod-cop, scripts cop-only.
-It's packed into a rezzer.
-Next owner rezzes, freezes, no prob.
-Next owner can shift-copy ONCE. 'Original' looses ALL perms, the shift-copied copy keeps mod&copy.
-Rezzbox stays fine, rezzes everything with correct perms.

1. I create an item for sale containing clothing - this may include shoes, flexis and sculpt items. I set all the perms while the items are in my inventory either to mod/copy or just copy.

2. These items are then boxed and sold thru a vendor or straight prim item.

3. Once someone has purchased the box, they then can pull the box out of inventory and drag a prim item from the box - for example a shoe. On the ground that shoe has full perms. This allows that person to sell that item that is on the ground to anyone.

4. Or - if the prim was mod/copy the perm once pulled to the ground becomes transfer still allowing that person to sell the prim item.

If they open the box in inventory the perms appear correctly but should they rez the box on the ground, drag the items out onto the ground the perms change.

This is happening now and with items created in the last several days. This is an issue that has not been fixed and needs to be immediately addressed. We have repeated several tests with several items and avatars and this happens over and over.

The only way to fix is if you box something up take the box out of your inventory, drop it and drag all the prim items out and correct the perms. Take those prim items out of the original box, take the new prims to your inventory and place in the box.

THIS IS A HUGE PROBLEM!

1. A genuine bug in the new Bulk Permissions system that caused permissions set using Bulk Permissions to be reverted next time the object was rezzed by its new owner.

2. A difficult-to-understand permissions system that makes it easy to get unexpected results such as items being more or less permissive than you intend them to be.

The first one above is fixed. The second one still exists, and I'm hoping that by explaining it, people will understand what's going on. It's taken me years to really understand the permissions system, and it's so confusing that it's no wonder that people constantly run into problems and think the system is randomly making their items fully-permissive.

Here's an example of a common set of steps a content creator might take that yields confusing results:

1. The content creator makes some content. At this point, for whatever reason, it's fully-permissive; for example if they're passing it back and forth to their business partner so that both can work on it.

2. The content creator rezzes a box to sell the content in.

3. The content creator places the content in the box.

4. The content creator picks up the box.

5. They right-click the object in their inventory and select properties, to view the permissions.

6. Seeing that the object is fully-permissive, they change the permissions to nomod/copy/no-transfer using the properties window.

7. They sell their content to a customer.

8. The customer receives the box in inventory, and it says it's nomod/copy/no-transfer.

9. The customer rezzes the box and sees that the box itself shows up in-world as nomod/copy/no-transfer.

10. When the customer looks inside the box, they'll see that the content is fully permissive.

A lot of items in SL are sold as fully-permissive, so this kind of thing can easily happen if a content creator isn't careful. Worse yet, the object SAYS it's next-owner nomod/copy/no-transfer in their inventory, so they quite reasonably believe it!

Here's why this happens. When you change the permissions of an object in your inventory, SL isn't actually going through and changing the contents. It's not actually even changing the permissions on the prims themselves yet! It's just recording the new, more-restrictive permissions you've set, and making a note to itself to apply them next time the object is rezzed. This note is called the "slam bit".

Next time the object is rezzed, if SL sees the "slam bit" set, it's going to apply those permissions you set to the object. So in step 9, when the containing box is rezzed, it's getting its permissions set to nomod/copy/no-transfer. But this is applied only to the box itself! SL won't go through and apply those permissions to the contents inside the box, so they'll stay exactly how they were before; often fully-permissive.

This is so confusing and counter-intuitive that it often looks like SL suddenly making objects fully-permissive. It's not a bug, though, it's a design decision. In my opinion, it's a very confusing and dangerous design decision, but it does make some sense and SL can be seen to work consistently if you really understand what's going on. The problem is, it's very hard to see the difference between what I've just described and the genuine bug in Bulk Permissions that Andrew just fixed.

So, the long and short of it is that the actual bug in this issue is fixed, but people are still having their objects end up fully-permissive because the permissions system is so confusing. If you don't like this, the best way to go is to open a new issue, asking that the system be changed to be less dangerous for users who don't have a PhD in SL Permissions.

Until then, you should make sure you never change the permissions on objects while they're in your inventory or in the inventory of an object! Just don't do it! It's incredibly likely that you won't be setting things as restrictive as you mean to. Always rez out every single object, and objects in that object's contents, etc... making sure you set permissions on every object in-world. For scripts, clothing, body parts, textures, and any other kind of inventory item, make sure you're setting each one individually or with Bulk Permissions (if you trust it at this point). Never allow Bulk Permissions to set the permissions on Object types, that's just asking for trouble.

BTW, if any Linden wants to chime in and tell me whether I'm right in all of this, I'd appreciate it. I've figured all this out through a ton of testing, but I'd love some corroboration from someone behind the curtain at LL.

@Lex Neva - Thank you for your explanation. Yes, setting permissions while an item is in object contents or avatar inventory does NOT enforce those permissions for all items inside. Such permissions settings on items are per-item, and the items inside the items have their own settings.

There is a subtle difference between the permissions on object items and other types, such as scripts, notecards, wearables, and textures. Each item (whether object, script, notecard, texture, or wearable) in avatar inventory is a chunk of "meta data" about ownership, creator, etc, including a reference to an "asset" which is a file that contains the "true data" of the item. For textures this true data is image colors, for notecards it is text, for scripts it is code, and for objects it is geometry (and more). All of the true data in the asset does not have stuff like owner, creator, and permissions... except for objects.

The true data of object assets includes the owner and permissions... when the asset was created. So if UserA created ObjectB then took it to inventory then an AssetC is created and ItemD is created in UserA's inventory that references it. If UserA gives the item to UserE then UserE gets an ItemF in inventory that has some meta-permission info, with a reference for the same AssetC as UserA's ItemD. Should UserE rez that AssetC out of ItemF as ObjectG then the ownerhsip info that was in AssetC is changed the moment it is created in-world, but only on the ObjectG itself, not its contents. The next-owner permissions of ObjectG's contents are applied, but those next-owner permissions used were those in AssetC, not those that were in UserE's inventory ItemF.

Whew. That was a mouthful.

Hrm... it occurs to me that it would be possible in theory to add a feature that is an "apply these next-owner permissions to everything inside" bit, that an object would inherit from its item meta data, and would apply to the item meta data of all of its contents when rezzed. Such a feature would enable item permissions settings to be enforced all the way down. Naturally, such a feature would have to prevent clearing permissions that were not allowed, so it is definitely harder to build it than to think up.

"Hrm... it occurs to me that it would be possible in theory to add a feature that is an "apply these next-owner permissions to everything inside" bit, that an object would inherit from its item meta data, and would apply to the item meta data of all of its contents when rezzed. Such a feature would enable item permissions settings to be enforced all the way down. Naturally, such a feature would have to prevent clearing permissions that were not allowed, so it is definitely harder to build it than to think up."

Even better, a way to apply "specific" permissions to objects in inventory. Rezzers may certainly need their internal inventories to carry different permissions than the rezzer itself.

Wow. Yes, quite a mouthful, or a fingerful, or something. I THINK I get the gist of it, but it would be very helpful if you had some kind of UML object or class diagram that illustrated the situation.

Incidentally, are there public JIRAs for the other two bugs you mentioned, that you are still working on? If so, could you please post a link or issue ID for them?

Thank you for working so hard on all of this!

you said

The only way to fix is if you box something up take the box out of your inventory, drop it and drag all the prim items out and correct the perms. Take those prim items out of the original box, take the new prims to your inventory and place in the box.

but this is the way how permission must be set on prims to have permissions work the way you want. This is because objects were designed in a way to contain the permissions inside the asset. The inventory permissions only apply to the item itself, when the object is rezzed, the permissions set in the asset are primary.

And to the Lindens, please fix the way on how the slam bit is applied (and when it's okay to remove it from inventory flags), detaching an object should never touch the inventory flags. Rezzing an object with slam bit set should always apply permissions, even if the ownership of prims doesn't change through rezzing. Do not allow dropping attachments to ground, when the slam bit is set.