Debug Permissions

Template:Needs Translation/de Template:Needs Translation/es Template:Needs Translation/el Template:Needs Translation/fr Template:Needs Translation/he Template:Needs Translation/it Template:Needs Translation/ja Template:Needs Translation/ko Template:Needs Translation/nl Template:Needs Translation/hu Template:Needs Translation/no Template:Needs Translation/da Template:Needs Translation/sv Template:Needs Translation/tr Template:Needs Translation/pl Template:Needs Translation/pt Template:Needs Translation/ru Template:Needs Translation/th Template:Needs Translation/uk Template:Needs Translation/zh-Hans Template:Needs Translation/zh-Hant

Debug Permissions is a tool which shows you granular attributes of your Second Life items. Permissions have numerous subtleties and with some practice, Debug Permissions can help you figure these out. You should have a firm understanding of next-owner permissions before using Debug Permissions.

To view Debug Permissions:

1. If using Viewer 2.0 or later, open the Build -> Options menu, and enable Show Advanced Permissions. If using Viewer 1.23.5 or earlier, open the Advanced menu and select Debug Permissions.
2. Right-click an object and select Edit.
3. If the General tab in the build tools isn't selected, click it.

Now, you'll see what was previously a blank spot has been filled in with additional Permissions: status.

Here's what all the abbreviations mean:

• B = Base - The object can never be more permissive than this.
• O = Owner - The permissions the owner (you) currently has.
• G = Group - The permissions group members currently have on the object. (The group the object is set or deeded to is shown next to Group: above.)
• E = Everyone - The permissions everyone else has on the object.
• N = Next Owner - The permissions the next person to own the object will have.
• F = Full/Folded - The permissions of the object as a whole, including all permissions of the object's contents. For example, a copyable object which has a no-copy item added to its contents becomes non-copyable as a whole because it's restricted by the no-copy content item.
• M, C, and T = Modify, Copy, and Transfer - Standard permissions.
• V = Velocity - This actually means "can move" permissions. For instance, if an object shows "E: V", this means everyone can move this object around inworld, which is the the same as Allow anyone to move being enabled.
• * = Slam bit - Explained more in the next section.

What is a slam bit?

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

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

It's also important to note, object transfers between avatars can result in unexpected permission behavior, if an object isn't rezzed to 'slam' the currently set permissions befor making changes. It's best practice to rez any object you receive before making additional in-inventory permission changes. (see https://jira.secondlife.com/browse/SVC-8223)

Technically, this is because an object's permissions as seen in your inventory (a database handle pointing to an asset) are out-of-sync with the asset's permission itself. We're aware of the confusion this causes. Unfortunately, it's a very difficult thing to fix.

The important lesson here: if you can avoid it, do NOT change an object's permissions when it's in your inventory. If you do, be sure to rez it to apply ("slam") those permissions, then take the resulting copy. Make sure earlier copies are archived or deleted as-needed to avoid confusion and accidentally giving the wrong thing out. While it takes a little time, double-checking permissions before distributing objects goes a long way towards preventing trouble.