Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008777opensim[GRID] Other Servicepublic2020-10-08 08:152020-11-19 07:01
ReporterManwa Pastorelli 
Assigned Totampa 
PlatformLinuxOperating SystemUbuntuOperating System Version20.04
Product Version 
Target VersionFixed in Versionmaster (dev code) 
Summary0008777: 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 Reproduce1. 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

    touch_start(integer any)

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.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script EngineXEngine
EnvironmentMono / Linux64
Mono Versiontrunk
ViewerFirestorm 6.4.5 (60799)
Attached Files

- Relationships

-  Notes
tampa (reporter)
2020-10-08 08:39

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.
BillBlight (developer)
2020-10-08 09:23
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.

BillBlight (developer)
2020-10-08 09:27

Updated ossl function page to make it more clear as to how it currently works.
UbitUmarov (administrator)
2020-10-08 13:17

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)
2020-10-08 15:22

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.
UbitUmarov (administrator)
2020-10-08 16:26

object owner current active powers dependency should now be gone on this case at master.
tampa (reporter)
2020-10-09 02:10
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.

UbitUmarov (administrator)
2020-10-09 04:25

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.
tampa (reporter)
2020-10-09 07:22

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.
UbitUmarov (administrator)
2020-10-10 07:45

a bit confusing on a prim you may leave on terrain no?

- Issue History
Date Modified Username Field Change
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
2020-11-19 07:01 tampa Status new => resolved
2020-11-19 07:01 tampa Fixed in Version => master (dev code)
2020-11-19 07:01 tampa Resolution open => fixed
2020-11-19 07:01 tampa Assigned To => tampa

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker