|Anonymous | Login | Signup for a new account||2020-10-28 22:07 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008777||opensim||[GRID] Other Service||public||2020-10-08 08:15||2020-10-10 07:45|
|Target Version||Fixed in Version|
|Summary||0008777: osInviteToGroup not functioning as documented|
Not sure if this is a documentation issue or an actual bug.
On the wiki, it states "The object owner must have the right to invite new users to the group the object is set to"
However, this is not enough, the role the object owner has active at the time object is set to the group must have the right to invite to a group.
This function fails if the object owner is the owner of a group, but has a group without invite rights active when the object is set to the group. Adding invite rights to that role retrospectively does not work. The object needs to be set to another group and set back again before this function works.
I suspect this is a bug rather than documentation, since the process is very counter intuitive.
|Steps To Reproduce||1. Create a group, |
2. set your avatar to the everyone role (a role without invite rights)
3. Build a box, set the box to your new group.
4. Add the following script
5. Use another avatar to click the box you just made. It will not work.
6. Change your avatar to the owners role, and try again, once more it will fail.
7. Now change the box to another group and back to your new group.
8. Try clicking with your 2nd avatar again, this time the invite will arrive.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||Mono / Linux64|
|Viewer||Firestorm 6.4.5 (60799)|
Only looked briefly, but it seems the check is done when the group is set to the object and it retains the group along with some additional information for the time the simulator is running(couldn't find that it enters this information to the prim data). So that you have to switch groups for this to update is the only way to make it fetch new group data, cause it cannot know of the change, you'd have to tell it somehow, which is a big can of worms. Either group or object would need to check for changes and that's no good, adds overhead, complexity.
I suspect it using the permissions you have at the time rather the max possible is meant to serve to be predictable, I would not expect it to always probe and see if there were more permissions available than the one I have selected currently. It would also add quite a bit of complexity to check the group for all the roles rather than just the selected one, though that could be added fairly easily still. You'd have to probe all roles the user has and check which has the most elevated permissions relevant to objects and then select them, but this means you always have the object group perms no matter which role you select giving you no way to "restrict" an object by using a lower role.
edited on: 2020-10-08 09:35
Seems to me if you are going to create an object that says you must have invite to group perms, you might want to have those before you create the object, not after the fact ..
I'd have to agree with Tampa here, seems like a lot of unneeded overhead to check the roles every time someone clicks the object.
|Updated ossl function page to make it more clear as to how it currently works.|
No, there is no time relation between object creation and group membership roles, except possible groups information caching, those may cause temporary change.
if there is a issue, then it maybe elsewhere like the invite processing
add a llSay to see the return value..
Manwa Pastorelli (reporter)
I added an llSay as suggested
Owner Of the group owns the prim, but their group tag (role) is set to everyone (which does not have invite permisions). The object is set to the group at this point.
Result: The bool is FALSE (0).
Case2: Same group, with the same avi, after changing their avi's group role to owners, changed the prims group to another group then back again.
Result: The bool is TRUE (1) and the invite is received by the clicking avatar.
|object owner current active powers dependency should now be gone on this case at master.|
edited on: 2020-10-09 07:18
That creates the new issue of being unable to test role permissions. I now can't verify as group owner that another role can't eject people from my group.
so no point on the patch.
this functions are not to check role powers. That is done on groups management via UI
Many group powers like this are active if user is member of any role with it.
|The patch was to allow switching to the old method that did not check full permission set but only current selected role in case someone may want to test a lesser roles permissions, but fine, removed the patch.|
|a bit confusing on a prim you may leave on terrain no?|
|2020-10-08 08:15||Manwa Pastorelli||New Issue|
|2020-10-08 08:39||tampa||Note Added: 0036916|
|2020-10-08 09:23||BillBlight||Note Added: 0036917|
|2020-10-08 09:27||BillBlight||Note Added: 0036918|
|2020-10-08 09:35||BillBlight||Note Edited: 0036917||View Revisions|
|2020-10-08 13:17||UbitUmarov||Note Added: 0036919|
|2020-10-08 15:22||Manwa Pastorelli||Note Added: 0036920|
|2020-10-08 16:26||UbitUmarov||Note Added: 0036921|
|2020-10-09 02:10||tampa||Note Added: 0036922|
|2020-10-09 02:17||tampa||File Added: Elevate-Group-Permission-config.patch|
|2020-10-09 02:18||tampa||Note Edited: 0036922||View Revisions|
|2020-10-09 04:25||UbitUmarov||Note Added: 0036923|
|2020-10-09 07:18||tampa||File Deleted: Elevate-Group-Permission-config.patch|
|2020-10-09 07:18||tampa||Note Edited: 0036922||View Revisions|
|2020-10-09 07:22||tampa||Note Added: 0036924|
|2020-10-10 07:45||UbitUmarov||Note Added: 0036925|
|Copyright © 2000 - 2012 MantisBT Group|