Group Owned Change Links Question

To change links using scripts, requires you to call llRequestPermissions from the owner, thus you usually call:

llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS);

However, when your object is group owned, llGetOwner() returns the group UUID, thus I assume llRequestPermissions(groupUUID,PERMISSION_CHANGE_LINKS); requests permissions from no one. Is this true? Otherwise, what do I set as the key for llRequestPermissions()? Or is there another way to achieve this?

Thanks.

Most instances of llRequestPermissions require an avatar to click a dialog button to actively approve a change. If the object is owned by a group, that's not possible. You'll have to buy the object back from the group to make the permitted change yourself. Unless there's a good reason for the object to be group-owned, however, you might instead consider scripting a white list of people who are allowed to make changes. Write a function like this ...

integer isNameOnList( list list_name, string name )
{
    integer len = llGetListLength( list_name );
    integer i;
    for( i = 0; i < len; i++ )
    {
        if( llList2String(list_name, i) == name )
        {
            return TRUE;
        }
    }
    return FALSE;
}

and then, if (isNameOnList(whitelist,avname)) you go ahead and request permission.

Yeah, since I am working on a project with a number of people, group permissions is a must.

However, I should have specified that what I am trying to do is, have multiple centers of rotation for an object.

Since objects rotate around the root, the two possible solutions I came up with were:
1) Move just the root, unfortunately there is no way to do this in Second Life and I don't know why?

2) Have multiple prims for the centers of rotation, however as this post suggests, there seems to be no way to request PERMISSION_CHANGE_LINKS permissions on group owned objects.

Imagine yourself tipping forward, backward, left, right. Each of these rotations involve different centers of rotation. In tipping forward, the center of rotation is your toes; tipping backward, the center of rotation is your heels...

/me thinks that is correct.

Like with debit permissions, change links is only valid on the owner of the object and you can't request that of the group.

Can't you check if the avatar is in the same group, and if they are, request permissions based on their key?

I think link permissions only works on the owner of the object. With deeded objects, the owner is the group they're deeded to - requesting permissions on an avatar, even if that avatar is in the group, won't work.

This seems like a bug rather than a new feature to me. I'd report it on jira, but the site seems to be down.

This seems like a bug rather than a new feature to me. I'd report it on jira, but the site seems to be down.

That won't work, Vance, because only the owner of an object can grant permission to change links. A group can't push the "Yes" dialog button to grant permission. That's the problem with my whitelist suggestion too. If the OP were trying to do anything that didn't require the permission of a specific person, your solution and mine would work. As it is, the only solution I can think of is to make the object mod/transfer and set it for sale at L$0, then script it so that only a group member can buy it. Then transfer ownership from one person to another as different group members want to use it. It's a clunky solution, but it's the only way I can think of to let different people grant CHANGE_LINKS permission at different times.

Yes.. The squids on wiki.sl.com are unhappy today..

It's not really a bug. If you don't own something, you shouldn't be allowed to grant permissions to modify its link set. If you deed an object, you're reassigning ownership to the group.

It's not a bug. The llRequestPermissions function is working the way it's supposed to ... just not the way you want it to. PERMISSION_CHANGE_LINKS and PERMISSION_DEBIT are designed to make it impossible for anyone to property without the owner's active knowledge. Opening the door for people to change your objects or your bank account without your explicit permission would raise all sorts of security issues. You could argue that LL should create a new PERMISSION_CHANGE_GROUP_LINKS maybe, but I can imagine security concerns there as well (Should some group members -- the owners -- have more liberal permission than others... ? ).

ETA: LOL... What Meade said .... with fewer words

Jesse Barnett once told me off in this forum (in the nicest possible way, of course) for bothering to write a function when, as would be the case when you're detecting names, you don't have to worry about partial matches and the like. What is wrong, she asked me, with just saying something like

if(~llListFindList(whitelist,[avname])){
// do stuff
}

I agree with you that there is no bug in llRequestPermissions, but to label this as a "New Feature" is wrong, since this is not a new feature, but rather a "Missing Feature". To me a new feature is a feature that would be nice to have, not one that the designers failed to consider. Additionally, does anyone even bother to take a look at "New Features", I have voted on many that were quite old, had many votes, and had not been assigned to anyone.

On the other hand, I think it would be easier to implement a method that moves just the root prim, and this would solve my issue aswell.

Yeah, that's a wish list. The catch in the system is that nobody is "assigned" a job from that list at all. It's my understanding that LL's techies choose their own projects. An item can sit on the wish list for years if nobody in house is interested.

You don't mean "move" physically, do you? You mean "change which prim is the root," right? I really have no idea how linked objects are defined in the servers, but I can't imagine that it would be a trivial matter to say that prim #5 is the root instead of prim #1. I'll leave that to someone with a deeper understanding of such things.

Hmmmm, maybe I should look into becoming an LL techy.



Actually, I did mean physically move the root prim within a linked set. The link posted, indicates a situation of a bug where the root prim was moving on its own, thus I can see this as being possible.

It seems like there should be a property you can set in a group role that sort of translate to "treat persons in this role as owners of group objects" (at the very least for the purpose of requesting permissions, if nothing else).

JIRA it up. I'll vote.

You can certainly give group members permission to rez, modify, or delete objects already. That still doesn't get around the problem that llRequestPermissions(PERMISSION_CHANGE_LINKS) throws up a dialog box that requires the person with the owner's key to click "Yes." The owner of a group object is not a person. If you do llGetOwner(), you get the group key, so there's nobody to see or click on a dialog button. As Meade pointed out earlier ...

I haven't tried this, but can't you use llSetLinkPrimitiveParams([PRIM_POSITION]) to do that?

Thanks for the suggestion, but unfortunately it doesn't. This would seem to be intuitive though.

Shame. It seemed like such a clear shot.....