QELBot

  • Status New
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category Bot
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 0.10.0045
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: QELBot
Opened by Krayon - 2010-11-15

QB#85 - Add bot access lists

Trac Ticket #74 - Originally reported by: Korrode

requesting the ability to have people in the “Guild” list have a “GuildAdmin” settable option, and when turned on, they have access to bot’s “say” command, but no other normal admin features.

(very useful for a guild with multiple guild masters that need access to rank 20 ability, but are not all owners of the bot, or using it to sell their wares).
Admin
Krayon commented on 2010-11-15 11:18

Comment by: Krayon

This would be best implemented using some kind of access list. Be this "access levels" (not my preference) or a case by case basis, ie Person A can have READ access to features 5, 11 and 14 and READ/WRITE access to features 6, 12 and 13. While this seems complex on the surface, if the interface is done right it can be intuitive will still being COMPLETELY flexible.

No time frame as yet.
Admin
Krayon commented on 2010-11-15 11:39

Comment by: Krayon

For ease of displaying and use, I think a permissions "tab" for the WebAdmin screen would be the best choice. It would display as follows:

Area(s) Group/Player Name Permissions
Area list None, All, Owner, Admins, Guildies, Players Player Name(s) (if "Players" selected) None, Read Only, Read/Add, Read/Modify, Read/Add/Modify, Execute

The Area list would be a list of areas you could have access to. It could be tabs (General, Admins etc) or even items within tabs (General→Owner). You could probably select more than 1 to define them together.

The Group concept could also be expanded if needed to allow for a group definition. This would allow for you to define a group of people, and refer to them as that group. If this were the case, in the above Group/Player section, you would select group and enter the name in the Name section. This would probably be overkill however, as specially since you can just enter a list of players in the Name section anyway.

Provided EL does not allow commas (,) in names, it will most likely be the separator for lists such as for names of players.

With a standard access list like this, you define a default set (in the case most likely None for everything) and you also define how conflicts are resolved. Conflict resolution will most likely be hard coded to always err on the side of caution. Basically if a rule granting access for a player is in contradiction with a rule denying access for that player, they will be DENIED.

A simple excerpt for an example:

Area(s) Group/Player Name Permissions
WebAdmin→Guild Admins - Read/Add/Modify
WebAdmin→Guild Guildies - Read Only
WebAdmin→Admin Admins - Read Only
WebAdmin→Admin Players Korrode, Krayon Read/Add/Modify
Bot→Say Owner - Execute
Bot→Say Players Bob, Joe Execute
Bot→Help All - Execute


As this might be confusing to some, an English summary could then be displayed:

  • All players can execute the "help" command.
  • Only Korrode (Owner) and players Bob and Joe can execute say command.
  • Only Korrode, Fallen, John, Paul, George and Ringo (Admins) can view the Admins list.
  • Only Korrode and Fallen can modify/remove or add from/to the Admins list.
  • Only Korrode, Sam and Joe can view the Guild list.
  • Only Korrode, Fallen, John, Paul, George and Ringo (Admins) can modify/remove or add from/to the Guild list.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing