Flexible

Introduction

!flexible security groups allow the definition of group memberships by conditions instead of fixed member lists. So instead of keeping track per hand who all meets some condition you can just tell the bot all who meet condition A are members of group B. An example would be a raidbot shared among several orgs. Just add a group checking if anyone is a member of one of the orgs to grant access, instead of keeping memberlists update every day via rosters. Or you can grant guest status to everyone of one faction above a selected level. The conditions are compared to the entry in the whois cache for the checked character.

How does a !flexible group work?

Each existing security group can be extended with one !flexible security group. The classical security group defines the name and the access level for both the normal and the !flexible group. The normal security group can still have fixed members.

A !flexible security group consists of a set of conditions that either have all to be met (AND-combined !flexible groups) or at least one has to be met (OR-combined !flexible groups). If you have conditions that only can be written in a combination of AND and OR you'll have to use several AND-combined security groups to split the conditions up.

Fields allowed in conditions

There are six fields allowed in conditions, each with a limited set of compare-operators supported.

   level for the level of a character. All numeric compare operators are allowed for this field (<, <=, =, >=, !=, >).
   profession for the profession of the character. = and != are supported operators.
   faction for the faction of the character. = and != are supported operators. In addition to the three factions ingame the pseudo-faction all is supported too, it meets all three factions at once.
   rank_id for the organizational rank of the character. All numeric compare operators are allowed (<, <=, =, >=, !=, >).
   org_id for the ID of the organization the character may be in. IDs don't change, org names may change, that's why this is supported instead of the org name. = and != are the supported operators.
   at_id for the AO alien level of the character. All numeric compare operators are allowed (<, <=, =, >=, !=, >).

The shape of classical use is therefore :

!flexible condition add <groupname> <level|rank_id|at_id> <<|<=|>|>=|=|!=> <number>

Internal workings

On a check for the highest access level of a character the security framework queries the !flexible extension if installed. First it checks the current cache if the character already got an entry, and returns that if existing. If no cached entry is found it checks all security groups with higher access level then the currently found one for !flexible extensions. Those groups are sorted in descending order of access levels, with the highest first. The conditions of the !flexible extensions existing are formed into a SQL query in the whois cache. If the query returns a result the player is a member of the currently checked group, and the access level of that group is returned. If not any further existing groups are checked afterwards.

Examples

Grant admin rights to members in the second highest rank in example org (org_id: 12345):

   Create a security group granting ADMIN rights (or just use the default ADMIN group)
    !addgroup admined group to give admin level
    !security levels => click on ADMIN link in the "admined" group entry below
    !security groups => verify "admined" group is now marked at ADMIN access level
   Create an AND-combined !flexible extension for this group
    !flexible => click on AND-combined link in the "admined" group creation line
   Add a rule checking for org membership org_id = 12345. All org checks are done with org ids, as those are fixed over the existance of the org. Org names can be changed.
    !flexible condition add admined org_id = 12345
   Add a second rule checking for rank_id equal to 1
    !flexible condition add admined rank_id = 1

If oppositely you'd want to open your bot at GUEST level to anyone:

   First check the rank of a player that doesn't have access yet (should yet be ANONYMOUS)
    !security whois playername
   Create a security group granting GUEST level
    !addgroup guested group to give guest level
    !security levels => click on GUEST link in the "guested" group entry below
    !security groups => verify "guested" group is now marked at GUEST access level
   Create an AND-combined !flexible extension for this group
    !flexible => click on AND-combined link in the "guested" group creation line
   Add a rule checking for player level to be at least 1
    !flexible condition add guested level >= 1
   Verify that the condition was created correctly
    !flexible => the condition "level >= 1" should now be added in our "guested" group
   Finish by checking the new rank of our player (should now be GUEST as expected)
    !security whois playername

Important note :

For the !minlevel and !faction commands to work you have to config a flexible group for guest access and enter the name into the  setting Guest_Group of the Flexible_Security module