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

catherine pfeffer made changes - 10/Sep/08 12:38 PM

Field	Original Value	New Value
Link		This issue Relates to VWR-8049 [ VWR-8049 ]

catherine pfeffer made changes - 14/Sep/08 10:56 AM

Comment

[ New message format would look like:

{
        ObjectAdd Medium NotTrusted Zerocoded
        {
                AgentData Single
                { AgentID LLUUID }
                { SessionID LLUUID }
                { GroupID LLUUID }
                { NextOwnerMask U32 } // new field: desired permissions
                { GroupMask U32 } // new field: desired group flags, including "share with group"
        }
        etc...
}
]

catherine pfeffer made changes - 14/Sep/08 11:07 AM

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 no conpy / no transfer / no modify. 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) 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.

It looks like the simplest way to implement this new feature is to extend the ObjectAdd message built on the client side in linden/indra/newview/lltoolplacer.cpp, 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.

We would take care of coding the user interface for the new "Edit => preferences" settings + the construction of the new fields of the ObjectAdd message in the client.

(*) the idea is to get the newly created object in the llSelectionManager, get the llViewerInventory and then set the llPermissions on it. But that sounds like an ugly hack, and it could also have bad side effects.

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 no conpy / no transfer / no modify. 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) 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 in linden/indra/newview/lltoolplacer.cpp, 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.

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

The new "Edit => preferences" settings, and 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] .

catherine pfeffer made changes - 14/Sep/08 11:07 AM

Comment

[ Implementation details
==============

Perharps the simplest way is to reuse the existing "ObjectFlags" field for this information.

I suggest to create new flags :

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

in linden/indra/llprimitive/object_flags.h.
]

catherine pfeffer made changes - 14/Sep/08 11:11 AM

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 no conpy / no transfer / no modify. 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) 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 in linden/indra/newview/lltoolplacer.cpp, 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.

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

The new "Edit => preferences" settings, and 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] .

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 no conpy / no transfer / no modify. 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) 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 in linden/indra/newview/lltoolplacer.cpp, 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.

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

The new "Edit => preferences" settings, and 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 for the new information conveyed in the ObjectAdd message, by adding the following new flags :

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

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

catherine pfeffer made changes - 15/Sep/08 12:15 AM

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 no conpy / no transfer / no modify. 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) 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 in linden/indra/newview/lltoolplacer.cpp, 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.

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

The new "Edit => preferences" settings, and 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 for the new information conveyed in the ObjectAdd message, by adding the following new flags :

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

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

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) 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.

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.

catherine pfeffer made changes - 15/Sep/08 03:01 AM

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) 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.

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.

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.

2) 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.

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.

catherine pfeffer made changes - 15/Sep/08 03:01 AM

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.

2) 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.

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.

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.

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.

catherine pfeffer made changes - 16/Sep/08 01:56 AM

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.

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.

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.

catherine pfeffer made changes - 19/Sep/08 12:57 AM

Link

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

catherine pfeffer made changes - 19/Sep/08 01:00 AM

Link

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

Sue Linden made changes - 13/Nov/08 12:06 PM

Workflow

jira-2007-12-22a [ 59023 ]

jira-2008-11-14 [ 81352 ]

Sue Linden made changes - 13/Nov/08 04:33 PM

Workflow

jira-2008-11-14 [ 81352 ]

jira-2008-11-14a [ 88079 ]

Sue Linden made changes - 13/Nov/08 04:56 PM

Workflow

jira-2008-11-14 [ 88079 ]

jira-2008-11-14a [ 95810 ]

catherine pfeffer made changes - 05/Feb/09 02:44 AM

Attachment

dump.txt [ 21821 ]

lindenrobot made changes - 23/Feb/09 04:03 PM

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