MantisBT - opensim
View Issue Details
0008432opensim[REGION] OpenSim Corepublic2018-12-24 03:182018-12-25 14:41
aiaustin 
BillBlight 
normalmajoralways
closedno change required 
PCWindows10
master (dev code) 
master (dev code) 
opensim-0.9.0.1-660-g810ab5f.zip (0.9.1.0 Dev Master 2018-12-21 16:10)
Grid (Multiple Regions per Sim)
BulletSim
.NET / Windows64
None
Firestorm 6.0.1.5653 Beta
0008432: Click to Open - Not Behaving Corrrectly
The 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 5.1.7.55786 and Firestorm 6.0.1.5653 Beta.

Checked and it DOES work when using the same viewer in Second Life, so (for now) I am not suspecting the viewer itself.
Create 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.
No tags attached.
Issue History
2018-12-24 03:18aiaustinNew Issue
2018-12-24 03:39aiaustinDescription Updatedbug_revision_view_page.php?rev_id=7448#r7448
2018-12-24 03:39aiaustinSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=7450#r7450
2018-12-24 04:00tampaNote Added: 0033668
2018-12-24 06:23UbitUmarovNote Added: 0033669
2018-12-24 06:51aiaustinNote Added: 0033670
2018-12-24 06:51aiaustinNote Edited: 0033669bug_revision_view_page.php?bugnote_id=33669#r7452
2018-12-24 07:37aiaustinNote Edited: 0033670bug_revision_view_page.php?bugnote_id=33670#r7457
2018-12-24 14:29djphilNote Added: 0033672
2018-12-25 02:37aiaustinNote Added: 0033673
2018-12-25 02:39aiaustinNote Added: 0033674
2018-12-25 02:39aiaustinNote Edited: 0033673bug_revision_view_page.php?bugnote_id=33673#r7459
2018-12-25 02:40aiaustinNote Edited: 0033673bug_revision_view_page.php?bugnote_id=33673#r7460
2018-12-25 04:23djphilNote Added: 0033675
2018-12-25 04:23djphilNote Edited: 0033675bug_revision_view_page.php?bugnote_id=33675#r7462
2018-12-25 04:26djphilNote Edited: 0033675bug_revision_view_page.php?bugnote_id=33675#r7463
2018-12-25 04:34djphilNote Edited: 0033675bug_revision_view_page.php?bugnote_id=33675#r7464
2018-12-25 04:36djphilNote Edited: 0033675bug_revision_view_page.php?bugnote_id=33675#r7465
2018-12-25 05:09djphilNote Edited: 0033675bug_revision_view_page.php?bugnote_id=33675#r7466
2018-12-25 11:12aiaustinNote Added: 0033676
2018-12-25 12:15djphilNote Added: 0033677
2018-12-25 12:17tampaNote Added: 0033678
2018-12-25 12:31djphilNote Added: 0033679
2018-12-25 12:34aiaustinNote Added: 0033680
2018-12-25 12:34aiaustinNote Edited: 0033679bug_revision_view_page.php?bugnote_id=33679#r7468
2018-12-25 12:48tampaNote Added: 0033681
2018-12-25 12:51djphilNote Added: 0033682
2018-12-25 14:09BillBlightNote Added: 0033683
2018-12-25 14:09BillBlightStatusnew => resolved
2018-12-25 14:09BillBlightResolutionopen => no change required
2018-12-25 14:09BillBlightAssigned To => BillBlight
2018-12-25 14:41BillBlightNote Added: 0033684
2018-12-25 14:41BillBlightStatusresolved => closed

Notes
(0033668)
tampa   
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.
(0033669)
UbitUmarov   
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.

(0033670)
aiaustin   
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.

(0033672)
djphil   
2018-12-24 14:29   
This is what LS says about this:

Open

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: https://community.secondlife.com/knowledgebase/english/click-actions-r18/ [^]
(0033673)
aiaustin   
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.

(0033674)
aiaustin   
2018-12-25 02:39   
Ah... of course..l I get it now...you are meant to sell the whole BOX....then its opened by the NEW owner and they can unbox it... that now makes sense.
(0033675)
djphil   
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.

(0033676)
aiaustin   
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.
(0033677)
djphil   
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.
(0033678)
tampa   
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.
(0033679)
djphil   
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 :)

(0033680)
aiaustin   
2018-12-25 12:34   
Don’t you just wish everything was full perm all the time :-)
(0033681)
tampa   
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?
(0033682)
djphil   
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.
(0033683)
BillBlight   
2018-12-25 14:09   
This is normal behavior.
(0033684)
BillBlight   
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.