You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a solution that will allow the use of groups as well as players. I have done it this way to improve inheritance of groups.
when using the Permissions plugin:
Using PermissionHandler.inGroup(player, 'Default') will not return true for a player in "Admins" even if Admins is inherited from Default. (please correct me if I'm wrong, but my experience is that it doesn't.)
By adding a generic permission to a group, "group.<group_name>", it is possible to check for that permission with inheritance. Within MyWarp is is possible to invite a permissions group, or to give a warp to a group. However, since playerCanWarp and playerCanModify only check for a player by name, it will not map over and allow the action.
I propose the following changes as a fix. I have tested this on my own server and it seems to work well.
To Warp.java these edits:
public boolean playerCanWarp(Player player) {
if (creator.equals(player.getName()))
return true;
if (permissions.contains(player.getName()))
return true;
//amkeyte
if (WarpPermissions.isGroupMember(player, permissions))
return true;
if (WarpPermissions.isAdmin(player) && WarpSettings.adminPrivateWarps)
return true;
return publicAll;
}
public boolean playerCanModify(Player player) {
if (creator.equals(player.getName()))
return true;
//amkeyte
//give the warp to a group to allow them to modify it.
if (WarpPermissions.isGroupMember(player, creator))
return true;
if (WarpPermissions.isAdmin(player))
return true;
return false;
}
to WarpPermissions.java add these functions:
/**
* amkeyte
*
* checks if the player is a member of a group using the Permissions plugin.
*
* The player must be a member of a group that has been given the permission:
* group.<Group Name>
*
* This method of checking for group allows the permissions plugin to assign by inheritance.
*
* @param player
* @param permissions
* @return
*/
public static boolean isGroupMember(Player player, String groupName) {
String groupPermission = "group." + groupName;
if (permission(player, groupPermission)) {
return true;
}
return false;
}
/**
* amkeyte
* Overloaded from above.
*
* checks if the player is a member of a group in the list.
* Iterates each item in the list and checks if the player is in the group.
* players may invite a group to their warp just like they would a player.
*
* called by Warp.playerCanModify
*
* @param player
* @param permissions
* @return
*/
public static boolean isGroupMember(Player player, ArrayList<String> permissions) {
for (Iterator iter = permissions.iterator(); iter.hasNext();) {
if (isGroupMember(player, (String) iter.next())) {
return true;
}
}
return false;
}
You might decide to go with a more specific permission property, (mywarp.warp.group.<group_name>) but I like the more generic one, since this technique could be helpful in other plugins as well.
The text was updated successfully, but these errors were encountered:
I have a solution that will allow the use of groups as well as players. I have done it this way to improve inheritance of groups.
when using the Permissions plugin:
Using PermissionHandler.inGroup(player, 'Default') will not return true for a player in "Admins" even if Admins is inherited from Default. (please correct me if I'm wrong, but my experience is that it doesn't.)
By adding a generic permission to a group, "group.<group_name>", it is possible to check for that permission with inheritance. Within MyWarp is is possible to invite a permissions group, or to give a warp to a group. However, since playerCanWarp and playerCanModify only check for a player by name, it will not map over and allow the action.
I propose the following changes as a fix. I have tested this on my own server and it seems to work well.
To Warp.java these edits:
to WarpPermissions.java add these functions:
You might decide to go with a more specific permission property, (mywarp.warp.group.<group_name>) but I like the more generic one, since this technique could be helpful in other plugins as well.
The text was updated successfully, but these errors were encountered: