| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
It's a valid configuration not to have these modules, but I think it's still worth logging the fact that certain permissions won't work (always return true)
|
|
scattering them over other categories
|
|
because checking EstateOwner == user
Due to an earlier check we already know that user != UUID.Zero so if EstateOwner == UUID.Zero, EstateOwner == user can never be true
|
|
affect the starting position in the destination region.
|
|
EstateSettings.IsEstateManagerOrOwner() to reflect what it actually does.
This makes it consistent with other parts of OpenSimulator that are treating ESTATE_MANAGER and ESTATE_OWNER as different entities.
As per opensim-dev mailing list.
|
|
for granting rights via a module call.
Rename IFriendsModule.GetFriendPerms() -> GetRightsGrantedByFriend() to be more self-documenting and consistent with friends module terminology.
Add some method doc.
|
|
|
|
DEFAULT. Turns out that this can't be expressed by cascading Permission modules, so I did it as per this patch."
This reverts commit 6146e7ef258b10888ad7464b72b75cca701e02c9.
|
|
Turns out that this can't be expressed by cascading Permission modules, so I did it as per this patch.
|
|
<category/module>" to display commands in a category.
This is to deal with the hundred lines of command splurge when one previously typed "help"
Modelled somewhat on the mysql console
One can still type help <command> to get per command help at any point.
Categories capitalized to avoid conflict with the all-lowercase commands (except for commander system, as of yet).
Does not affect command parsing or any other aspects of the console apart from the help system.
Backwards compatible with existing modules.
|
|
This fixes the problem by fixing the permissions module to look at root part permissions rather than having to do this for every caller.
Resolves http://opensimulator.org/mantis/view.php?id=5569
|
|
if the current user is the owner of an object. none of the later
checks can reverse the outcome.
|
|
created in that client session, or if no other action has been performed on the object.
There were two problems here:
1) On object group update, we looked for the group is the IClientAPI group cache rather than in the groups service. This fails to groups created newly in that session
2) On object group update, we weren't setting the HasGroupChanged flag. This meant that the change was not persisted unless some other action set this flag.
This commit fixes these issues and hopefully addresses http://opensimulator.org/mantis/view.php?id=5588
This commit also moves HandleObjectGroupUpdate() to the GroupsModule from the Scene.PacketHandlers.cs file
|
|
|
|
FriendsModule.FetchFriendslist() asychronously.
Executing this asynchronously allows a race condition where subsequent friends fetches hit a cache that FetchFriendsList() had not yet populated.
Changing this to synchronous may improve issues where a user does not see friends as online even though they are.
I don't believe synchronous is a problem here, but if it is, then a more complicated signalling mechanism is required. Locking the cache isn't sufficient.
|
|
|
|
The only times when ParentGroup might be null is during regression tests (which might not be a valid thing) and when scene objects are being constructed from the database.
At all other times it's not possible for a SOP not to have a SOG parent.
|
|
|
|
user expectations.
It also matches the default setting in the OpenSim.ini.example file
|
|
FriendsData[] GetFriends(string principalID) to IFriendsData and FriendInfo[] GetFriends(string PrincipalID) to IFriendsService. Refactored some more in the FriendsModule. Made client get notification of local friends permissions upon HGLogin. HG Friends object permissions work.
|
|
of media permissions.
Media permissions are just meant to be checked when we want to know if a user should be shown the navigation bar or allowed to navigate. It should not be checked when we're setting the media up.
This bug was preventing a user from ever setting any more values if they had unchecked the owner settings.
|
|
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
|
|
|
|
|
|
|
|
|
|
copy would change both prims until server restart
I also found out that you can crash the current viewer by giving it more media entrys than it's expecting
|
|
|
|
serverside url whitelist checks
at the moment, only checking for the exact name prefix is implemented
for some reason, whitelists are not persisting
this commit also fixes a very recent problem where setting any media texture parameters after the initial configuration would not work
|
|
naughty clients
|
|
|
|
|
|
|
|
serverside url whitelist checks
at the moment, only checking for the exact name prefix is implemented
for some reason, whitelists are not persisting
this commit also fixes a very recent problem where setting any media texture parameters after the initial configuration would not work
|
|
naughty clients
|
|
|
|
|
|
|
|
|
|
route the permissions request through the existing CanEditScript() and CanEditNotecard() methods.
This implements the 'share with group' flag for notecards and scripts in prim inventory since the PermissionsModule checks group membership and permissions.
Other than that, the code in PermissionsModule duplicates the checks in LLClientView so there should be no change other than allowing group members to edit embedded notecards and scripts.
For all other asset types, the permission checking code in LLClientView continues to be used, pending refactoring of suitable permissions code
This means that 'share with group' will not yet work for prim inventory items other than notecards and scripts
|
|
the client's active group id
this resolves the earlier issue where notecards/scripts shared with group could only be edited if the user had that group active
|
|
|
|
|
|
really don't need two methods doing the same thing, but differently.
|
|
|
|
to use that stored value.
|
|
* Performance improvement in the expensive GenerateClientFlags()
|
