Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008432opensim[REGION] OpenSim Corepublic2018-12-24 03:182018-12-25 14:41
Assigned ToBillBlight 
StatusclosedResolutionno change required 
PlatformPCOSWindowsOS Version10
Product Versionmaster (dev code) 
Target Versionmaster (dev code)Fixed in Version 
Summary0008432: Click to Open - Not Behaving Corrrectly
DescriptionThe Click to Open action on a full perm prim and contents works for the creator avatar, but not for other avatars.

Checked on latest dev master (2018-12-21 16:10) and with both Firestorm and Firestorm Beta.

Checked and it DOES work when using the same viewer in Second Life, so (for now) I am not suspecting the viewer itself.
Steps To ReproduceCreate a box.
Set the box as full permissions.
Add one (even very simple body part) item with full permissions into its contents.
Set the "Click to" as "Open".
Observe that the Open icon shows when the creator hovers the mouse over the box.

Log on as a different avatar.
Hover mouse over the box.
Observe that the open icon does not show.
Also see that if you try to right click over the object the "open" menu item is greyed out.
TagsNo tags attached.
Git Revision or version ( Dev Master 2018-12-21 16:10)
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script Engine
Environment.NET / Windows64
Mono VersionNone
ViewerFirestorm Beta
Attached Files

- Relationships

-  Notes
tampa (reporter)
2018-12-24 04:00

Unable to reproduce on master using hair body part and FS-Beta. Only thing I can see is that it takes a couple seconds for the "Click to Open" attribute to reach the other viewer(running two at the same time), but ultimately the state of "Click to Open" does make it to the other viewer, even if the body part is not full perm or the object is set to Copy. Maybe this is due to both accounts being userlevel 250 though.

Checking on console using http debug the attribute change does reach the database and adding to the contents of the prim does not reverse or block the attribute either.
UbitUmarov (administrator)
2018-12-24 06:23
edited on: 2018-12-24 06:51

Think you can only open objects you own, or if you have rights to modify owner objects.

aiaustin (developer)
2018-12-24 06:51
edited on: 2018-12-24 07:37

I think you must be right... I just tested with an avatar I don't normally use in Second Life and that avatar also cannot use "Open" on a test object. The previous avatar I tested with was probably sharing group items or something like that.

Strange, as I thought that "Open" is used as a way to offer items in boxes to inventory of any avatar isn't it? When you click on the "open box" icon it offers to copy items in the box to your inventory. But it seems that only for those sharing the object in some way.

Though I normally use a script in the box to give the contents, I noted that the Ruth 2.0 and Roth 2.0 distribution boxes use "Open" to offer their contents, which is why I noticed this problem. The contents were not available to the avatar via a click other than the owner of the box.

Anyway, now I realise my assumption was wrong, I will add a distributor script to make my copy work.

djphil (reporter)
2018-12-24 14:29

This is what LS says about this:


You must own the object and it must have contents to open it. Very useful if you sell content which is intended to be packaged and "unwrapped" from boxes.

The cursor changes to an open box when you hover the object. When clicked, an Object Contents window appears, with the same result as right-clicking the object and selecting Open.

source: [^]
aiaustin (developer)
2018-12-25 02:37
edited on: 2018-12-25 02:40

That is ambiguous isn’t it @dphil. And its kind of pointless if its not able to be opened to get permitted contents by others.

Still.. Firestorm in SL has the behaviour as OpenSim and as pointed out by @Ubitmarov. I wonxer if this has changed recently.

SL does not offer the unbox icon if it has no contents as documented... OpenSim offers the unbox icon (to the owner) as soon as the “click to” is set to Open even if its contents are empty. But that’s no real issue.

aiaustin (developer)
2018-12-25 02:39

Ah... of course..l I get it are meant to sell the whole BOX....then its opened by the NEW owner and they can unbox it... that now makes sense.
djphil (reporter)
2018-12-25 04:23
edited on: 2018-12-25 05:09

It seems to have a real interest if you set like this:
open / for sale / copy / 0 L$

Otherwise if you adjust like this:
open / for sale / original / 0 L$
then the behavior is strange.

1) The object remains on the ground without going through the inventory of the new owner. The object simply changes ownership.
2) The click action of the object automatically returns to the "touch" position, so there is no point in having previously set it to "open" in this case.
3) The object in the object becomes no copy / no transfer for the original owner.
4) The original owner can still erase the object on the ground even if he is no longer the current owner.

And finally, the 3rd possibility:
open / for sale / content / 0 L$
In this case there is no interest in using the 'open' option. The main object is never given entirely to the next owner, only its content is delivered.

