[#SVC-3046] Add permissions information to ObjectAdd message

2. Second Life Service - SVC

Add permissions information to ObjectAdd message

Created: 10/Sep/08 12:34 PM Updated: 04/May/09 10:44 AM

Return to search

Component/s:

Permissions

Affects Version/s:

None

Fix Version/s:

None

File Attachments:

dump.txt (3 kB)

Environment:

(not relevant)

Issue Links:

Relates

This issue Relates to:

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

Last Triaged:	23/Feb/09 04:03 PM
Linden Lab Issue ID:	DEV-27902

Description

« Hide

Purpose :
======

Allow users to set different default permissions for the objects they create.

Rationale :
=======

1) The current contents creation model of Second Life is a propriétary model, because default permissions are not copiable / no copy / no modify / no copy. People should be able to set different default permissions for the objects they create, that would encourage people to create Freebies or Open Source objects. See http://www.ipetitions.com/petition/secondlife-4freedom/index.html

2) Creators who sell their creations usually stick to either Copy / No trans or No copy / Trans. It's very easy for them to put wrong permissions on the objects they put on sale, and anyway it is a tedious task to set them manually.

3) Professional builders working in teams are hindered by the fact that the newly created objects are not "share with group" (even though the object's group is correctly set upon creation to their active group). This class of people too should be able to set the default permissions of the newly created objects to "share with group", instead of manually fixing that permission for every object they create. That would make team work easier.

Details :
=====

It seems there are technical ways to add this new feature on the viewer side only, but that they are inelegant.

The simplest way to implement this new feature is probably to extend the ObjectAdd message built on the client side, so that it sends the desired permissions along with the object's geometrical characteristics.

What should be done on server side ?
========================

Upon reception of an ObjectAdd message, decode the requested permissions and apply them to the newly created object.
Set these permissions in the ObjectProperties message that is sent back to the viewer. That will ensure that the object edition dialog is updated correctly and shows the correct initial permissions.

A patch for the client side is available
========================

The new "Edit => preferences" settings, as well as the construction of the new fields of the ObjectAdd message in the client, are provided in a patch attached to the client-side issue VWR-8049 .

This patch reuses the existing "ObjectFlags" field to convey the new information in the ObjectAdd message, by adding the following new flags:

const U32 FLAGS_SHARE_WITH_GROUP;
const U32 FLAGS_EVERYONE_COPY;
const U32 FLAGS_NEXT_OWNER_MODIFY;
const U32 FLAGS_NEXT_OWNER_COPY;
const U32 FLAGS_NEXT_OWNER_TRANSFER;

Of course this is not the only way to implement it, the client-side patch is just a proposal and a proof of concept.

Description

Purpose : ====== Allow users to set different default permissions for the objects they create. Rationale : ======= 1) The current contents creation model of Second Life is a propriétary model, because default permissions are not copiable / no copy / no modify / no copy. People should be able to set different default permissions for the objects they create, that would encourage people to create Freebies or Open Source objects. See http://www.ipetitions.com/petition/secondlife-4freedom/index.html 2) Creators who sell their creations usually stick to either Copy / No trans or No copy / Trans. It's very easy for them to put wrong permissions on the objects they put on sale, and anyway it is a tedious task to set them manually. 3) Professional builders working in teams are hindered by the fact that the newly created objects are not "share with group" (even though the object's group is correctly set upon creation to their active group). This class of people too should be able to set the default permissions of the newly created objects to "share with group", instead of manually fixing that permission for every object they create. That would make team work easier. Details : ===== It seems there are technical ways to add this new feature on the viewer side only, but that they are inelegant. The simplest way to implement this new feature is probably to extend the ObjectAdd message built on the client side, so that it sends the desired permissions along with the object's geometrical characteristics. What should be done on server side ? ========================

Upon reception of an ObjectAdd message, decode the requested permissions and apply them to the newly created object.
Set these permissions in the ObjectProperties message that is sent back to the viewer. That will ensure that the object edition dialog is updated correctly and shows the correct initial permissions.

A patch for the client side is available ======================== The new "Edit => preferences" settings, as well as the construction of the new fields of the ObjectAdd message in the client, are provided in a patch attached to the client-side issue VWR-8049 . This patch reuses the existing "ObjectFlags" field to convey the new information in the ObjectAdd message, by adding the following new flags: const U32 FLAGS_SHARE_WITH_GROUP; const U32 FLAGS_EVERYONE_COPY; const U32 FLAGS_NEXT_OWNER_MODIFY; const U32 FLAGS_NEXT_OWNER_COPY; const U32 FLAGS_NEXT_OWNER_TRANSFER; Of course this is not the only way to implement it, the client-side patch is just a proposal and a proof of concept.

Show »

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

catherine pfeffer added a comment - 24/Sep/08 03:20 AM

Update on the client side patch
====================

If having the User Interface for those settings in Edit => preferences is not okay, we could of course move it to a new floater in the "tools" menu.

We could also share the default settings with the default settings for the new feature "inworld bulk permissions change".

Update on the server side changes
======================

I am currently investigating the changes that would be needed for the new creations that are done directly in the inventory folder and in appearance mode (clothing, body parts, notecards, scripts, etc.), i.e. not inworld.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 24/Sep/08 07:47 AM

Considering that permissions are a full 32bit mask, you suggestion to mooch bits from the flag field is not a good idea. Your solution just doesn't scale. A better solution is to properly support permissions.

