[#SVC-3551] llSetInventoryNextOwnerPermMask or llSetInventoryPermMask

2. Second Life Service - SVC

llSetInventoryNextOwnerPermMask or llSetInventoryPermMask

Created: 18/Dec/08 05:29 PM Updated: Tuesday 01:57 PM

Return to search

Component/s:

Permissions, Scripts

Affects Version/s:

None

Fix Version/s:

None

Issue Links:

Relates

This issue Relates to:

VWR-8049 User-settable default permissions on creation of objects, clothing, scripts, notecards, etc.

SVC-593 There should be a way to mass set permissions on items

This issue is related to by:

SVC-706 New Primitive/Object/Link functions

Linden Lab Issue ID:

DEV-17836

Description

« Hide

I'm recommending the llSetInventoryNextOwnerPermMask function (name could be shortened). This function will allow a script to do the following:

-Set the Next Owner's permission for an object in task's inventory.
-Only prohibit permissions, not permit any permissions not already permitted.

The function will NOT be able to do the following:

-Set the Next Owner's permissions for an object in task's inventory if the object is not transferable.
-Set permissions that are already not permitted. For example, if the object does not permit copying, llSetInventoryNextOwnerPermMask will not be able to permit copying.

Recommended function syntax should be similar to llSetInventoryPermMask.

If possible llSetInventoryPermMask would be more suited for the job then the suggested llSetInventoryNextOwnerPermMask. However, llSetInventoryPermMask would need to have more restrictions if God Mode is not evident. These restrictions being the same as the above restrictions for llSetInventoryNextOwnerPermMask.

llSetInventoryPermMask should have the following restrictions if God Mode is not granted.

-MASK_NEXT will be the only flag available.
-The function will have no effect if the current permissions include no transfer.
-PERM_* values will only be used in such a way that will make permission more strict rather then give permissions that are not already there.

To elaborate more, PERM_ALL will be useless sense you CAN NOT grant permissions then already available. In conclusion, llSetInventoryPermMask without God Mode will only be useful for making an object have less permissions for the next owner.

Why would this be needed? One application for this is automation. If you have a lot items you would like to sell and would like to set the permissions for them all, rather then going through all the items one by one, you could write a simple script to do the cumbersome work for you. One more important application for this would be the ability to sell other user's items for them at your store (with there consent of course, and more likely giving them large commission in return).

I hope that Linden Labs really considers this recommendation. Sense the llSetInventoryPermMask function is already there, I don't see how this could be difficult to accomplish. But then again, I don't really know how to technically achieve this.

Thank you
Denim Kamachi

Description

I'm recommending the llSetInventoryNextOwnerPermMask function (name could be shortened). This function will allow a script to do the following: -Set the Next Owner's permission for an object in task's inventory. -Only prohibit permissions, not permit any permissions not already permitted. The function will NOT be able to do the following: -Set the Next Owner's permissions for an object in task's inventory if the object is not transferable. -Set permissions that are already not permitted. For example, if the object does not permit copying, llSetInventoryNextOwnerPermMask will not be able to permit copying. Recommended function syntax should be similar to llSetInventoryPermMask. If possible llSetInventoryPermMask would be more suited for the job then the suggested llSetInventoryNextOwnerPermMask. However, llSetInventoryPermMask would need to have more restrictions if God Mode is not evident. These restrictions being the same as the above restrictions for llSetInventoryNextOwnerPermMask. llSetInventoryPermMask should have the following restrictions if God Mode is not granted. -MASK_NEXT will be the only flag available. -The function will have no effect if the current permissions include no transfer. -PERM_* values will only be used in such a way that will make permission more strict rather then give permissions that are not already there. To elaborate more, PERM_ALL will be useless sense you CAN NOT grant permissions then already available. In conclusion, llSetInventoryPermMask without God Mode will only be useful for making an object have less permissions for the next owner. Why would this be needed? One application for this is automation. If you have a lot items you would like to sell and would like to set the permissions for them all, rather then going through all the items one by one, you could write a simple script to do the cumbersome work for you. One more important application for this would be the ability to sell other user's items for them at your store (with there consent of course, and more likely giving them large commission in return). I hope that Linden Labs really considers this recommendation. Sense the llSetInventoryPermMask function is already there, I don't see how this could be difficult to accomplish. But then again, I don't really know how to technically achieve this. Thank you Denim Kamachi

Show »

All

Comments

Change History

Sort Order:

Liny Odell made changes - 25/Jan/09 01:17 PM

Field	Original Value	New Value
Link		This issue Relates to SVC-593 [ SVC-593 ]

CG Linden made changes - 05/Feb/09 11:49 AM

Link

This issue Relates to VWR-8049 [ VWR-8049 ]

[ Permlink | « Hide ]

CG Linden added a comment - 05/Feb/09 11:49 AM

I will see if I can't revive some interest in this... The main problem here is that the conditions under which this should be permitted are astonishingly complicated.

McCabe Maxsted made changes - 05/Feb/09 12:08 PM

Link

This issue is related to by SVC-706 [ SVC-706 ]

[ Permlink | « Hide ]

CG Linden added a comment - 06/Feb/09 02:40 PM

Internal JIRA: DEV-17836

[ Permlink | « Hide ]

Gypsy Paz added a comment - 27/Mar/09 09:25 PM

Yes, this would be very good!

I have some products that really need to be available to builders, but they have 3 levels of nested inventory contents and if I let them out there full perm, guaranteed not everyone would set the perms correctly and someone would grab the animations and scripts and they would become freebies.

[ Permlink | « Hide ]

Nilene Humby added a comment - 01/Apr/09 03:18 AM

Hope you can revive this issue! Like myself, not all builders are scripters. Some of the best products in SL, which would really enhance the marketability of our creations, are just not available, full perm. ...and understandably so... It is a really limiting and frustrating situation for everyone, so I hope resolution becomes a priority !!

Strife Onizuka made changes - 01/Apr/09 06:19 AM

Linden Lab Issue ID

DEV-17836

[ Permlink | « Hide ]

Strife Onizuka added a comment - 01/Apr/09 06:30 AM - edited

I don't have any incites on to this, CG is correct about the complexity of the problems.

Here is a griefer usercase.
1) Griefer gives out script purporting to be a script vender update.
2) User installs the script into vender
3) Using llSetInventoryPermMask the script changes the permissions of the objects in the vender and transfers the contents to Griefer.
4) Script resets the permissions.
5) Griefer gives away/sells products as his own.

