Possible improvements of Privilege level

[Graveen]

Hi,

I have coded an improvement for Privilege level. I simply need feedback about it, aka possible applications.

Actually, you have plvl 1,2 and 3, respectively player, GM and Admin. The system assumes a GM is a player, and an admin is both GM and Player.
This is exactly shown in most of the code, where checks are either equals to ePrivLevel.Player, or greater than. Assuming greater than ePrivLevel.Player is a gamemaster.
This is also exactly what is done in command handling, where de facto, a GM can use all player commands.

Idea 1)
Like Dre suggested 1 or 2 years ago, a system based on flags can be interesting, where you have strict attached rights to these flags. 3 flags (player, gm, admin) would each have their own rights, which are not cumulatives. It means if you are *only* GM, you can *only* do explicit GM stuff. But as you can be flaggued multiple times, you can both be GM and player.
In this case, the problem comes in the way we are handling the properties. If you are *both* gm and player, you'll finally, with the current code, get rights to the first related check. I was thinking about this system to include, on my side, players with translation rights, players who could easily help to submit translations.

Idea 2)
The other system i could think about is to keep the 3 current privilege levels, and extend them with a subset of privileges. The 'include' system is kept (Admin includes GM includes Player rights), and the set by more suitable rights.

---

The PrivilegeMgr could be a real important system and replace a lot of DOL areas - login management, ban handling, etc...
- ePrivLevel.None -> no privileges
- ePrivLevel.Login -> allow to log (aka you are not ban)
- ePrivLevel.Watcher -> you can log but only roam into the world, not be attacked/being attacked/talk in send,say, broadcast - perhaps fly too. Noone see you
- ePrivLevel.Player -> player rights
- ePrivLevel.Translator -> you can submit translations
- ePrivLevel.Mapper -> you can create and move mobs
- ePrivLevel.ItemFixer -> you can create and fix items
- ePrivLevel.GameMaster -> actual GM rights
- ePrivLevel.Admin -> actual admin rights

I have actually implemented idea 1 with ePrivLevel.Player, ePrivLevel.GM, ePrivLevel.Admin and ePrivLevel.Translator. Who'll have wide use of this system, and so contribute to Dawn of Light to support various others privilege levels ?
Would you prefer using the idea 1) or idea 2) ?

[Graveen]

On another side, if it benefits noone, i think i could avoid such a big change !

[Tolakram]

I kind of like the command privileges rather than privlevel. Seems like to big a change to make right now. If someone needs to edit mobs that can be given access to the mob command ... item command, etc. I've been adding missing features to these commands as I find them, so they should be fairly complete.

You know me ... when in doubt, don't do it.

[Graveen]

Actually, this is the point. The system by flags is working fine. Anyway i manually changed hundred of

Code: Select all

if (Client.Account.PrivLevel ==1)


by

Code: Select all

if(PrivelegeMgr.HavePrivilege(Client, ePrivLevel.Player))


or exactly, by *what* the plvl1 check1 means exactly in our context:

Code: Select all

if( !PrivilegeMgr.IsGameMaster(Client))


but, the reality is i find the flag hardly readable, that i'm forced to cheat with commands, and - the most important - that the checks for privlevel are rather stupid. With do 3 checks of plvl for trading where we could use IsAllowedToTrade(), or more generally, the serverrules ? How to handle ePrivLevel.Player commands where a part is GM only - ie /guild ? This would need a rewrite, and i'm not really in the mood to do it for such a benefits.

I'll upload my work as a new branch; perhaps somebody would be interested to find a real use for this. I think if we have the need of translator differents of players (which is also a point... on Storm, the validation process means than everyone 'll be invited to submit translation... GMs 'll validate them or not !).

[Dre]

I have a better idea than my old one

First, for a good right management, we need to have many different (basic) rights such as:

• Create more than one character
• Gain experience
• Gain realm points
• Gain bounty points
• Can trade
• Can loot
• Can PvE
• Can PvP
• Can use XXX command
• Can fly
• Can use player's abilities
• Is invisible
• And many others (every time we have a new system, we have also a new right

There are already a system with many rights with "singlepremission" but we need to extend that to core access (Loot, Trade, ...) and not only commands.

Secondly, we need a group system to create access such as:

• Watcher
  Is invisible
  Can fly
• Player
  Create more than one character
  Gain experience
  Gain realm points
  Gain bounty points
  Can trade
  Can loot
  Can PvE
  Can PvP
• GM
  Watcher (a group can belong another group =))
  Can trade
• Admin
  GM
  AllCommands

And finally, a player can belong to one or more group.

It's not a big work, we can create some temporary groups "OldPlayer", "OldGM", "OldAdmin" which have theirs access and create some new access when a developer implements "Can trade", he add it to "OldPlayer" and so on.

[Apo]

Other emus (like WoW) are using bit flags - this flags can be set into the account table or server table - account table = same rights on each server | server table = only on this server. With this you can give an gm the exact command rights you want for him. Or use an database table for "access templates":

