Bukkit

Note: this only applies to ScrollingMenuSign v2.0.0 and later.

ScrollingMenuSign features a flexible access control mechanism, allowing for permission-based control, private menus and views, and group-based menus and views (the latter requiring Vault).

All views and menus have an owner, group and access attribute:

• owner is the name of the player who owns the view or menu. By default, it's the player who created the entity, or [console] if it was created on the console.
• group is the permission group for this view or menu. By default it's empty - it is only checked if the access attribute is set to GROUP.
• access may be one of ANY, OWNER, GROUP or OWNER_GROUP. By default, it is ANY.

Both attributes can be changed as follows:

/sms menu <menu-name> owner <new-owner>
/sms menu <menu-name> access <ANY|OWNER|GROUP|OWNER_GROUP>
/sms view <view-name> owner <new-owner>
/sms view <view-name> access <ANY|OWNER|GROUP|OWNER_GROUP>

How Access Control Is Carried Out

When a player tries to scroll or execute a menu, the following checks are made:

• Ensure the player has scrollingmenusign.scroll and/or scrollingmenusign.execute (and scrollingmenusign.execute.elevated for menu items with permission-elevated commands)
• Ensure the player is allowed to use this view type by checking for the scrollingmenusign.use.<type> permission node, e.g. scrollingmenusign.use.map is needed to use a map view.
• If the player has the scrollingmenusign.access.any permission node (by default, requires op or the scrollingmenusign.admin node), then they are allowed to proceed; no further checks needed.
• If the view's access attribute is ANY, then the view is usable by any player regardless of ownership.
• If the view's access is OWNER, then only the view's owner may use it.
• If the view's access is GROUP, then any player who is in the view's group permission group may use it. This requires Vault and a correctly-configured permissions plugin.
• If the view's access is OWNER_GROUP, then any player who is in the owner's primary permission group may use it. This also requires Vault and a correctly-configured permissions plugin.
• The exact same checks are made for the view's menu.

Example

/sms create mymenu &1My Menu
/sms add mymenu One "\\you clicked One"
/sms give map mymenu
# place a sign in the world, look at it, and type:
/sms sync mymenu

This creates a menu and a map view on that menu, giving you a map for that view. It also creates a sign view for the menu.

/sms menu mymenu
/sms view mymenu-1

These two commands will show you the current owner (your player name) and access (ANY) for the menu and view.

/sms menu mymenu access OWNER

Now only you (or an admin with the scrollingmenusign.access.any permission node) will be able to scroll or execute that menu, regardless of the view (map, sign or otherwise) they try to use.

/sms menu mymenu access ANY
/sms view mymenu-1 access OWNER

Now anyone will be able to use the sign to scroll & execute your menu, but only you will be able to use the map. If you give the map to someone else, it won't work for them.

Access Control for Menu/View Modification

To change any aspect of a menu or view (editing menu/view attributes, adding/removing/editing menu items, creating/deleting views, or deleting the menu), you must either:

• Be the owner of the view/menu you're modifying OR
• Have the scrollingmenusign.edit.any permission node. By the default this node requires op or the scrollingmenusign.admin node.

In addition, you must have the scrollingmenusign.edit.any to change the ownership of view or menu, even one that you currently own. Only admins should be able to change the ownership of SMS entities.