[ Permlink | « Hide ]

catherine pfeffer added a comment - 25/Sep/08 12:11 AM

Probably, yes.

Honestly, I don't care whether we reuse the flags field or introduce a new field.

[ Permlink | « Hide ]

catherine pfeffer added a comment - 30/Nov/08 03:17 PM

I have attached to VWR-8049 a new patch named "inworld.patch" that takes Strife's criticism into account.

The old ObjectFlag field is left alone and not changed. Three new fields are added to ObjectAdd message after ObjectFlag field:

{ GroupMask U32 } { EveryoneMask U32 } { NextOwnerMask U32 }

If needed, base and owner masks can be sent as well, but is it really needed for new objects ? We know for sure that these two masks always contain PERM_ALL .

[ Permlink | « Hide ]

catherine pfeffer added a comment - 30/Dec/08 02:00 PM - edited

Coco Linden expressed criticism too. She told me that the old message system was "frozen" and could not be changed.

The solution is to switch ObjectAdd to the new capabilities system.

The new client-side patch "inworld.patch" takes this remark into account. It is attached to issue VWR-8049.

[ Permlink | « Hide ]

catherine pfeffer added a comment - 05/Feb/09 02:44 AM

I'm attaching the LLSD dump of an example of the new ObjectAdd packet using capabilities
and with the new permission fields.

[ Permlink | « Hide ]

Andrew Linden added a comment - 13/Mar/09 04:17 PM

As far as I can tell it would be possible to use some bits in the legacy ObjectAdd::AddData::AddFlags field. At frist glance the "object flags" in object_flags.h appear to be full, however a few of those flags are no longer used, and the majority of them are actually used for the ObjectUpdate messages from simulator to viewer. That is, within the context of ObjectAdd most of those flags are meaningless (the exceptions are FLAG_USE_PHYSICS and FLAGS_CREATE_SELECTED, which are used in both directions).

ObjectAdd does not yet have a caps implementation server-side.

[ Permlink | « Hide ]

Andrew Linden added a comment - 13/Mar/09 05:03 PM

I've got a simulator change that will enable custom default permissions when rezzing new prims, if the proper bits are set in the ObjectAdd::AddData::AddFlags field. If this passes review then I'll be committing to the maint-server-8 branch and I'll come back here with some comments about how to take advantage of it should it ever get deployed.

The server-side changes necessary for scripts (VWR-12121), notecards (VWR-12122), and wearables (VWR-12123) are each different. I looked into how to do it for scripts and got lost in the convolutions of the code (it is end-of-day Friday and my brain is fried). But I'll try to keep those projects in mind.

[ Permlink | « Hide ]

catherine pfeffer added a comment - 16/Mar/09 03:06 PM

Hi Andrew,

It's nice you hade time to look at this .

> As far as I can tell it would be possible to use some bits in the legacy ObjectAdd::AddData::AddFlags field.

That was my first intention, but people told me the capabilities were the way to go, so the current patch (client-side) attached to VWR-8049 does caps.

But if you really want to go the UDP way, I can add the necessary bits to the client side patch which would then do both UDP and CAPS.

> ObjectAdd does not yet have a caps implementation server-side.

Sure, that's what this jira was requesting, being given that everyone judged my initial idea of reusing existing flags in the UDP packet was ugly .

For your information, there is already a caps implementation for opensim running and tested with my client-side patches.

> I've got a simulator change that will enable custom default permissions when rezzing new prims, if the proper bits are set in the ObjectAdd::AddData::AddFlags field.

Cool (if UDP is the way to go).

> The server-side changes necessary for scripts (VWR-12121), notecards (VWR-12122), and wearables (VWR-12123) are each different.

It's different problems client-side too. Coco Linden already implemented everything with respect to "File => Upload" side of the problem. Next step was inworld object creation, for which we needed those ObjectAdd server side changes.

> I looked into how to do it for scripts and got lost in the convolutions of the code (it is end-of-day Friday and my brain is fried). But I'll try to keep those projects in mind.

Believe me, it's very different problems, let's do them once at a time.

items uploading is already done client-side and server-side and AFAIK it is scheduled for 1.23 client
inworld creation is what we are currently speaking about and is ready client-side for caps
in-inventory creation is ready client-side and even tested with success but probably needs more work (server side too)
in-object creation (scripts) has not been started yet
client-side GUI is ready, and even in several versions for you lindens to choose from

You'll find all the many client-side patches attached to VWR-8049.

I'll be able to do your UDP message tweaks client-side, if you confirm that you don't want to go the caps way server-side. Just tell me and i'll do the work.

Perharps it would be a good idea too for you to have a chat with Coco Linden who already knows the problem well.

Anyway I'm happy you jumped into this

[ Permlink | « Hide ]

Prokofy Neva added a comment - 04/May/09 10:44 AM

Re: "I've got a simulator change that will enable custom default permissions when rezzing new prims, if the proper bits are set in the ObjectAdd::AddData::AddFlags field"

Andrew, can you explain what you are doing with this, how the objects will rez in world, whether you mean something will have to change about the core way the server has always read objects.

Also, I'd invite you to think about what's really going on here, which is an assault on copyright, and smuggling in a copyleftist regime into the tools by forcing mass perms on objects under the notion of "builder convenience" for a tiny subset of residents.