Access Name, ValidCommands

AccessName: GM, ValidCommands: Mob; Zone; Keep etc. etc.
AccessName: GMLight, ValidCommands: Kick; Ban

And then check if the users access template includes the access to the e.g. /mob command.

[Graveen]

well, i exactly think this is a lot of work and/or will never be implemented

[tobz]

well, i exactly think this is a lot of work and/or will never be implemented

I wrote a role-based system a while ago. The problem is that DOL has the idea of tiered access baked in heavily. You'd have to categorize a lot of the usage to make it viable to switch to a more expressive permission system. For instance, GMs and Admins can see stealther players regardless... how do you deal with that if you have a role-based system? (obviously, this is a simple example, as you could make it a bit flag or something, and let roles have flags and usable commands, etc)

[Apo]

Theory: remove privLevel from CmdAttribute and check in the OnCommand method if the player is allowed to use this command:

if(!IsAllowedToUse(client, "mob"))
return;

AbstractCommandHandler
public bool IsAllowedToUse(GameClient client, string cmdName)
{
if(client.account.access.contains(cmdName))
return true;

return false;
}

But thats theory.

[Apo]

*bump*

While I was thinking about some things for the language system (don't ask me how I came from the language system to this, it was just there), I - maybe - found an other way for you:

Code: Select all

using DOL.Database.Attributes;

namespace DOL.Database
{
    [DataTable(TableName = "access_level_template")]
    public class AccessLevelTemplate : DataObject
    {
        private string m_id;
        private bool m_allowStaffLogin;
        private bool m_isAllowedToBeVisible;
        private bool m_canAttackPlayers;
        private bool m_canBeAttackedByPlayers;
        private bool m_canAttackCreatures;
        private bool m_canBeAttackedByCreatures;
        private string m_allowedCommands;

        public AccessLevelTemplate()
        {
            m_id = string.Empty;
            m_allowStaffLogin = false;
            m_isAllowedToBeVisible = true;
            m_canAttackPlayers = true;
            m_canBeAttackedByPlayers = true;
            m_canAttackCreatures = true;
            m_canBeAttackedByCreatures = true;
            m_allowedCommands = string.Empty;
        }

        /// <summary>
        /// Gets or sets the template id of the access level template
        /// </summary>
        [PrimaryKey]
        public string AccessLevelTemplateID
        {
            get { return m_id; }
            set { m_id = value; }
        }

        /// <summary>
        /// Gets or sets if the assigned account is allowed to use the staff login (log in while the server is closed).
        /// </summary>
        [DataElement(AllowDbNull = false)]
        public bool AllowStaffLogin
        {
            get { return m_allowStaffLogin; }
            set { m_allowStaffLogin = value; }
        }

        /// <summary>
        /// Gets or sets if the assigned account is allowed to be visible for other accounts (no = false, yes = true).
        /// </summary>
        [DataElement(AllowDbNull = false)]
        public bool IsAllowedToBeVisible
        {
            get { return m_isAllowedToBeVisible; }
            set { m_isAllowedToBeVisible = value; }
        }

        /// <summary>
        /// Gets or sets if the assigned account is allowed to attack players (no = false, yes = true).
        /// </summary>
        [DataElement(AllowDbNull = false)]
        public bool CanAttackPlayers
        {
            get { return m_canAttackPlayers; }
            set { m_canAttackPlayers = value; }
        }

        /// <summary>
        /// Gets or sets if the assigned account can be attacked by players (no = false, yes = true).
        /// </summary>
        [DataElement(AllowDbNull = false)]
        public bool CanBeAttackedByPlayers
        {
            get { return m_canBeAttackedByPlayers; }
            set { m_canBeAttackedByPlayers = value; }
        }

        /// <summary>
        /// Gets or sets if the assigned account is allowed to attack creatures (no = false, yes = true).
        /// </summary>
        [DataElement(AllowDbNull = false)]
        public bool CanAttackCreatures
        {
            get { return m_canAttackCreatures; }
            set { m_canAttackCreatures = value; }
        }

        /// <summary>
        /// Gets or sets if the assigned account can be attacked by creatures (no = false, yes = true).
        /// </summary>
        [DataElement(AllowDbNull = false)]
        public bool CanBeAttackedByCreatures
        {
            get { return m_canBeAttackedByCreatures; }
            set { m_canBeAttackedByCreatures = value; }
        }

        /// <summary>
        /// Gets or sets the commands the assigned account is allowed to use (seperated by semikolon: ';')
        /// </summary>
        [DataElement(AllowDbNull = true)]
        public string AllowedCommands
        {
            get { return m_allowedCommands; }
            set { m_allowedCommands = value; }
        }
    }
}

For commands, check if the AllowedCommands column contains the command name. It's just a few properties, but I think you know what I want to say. In that way you can create _hundreds_ of priv levels - each template has other settings.

Maybe add it as an property to the client.