Viewer caches 'no modify' status of another agent's objects after Edit Permissions was granted

[canny]

Edit Permissions Not granting when someone grants permissions

https://secondlife.canny.io/admin/board/bug-reports/p/edit-permissions

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim #4834 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @canny[bot] (replace 20 with the amount, and @canny[bot] with the user to tip).

📖 If you want to learn more, check out our documentation.

[canny]

This issue has been linked to a Canny post: Edit Permissions 🎉

[maestrolinden]

I can reproduce this issue with Second Life Release 7.2.1.17108480561 (64bit) on Second Life Server 2025-09-16.17777995432. It appears that if you had selected an object prior to edit permissions being granted, the viewer caches the "no modify" state when edit permissions have been granted, preventing the user from editing objects until they are 'dirtied'.

Here's the end-to-end repro case:

1. UserA and UserB (who are not yet friends): login to the same location
2. UserA: Right click on UserB and select "Add friend"
3. UserB: Accept UserA's friendship offer
4. UserA and UserB: Open the other user's profile in People -> Friends, and click Actions -> Permissions to view permissions
5. UserA and UserB: Verify that the default permissions are set:
   • 'See when I am online' is enabled
   • 'Find me on the world map' is disabled
   • 'Edit, delete, and take objects from my land' is disabled
6. UserA: Rez a new box with the build tool
7. UserB: select UserA's box, and attempt to resize it
   • UserB: Verify that editing is disabled, with "You can't modify this object" shown in the build tool
8. UserA: Enable 'Edit, delete, and take objects from my land' from the permissions options, then click Yes to confirm
   • UserB: Verify you see a notification that '[UserA] has given you permission to edit their objects.'
9. UserB: Select UserA's box from (6) again and attempt to resize it
10. UserA: Rez a new sphere with the build tool
11. UserB: Select UserA's sphere and attempt to resize it
    12: UserA: Select your box, resize it, then deselect it
    13: UserB: Make another attempt to resize UserA's box

Expected results:

• After UserA gives object edit permissions to UserB, UserB should be able to resize both the box that UserA had rezzed prior to the permissions grant, as well as the sphere that UserA had rezzed after permissions were granted.

Actual results:

• In (9), UserB observes that that "You can't modify this object" shown in the build tool, and that you can't edit the box ( BUG - UserB should be able to edit it! )
• In (11), UserB observes that "You can modify this object" correctly appears in the build tool, and that the sphere can be resized by UserB immediately
• In (13), UserB observes that they can now resize the box, following UserA's slight modification

Looking at this bug, I'm pretty sure it's viewer-side. UserB's viewer appears to be caching the "You can't modify this object" state on the box from when it was selected in (7), and doesn't allow the User to edit it in step (9). The sphere does not have this cached status, because it was rezzed after permissions were granted. When UserA resizes the box, it appears to clear this cached state on UserB's viewer, allowing UserB to edit the box.

In (9), if UserB bypasses the viewer UI, and manually sends a MultipleObjectUpdate message to resize the box (similar to what they sent to resize the sphere, but updating the ObjectLocalID to update), then they are able to resize the box - as expected. Details on that coming to the GHI.

Here are some other test messages. In my test case, UserA was 39b44919-512a-40a5-8347-90f9125937e4 and UserB was 70243b06-a65e-4e2b-b419-4844fbc3ea11.

• In step (8), the 'Permissions rights granted' Message that UserB gets appears to be well-formed:

IN ChangeUserRights [RELIABLE]
# ID: 1592

[AgentData]
  AgentID = 39b44919-512a-40a5-8347-90f9125937e4
[Rights]
  AgentRelated = 70243b06-a65e-4e2b-b419-4844fbc3ea11
  RelatedRights =| ('MODIFY_OBJECTS',) #0x4

• In step 9, when UserB selects the (incorrectly) no-modify box, the ObjectProperties looks like:

IN ObjectProperties [ZEROCODED] [RELIABLE]
# ID: 4499