aiaustin (developer)
2018-12-25 11:12

Thanks @djphil... I simply (and normally) use a “give contents to folder on touch” script.

I was just trying to make sense of the Ruth 2.0 and Roth 2.0 boxes which were set to “Open”. I now realise these were originally in an outer vender which delivered the box of contents to the receiver avatar who therefore owned the inner box and hence they could use that to get the contents via “Open”.

Happy Christmas everyone.
djphil (reporter)
2018-12-25 12:15

Merry christmas to you too and for everyone! :)

Point 4 that I quote above remain particularly strange.
If this behavior is voluntary, I do not understand it ...

The object has been "given" to the user, the object no longer belongs to the original owner. The original owner should not be able to delete an object that no longer belongs to him.
tampa (reporter)
2018-12-25 12:17

You have me a bit scared there, are you testing with normal accounts or gods? Userlever above 50 seems to be able to delete objects regardless of ownership, that is afaik intentional. If levels below that can also do this for such object then this may be a bug.
djphil (reporter)
2018-12-25 12:31
edited on: 2018-12-25 12:34

Hooo yes, you're right Tampa, I did not consider this setting.
I also see that god always sees the "open" icon above the objects.
I will think more before I speak next time :)

aiaustin (developer)
2018-12-25 12:34

Don’t you just wish everything was full perm all the time :-)
tampa (reporter)
2018-12-25 12:48

Don't say that too loud or the "OpenSim should be free" crowd is gonna waltz in.

On a serious note. Does it actually allow you to delete after owner change when using regular userlevel 0 accounts?
djphil (reporter)
2018-12-25 12:51

@Tampa: No, I tested this, the behavior is normal.
Point 4 that I quote above may be considered null and void.
BillBlight (developer)
2018-12-25 14:09

This is normal behavior.
BillBlight (developer)
2018-12-25 14:41

Steps to reproduce are not entirely correct.

But this is normal behavior, you should only be able to "Open" boxes that belong to you. The correct setup to use for the desired result is "Buy>Contents" or use a giver script.

There does seem to be some inconsistency of when or why the open menu appears or does not appear, I'm going to make an assumption that since it is the same in SL that it is viewer lag or object update lag.

Not sure it is worth a Jira on the viewer though, since regardless of the menu if you don't have the proper permissions/ownership you still cannot OPEN the item.

- Issue History
Date Modified Username Field Change
2018-12-24 03:18 aiaustin New Issue
2018-12-24 03:39 aiaustin Description Updated View Revisions
2018-12-24 03:39 aiaustin Steps to Reproduce Updated View Revisions
2018-12-24 04:00 tampa Note Added: 0033668
2018-12-24 06:23 UbitUmarov Note Added: 0033669
2018-12-24 06:51 aiaustin Note Added: 0033670
2018-12-24 06:51 aiaustin Note Edited: 0033669 View Revisions
2018-12-24 07:37 aiaustin Note Edited: 0033670 View Revisions
2018-12-24 14:29 djphil Note Added: 0033672
2018-12-25 02:37 aiaustin Note Added: 0033673
2018-12-25 02:39 aiaustin Note Added: 0033674
2018-12-25 02:39 aiaustin Note Edited: 0033673 View Revisions
2018-12-25 02:40 aiaustin Note Edited: 0033673 View Revisions
2018-12-25 04:23 djphil Note Added: 0033675
2018-12-25 04:23 djphil Note Edited: 0033675 View Revisions
2018-12-25 04:26 djphil Note Edited: 0033675 View Revisions
2018-12-25 04:34 djphil Note Edited: 0033675 View Revisions
2018-12-25 04:36 djphil Note Edited: 0033675 View Revisions
2018-12-25 05:09 djphil Note Edited: 0033675 View Revisions
2018-12-25 11:12 aiaustin Note Added: 0033676
2018-12-25 12:15 djphil Note Added: 0033677
2018-12-25 12:17 tampa Note Added: 0033678
2018-12-25 12:31 djphil Note Added: 0033679
2018-12-25 12:34 aiaustin Note Added: 0033680
2018-12-25 12:34 aiaustin Note Edited: 0033679 View Revisions
2018-12-25 12:48 tampa Note Added: 0033681
2018-12-25 12:51 djphil Note Added: 0033682
2018-12-25 14:09 BillBlight Note Added: 0033683
2018-12-25 14:09 BillBlight Status new => resolved
2018-12-25 14:09 BillBlight Resolution open => no change required
2018-12-25 14:09 BillBlight Assigned To => BillBlight
2018-12-25 14:41 BillBlight Note Added: 0033684
2018-12-25 14:41 BillBlight Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker