NewPerms/SourcePerms questions

[iPlayer]

Hey guys. I've got two simple questions.

1. How do I define priority? Say, admin with higher priority shouldn't be ignited by a regular admin etc.
2. Is it a good idea to put non-admins in permissions? For example, premium players would have 'premium.*' permission.

[necavi]

1. Nothing is setup for that yet, I'll have to think about how best to handle that, if you have any ideas I would love to hear them.
2. Yes! That was certainly a very large part of the idea behind this system! Normal users, donors, etc

[iPlayer]

1. Priority is basically a number. Well, it can be group-wide, player-wide or permission-wide. Say, player's priority overrides group's one and permission priority overrides them both.

Syntax: Select all

{
    "[U:1:66103826]": 
    {
        "priority": 5,
        "parents" :
        [],
        "permissions" :
        [
            "sp.fun.*@10"
        ]
    }
}

2. I was just a little bit confused because of admins.json name for your flatfile backend.

[necavi]

1. We'll likely go for something like that, definitely have to consider it a bit more, however.

2. True, most places follow the convention of it being an "admin" system, even when its used by everyone. Being in the admins file gives you absolutely no permissions except those that you define.

[iPlayer]

1. Thanks. Will be looking forward to seeing that implemented.
2. Great, I get the idea

[iPlayer]

For now, I see that a permission is represented by two entitites - permission string and compiled regex. They're stored in a dict where the string is a key, regex is a value. If you implement per-permission priority, it's getting too nested. I guess then you're coming closer to doing a Permission class which would store the string, the regex and the priority.

[Ayuto]

Maybe we should rename the admins.json to permissions.json. Especially, since the SQL database is called permissions.db.

[necavi]

I think that that would be a good idea. And as for the priority, if we end up having a static int value for it I would have it be a part of the command decorator, separate from the permission string. Something like respect_immunity=True, only allowing you to target people lower than yourself. Quite frankly I'm a bit meh about adding priority at all, however. I've always strongly felt that if you're going to have people with commands you should trust them entirely (And audit often). If they're trying to use commands out of order then remove their power.

[iPlayer]

I guess you just don't realize how pragmatic some server owners are in terms of giving people powers. No, I'm serious. For 200 rubles you get A3 powers (admin powers that can operate with regular players) and for 200 more rubles you get I3 (immunity that protects you from A3 admins). Then there're A2 & I2 for 300RUB, A1 and I1 for 500RUB each. Finally there's a server owner who's basically invulnerable and who gives these powers to 13yo's as long as they pay enough. Do anything wrong and your admin rights will be suspended. Get banned permanently and you can get unbanned for X rubles.

I won't recommend such servers though.

Now, even if we're talking about sane servers, you can think of admin probation. Somebody evil can pretend to be an awesome candidate for admin, but as soon as you give them rights, they ban everybody including you. With admin priorities you can avoid that. Players will still get banned but other admins won't, and these admins can unban banned players and ban the enemy - with equal priorities the enemy would be invulnerable until server owner gets to server configs.

[necavi]

I'll figure out a system for it. Likely the way I said before.