Editing Flexible
From Bebot Wiki 2
Jump to navigationJump to searchWarning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
''Introduction'' | ''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 | |
| − | A | ||
| − | |||
| − | |||
There are six fields allowed in conditions, each with a limited set of compare-operators supported. | 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 (<, | + | '''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. | '''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 | + | '''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 (<, | + | '''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. | '''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 (<, | + | '''at_id''' for the AO alien level of the character. All numeric compare operators are allowed (<, ⇐, =, >=, !=, >). |
| − | |||
| − | |||
| − | |||
''Internal workings'' | ''Internal workings'' | ||
| − | On a check for the highest access level of a character the security framework queries the | + | 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'' | ''Examples'' | ||
| Line 31: | Line 26: | ||
Grant admin rights to members in the second highest rank in example org (org_id: 12345): | Grant admin rights to members in the second highest rank in example org (org_id: 12345): | ||
| − | Create a security group granting | + | Create a security group granting admin rights (or just use the default ADMIN group) |
| − | + | Create an AND-combined flexible security group extending this group | |
| − | |||
| − | |||
| − | Create an AND-combined | ||
| − | |||
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. | 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. | ||
| − | + | Add a second rule checking for rank_id equal to 1 rank_id = 1 | |
| − | Add a second rule checking for rank_id equal to 1 | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
