| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
the OwnerRoleID in the groups table was inconsistent with the roleID in the roles table. OpenSim core was not running into this bug, but 3rd party modules (like Wifi) were.
|
|
|
|
|
|
|
| |
a threadpool) via Watchdog.RunInThread() rather than Util.RunThreadNoTimeout()
The functionality is the same but this allow us to monitor such tasks via "show threads" and abort them for test purposes, etc.
Also extends thread names to provide more info (e.g. SendInitialDataToClient says what client the task is for).
|
|
|
|
|
|
| |
neighbour) don't resend all the initial avatar and object data again.
This is unnecessary since it has been received (and data continues to be received) in the existing child connection.
|
|
|
|
|
|
|
| |
not have sufficient permission, return null failure result rather than true.
On non-HG this is on the only recognized failure state so we can return more information in the error result.
On HG there are multiple failure states which would require more work to distinguish, so currently return the unsatisfying "Internal Error" like some other existing calls.
|
|
|
|
| |
REMOVEAGENTFROMGROUP call has failed because of missing parameters
|
|
|
|
|
|
| |
a ServiceLocation would set the group name to an empty string.
This should set the ServiceLocation to an empty string instead.
|
|
|
|
|
|
| |
When sending an ImprovedInstantMessage to a group, the IM's binary bucket is supposed to contain the group's name (this is what SL does). Singularity uses this to show the group name when it shows the message at the bottom of the viewer for a few seconds: "[Group Name] From User: Message". Before this update, the group name was empty ("[]").
This update doesn't have any visible effect in Firestorm, because it doesn't use the group name sent in the IM.
|
| |
|
| |
|
| |
|
|
|
|
| |
which logs every request it receives.
|
| |
|
|
|
|
|
|
| |
an exception when the service tried to read the data later on.
Signed-off-by: Oren Hurvitz <orenh@kitely.com>
|
|
|
|
| |
when sending group messages, not just those after get group members and get presence status, as applicable
|
|
|
|
|
|
|
|
|
| |
that of the groups module.
This is to allow us to get useful information on messaging without being overwhelmed by the rest of groups debug.
Enabled with [Groups] DebugMessagingEnabled = true in config (default false)
Or "debug groups messaging verbose true|false on the console" (similar to existing groups setting).
Done for both xmlrpc and V2 groups.
|
|
|
|
| |
does not contain any mandatory parameters and won't be present on older installations.
|
|
|
|
| |
of xmlrpc and core offline IM modules
|
| |
|
|
|
|
| |
This allows for more secure group services, to be used by collections of mutually-trusting grids.
|
| |
|
|
|
|
| |
- Changed a few places that launch long-lasting threads to skip the timeout altogether
|
|
|
|
|
|
| |
"debug" options to appear in "help")
This is a (small) part of http://opensimulator.org/mantis/view.php?id=6949
|
|
|
|
| |
Resolves http://opensimulator.org/mantis/view.php?id=6937
|
|
|
|
| |
This resolves http://opensimulator.org/mantis/view.php?id=6936
|
|
|
|
|
|
|
|
| |
use for fetching group data to be different from im.fromAgentID
This is because xmlrpcgroups currently always checks visibility for the requesting agent ID (unlike Groups v2, which can accept UUID.Zero)
But group notice IMs have a from agent which is the group rather than the sending agent.
Further addresses http://opensimulator.org/mantis/view.php?id=7037
|
|
|
|
|
|
|
|
| |
group chat to avoid timeout issues when sending messages to large groups.
Only implementing for XmlRpcGroups initially to test.
May require MessageOnlineUsersOnly = true in [Groups] to be effective.
In relation to http://opensimulator.org/mantis/view.php?id=7037
|
|
|
|
|
|
|
| |
UpdateGroup() do not have a RESULT parameter in the result message, return null rather than fail with NullReferenceException
This check was already done by other methods.
Looks to resolve http://opensimulator.org/mantis/view.php?id=7012
|
|
|
|
| |
This is useful if the user is deleted.
|
|
|
|
| |
This data is useful for preventing abuse (e.g., someone who sends too many messages), or for deleting message if their sender has been deleted.
|
| |
|
|
|
|
| |
Thanks to Kira for this patch from http://opensimulator.org/mantis/view.php?id=6845
|
| |
|
| |
|
|
|
|
| |
user if no GroupsServerURI has been given in user data by the home grid
|
|
|
|
|
|
|
| |
event queue.
I think there is an argument for sending this information to NPCs anyway since in some cases it appears a lot easier to write server-side bots by hooking into such internal events.
However, would need to stop event messages building up on NPC queues if they are never retrieved.
|
|
|
|
| |
the fields get messed up because the transfer is async
|
| |
|
| |
|
| |
|
|
|
|
| |
instead of "all" because some paths in the code assume there's a UUI in the RequestingAgent string.
|
| |
|
| |
|
|
|
|
| |
for group chat.
|
| |
|
|
|
|
| |
handler from both Groups modules in core, and replaced them with an operation on IGroupsModule.
|
| |
|
|
|
|
| |
or else they'll see an echo of their own messages after teleporting.
|
| |
|
|
|
|
|
|
| |
join/drop appropriately, invitechatboxes.
The major departure from flotsam is to send only one message per destination region, as opposed to one message per group member. This reduces messaging considerably in large groups that have clusters of members in certain regions.
|