Attachments: understand / revisit the permission rule hiding restricted textures + materials (Linden SL-5522 / SL-20655) #658

New issue

Open

opened 2026-10-11 02:27:12 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-11 02:27:12 +00:00

Owner

Revisit the rule that hides restricted textures and materials when the object being edited is worn. Today:

Texture / normal / specular / projector pickers on an attachment require copy + transfer.
The PBR material picker on an attachment requires copy + transfer + modify.
Items that fail are hidden silently, with no explanation. On rezzed objects there is no filter.

This rule is Linden's: SL-5522 (97ee8b207b, Sep 2023) and SL-20655 (88aefc95ea, Nov 2023). It lives in llpanelface.cpp / fspanelface.cpp (setFilterPermissionMasks), llpanelvolume.cpp (light texture) and lltooldraganddrop.cpp. Linden's stated reason, from the SL-5522 code comment: "attachments are in world and in inventory, server doesn't support changing permissions in such case". Applying a restricted asset seems to change the object's permissions on a rezzed object, and the server can't do that for an attachment. Why materials also need modify is not explained anywhere.

Questions to answer (on the alt, with throwaway items, before changing anything)

What happens to a rezzed object's permissions, current and next-owner, when a no-transfer / no-copy / no-mod texture or material is applied?
What does the server do with the same application on a worn attachment if the viewer allows it? Possible outcomes: accepted, rejected silently, rejected with an alert, or accepted with the permissions left unchanged (a leak).
Why does modify matter for materials: overrides (#gltf overrides on a no-mod material), or something else?
What do other viewers do today (released code only)?

Possible outcomes

Keep the rule but explain it in the picker: "Only full-permission materials can be applied to worn items", with a way to show the hidden items greyed out.
Relax it where the server is shown to handle it correctly.

Use the same zero-risk testing standard as inventory work: alt account, throwaway items, no blind changes. Related: #650, where the reporter's case was a rezzed object, so this rule isn't the cause there.

Revisit the rule that hides restricted textures and materials when the object being edited is **worn**. Today: - Texture / normal / specular / projector pickers on an attachment require **copy + transfer**. - The PBR material picker on an attachment requires **copy + transfer + modify**. - Items that fail are hidden silently, with no explanation. On rezzed objects there is no filter. This rule is Linden's: SL-5522 (`97ee8b207b`, Sep 2023) and SL-20655 (`88aefc95ea`, Nov 2023). It lives in `llpanelface.cpp` / `fspanelface.cpp` (`setFilterPermissionMasks`), `llpanelvolume.cpp` (light texture) and `lltooldraganddrop.cpp`. Linden's stated reason, from the SL-5522 code comment: *"attachments are in world and in inventory, server doesn't support changing permissions in such case"*. Applying a restricted asset seems to change the **object's** permissions on a rezzed object, and the server can't do that for an attachment. Why materials also need **modify** is not explained anywhere. ## Questions to answer (on the alt, with throwaway items, before changing anything) 1. What happens to a **rezzed** object's permissions, current and next-owner, when a no-transfer / no-copy / no-mod texture or material is applied? 2. What does the server do with the same application on a **worn** attachment if the viewer allows it? Possible outcomes: accepted, rejected silently, rejected with an alert, or accepted with the permissions left unchanged (a leak). 3. Why does **modify** matter for materials: overrides (#gltf overrides on a no-mod material), or something else? 4. What do other viewers do today (released code only)? ## Possible outcomes - Keep the rule but **explain it in the picker**: "Only full-permission materials can be applied to worn items", with a way to show the hidden items greyed out. - Relax it where the server is shown to handle it correctly. Use the same zero-risk testing standard as inventory work: alt account, throwaway items, no blind changes. Related: #650, where the reporter's case was a rezzed object, so this rule isn't the cause there.

sky_line added the

feature

label

2026-10-11 02:27:12 +00:00

sky_line added this to the Slipstream project

2026-10-11 02:27:12 +00:00

sky_line referenced this issue

2026-10-12 18:24:19 +00:00

Build > Texture tab shows nothing for objects you don't own (should show read-only values) #729

sky_line referenced this issue from a commit

2026-10-25 19:16:09 +00:00

#658: texture/material picker explains why restricted items are hidden on worn objects