To combat this scenario the function needs strong limits on expanding the assets permitted uses (that is, removing next owner restrictions).
Either the should not be allowed to remove next owner restrictions already in place, or a script permission would be needed.
Maybe even an asset permission to go along with the script permission ("Scripts in this prim can change the permissions of items in the prims inventory []").

[ Permlink | « Hide ]

Gypsy Paz added a comment - 24/Apr/09 08:34 AM

ya know, another problem with this would be no-script zones. It wouldn't be very effective if you set the script to lock down the perms on an animation if it's so easy to break it. Although that could be worked out by setting up an object that they have to rez at our stores and give it the items with llGiveInventory() to the buyers object, and set the perms then.

Although, what might be an all around better solution would be to just add an 'advanced perms' button to the edit window and let the client/server set that up. It would probably be much easier to develop too, and it sure would be the most fool proof solution.

As far as Strife's griefer modes, #1 could be a problem, although I don't think #3 would be an issue because the perms should only be able to be made stricter. As far as #5, isn't that pretty much the whole point here? To allow us to sell stuff to be resold without having to trust everybody to set the perms correctly.

Anyway, there's my two cents, I really hope this one goes forward. I for one have many products that would fit in very well with other sellers builds. It would be awesome to provide stuff that way without the fear of my stuff winding up in the freebie market.

[ Permlink | « Hide ]

Norton Burns added a comment - 17/Jul/09 07:47 AM - edited

We now have the 'set all perms' button in the edit window, but still a thought as to setting perms for future users, such as handing a non-networked vendor to a 3rd party, who needs trans perms to be able to sell from it, though those items should be no-trans when the buyer receives them.
In these circumstances, it would be good to be able to set new perms as the 3rd party rezzes the vendor, or at the point of sale as the object leaves the vendor, or as the vended object is first rezzed by it's new owner.

I would like to be able to make & sell a 'drag & drop' weapons scripting system for 3rd party builders, whereby it would be impossible for them to sell the system on as copy/trans, only as finished, copy-only weapons.

For this scenario & also for product updaters, why not use the existing script PIN number system, which any updating system must have embedded in it anyway? It would be a relatively simple matter to set the PIN for any items which a creator may need to be changed this way.

That would stop any griefer who didn't know the PIN.
No PIN number, no set permissions - easy.
God mode not required.

[ Permlink | « Hide ]

Denim Kamachi added a comment - 24/Nov/09 01:57 PM

I don't see how this would be a security issue or complicated.

Let me clarify a few things. First, llSetInventoryNextOwnerPermMask will only change the "Next owner can" permissions like in the properties window of an object. So I don't see how there would be any technical difficulties; it would just be a script changing the next-owner permissions rather than a agent. Second, llSetInventoryNextOwnerPermMask will not be able to give more permissions then what is currently already permitted. If the object doesn't have modify perms, then llSetInventoryNextOwnerPermsMask would not be able to give modify perms to the next owner. This goes for each of the three perms (mod, copy, trans).

I don't see how this would be difficult to implement, because llSetInventoryPermMask already can set next owner permissions (MASK_NEXT flag). Rather than creating a whole new function for this feature, maybe we could just give limited access to the llSetInventoryPermMask to those that don't have God Mode.

Please some clearly state why this would be hard to achieve?