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.

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.

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 alien level of the character. All numeric compare operators are allowed (<, ⇐, =, >=, !=, >).

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.

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

1. Create a security group granting admin rights (or just use the default ADMIN group)
2. Create an AND-combined flexible security group extending this group
3. 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.
4. Add a second rule checking for rank_id equal to 1 rank_id = 1