[ObjectData]
  ObjectID = 68834c64-2671-67cf-2015-e836ce055912
  CreatorID = 39b44919-512a-40a5-8347-90f9125937e4
  OwnerID = 39b44919-512a-40a5-8347-90f9125937e4
  GroupID = 6154dc8d-f198-d6cc-4714-9841a1d49521
  CreationDate =| '2025-10-15T11:24:13.072463' #1760552653072463
  BaseMask =| ('TRANSFER', \
     'MODIFY', \
     'COPY', \
     'EXPORT_OR_PARCEL_ENTER', \
     'TERRAFORM', \
     'OWNER_DEBIT', \
     'MOVE', \
     'DAMAGE', \
     2145394687) #0x7fffffff
  OwnerMask =| ('TRANSFER', \
     'MODIFY', \
     'COPY', \
     'EXPORT_OR_PARCEL_ENTER', \
     'TERRAFORM', \
     'OWNER_DEBIT', \
     'MOVE', \
     'DAMAGE', \
     2145394687) #0x7fffffff
  GroupMask =| () #0x0
  EveryoneMask =| () #0x0
  NextOwnerMask =| ('TRANSFER', 'MOVE') #0x82000
  OwnershipCost = 10
  SaleType =| 'NOT' #0
  SalePrice = 10
  AggregatePerms = 0
  AggregatePermTextures = 0
  AggregatePermTexturesOwner = 0
  Category = 0
  InventorySerial = 0
  ItemID = 00000000-0000-0000-0000-000000000000
  FolderID = 00000000-0000-0000-0000-000000000000
  FromTaskID = 00000000-0000-0000-0000-000000000000
  LastOwnerID = 00000000-0000-0000-0000-000000000000
  Name = 'Object'
  Description = b''
  TouchName = b''
  SitName = b''
  TextureID =| ['89556747-24cb-43ed-920b-47caed15465f', \
     '89556747-24cb-43ed-920b-47caed15465f', \
     '89556747-24cb-43ed-920b-47caed15465f', \
     '89556747-24cb-43ed-920b-47caed15465f', \
     '89556747-24cb-43ed-920b-47caed15465f', \
     '89556747-24cb-43ed-920b-47caed15465f']
  #TextureID = b'\x89UgG$\xcbC\xed\x92\x0bG\xca\xed\x15F_\x89UgG$\xcbC\xed\x92\x0bG\xca\xed\x15F_\x89UgG$\xcbC\xed\x92\x0bG\xca\xed\x15F_\x89UgG$\xcbC\xed\x92\x0bG\xca\xed\x15F_\x89UgG$\xcbC\xed\x92\x0bG\xca\xed\x15F_\x89UgG$\xcbC\xed\x92\x0bG\xca\xed\x15F_'

• In step 10, when UserB selects the modifiable sphere, the ObjectProperties look like:
  • I think this looks the same as the box from a permissions POV. In both cases, OwnerMask indicates that the owner can modify it, and the viewer already knows that the OwnerID has just granted edit objects permission.

IN ObjectProperties [ZEROCODED] [RELIABLE]
# ID: 3692

[ObjectData]
  ObjectID = 343544c7-eaf1-d430-8e57-7d55221211f9
  CreatorID = 39b44919-512a-40a5-8347-90f9125937e4
  OwnerID = 39b44919-512a-40a5-8347-90f9125937e4
  GroupID = 6154dc8d-f198-d6cc-4714-9841a1d49521
  CreationDate =| '2025-10-15T11:26:06.744631' #1760552766744631
  BaseMask =| ('TRANSFER', \
     'MODIFY', \
     'COPY', \
     'EXPORT_OR_PARCEL_ENTER', \
     'TERRAFORM', \
     'OWNER_DEBIT', \
     'MOVE', \
     'DAMAGE', \
     2145394687) #0x7fffffff
  OwnerMask =| ('TRANSFER', \
     'MODIFY', \
     'COPY', \
     'EXPORT_OR_PARCEL_ENTER', \
     'TERRAFORM', \
     'OWNER_DEBIT', \
     'MOVE', \
     'DAMAGE', \
     2145394687) #0x7fffffff
  GroupMask =| () #0x0
  EveryoneMask =| () #0x0
  NextOwnerMask =| ('TRANSFER', 'MOVE') #0x82000
  OwnershipCost = 10
  SaleType =| 'NOT' #0
  SalePrice = 10
  AggregatePerms = 0
  AggregatePermTextures = 0
  AggregatePermTexturesOwner = 0
  Category = 0
  InventorySerial = 0
  ItemID = 00000000-0000-0000-0000-000000000000
  FolderID = 00000000-0000-0000-0000-000000000000
  FromTaskID = 00000000-0000-0000-0000-000000000000
  LastOwnerID = 00000000-0000-0000-0000-000000000000
  Name = 'Object'
  Description = b''
  TouchName = b''
  SitName = b''
  TextureID =| ['89556747-24cb-43ed-920b-47caed15465f']
  #TextureID = b'\x89UgG$\xcbC\xed\x92\x0bG\xca\xed\x15F_'

The hacked MultipleObjectUpdate message which was able to resize the box in step (9) looks like this. I just took the resize message that the viewer sent to resize the sphere, and applied it to the box's ObjectLocalID.

OUT MultipleObjectUpdate [RELIABLE] [ACK]
# ID: 956

[AgentData]
  AgentID = [[AGENT_ID]]
  SessionID = [[SESSION_ID]]
[ObjectData]
  ObjectLocalID = 77566384
  Type =| ('POSITION', 'SCALE', 'LINKED_SETS', 'UNIFORM') #0x1d
  Data =| {'POSITION': (43.1068000793457, 91.5832290649414, 34.45309829711914), \
     'SCALE': (0.9555362462997437, 0.9555362462997437, 0.9555362462997437)}
  #Data = b']m,B\x9d*\xb7B\xf9\xcf\x05B\x06\x9et?\x06\x9et?\x06\x9et?'

I also see that if UserB attempts to resize the box in this way before permissions are granted, they get a rather clear Can't rescale -- permission denied alert from the simulator.