moon
/
enigma-bbs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

ACS doc improvements

This commit is contained in:
Bryan Ashby 2018-12-09 01:22:33 -07:00
parent 8652b35b46
commit 4bceb74cc4
2 changed files with 40 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/configuration/acs.md
View File

@ -4,7 +4,7 @@ title: Access Condition System (ACS)
---
## Access Condition System (ACS)
ENiGMA½ uses an Access Condition System (ACS) that is both familure to oldschool BBS operators and has it's own style. With ACS, SysOp's are able to control access to various areas of the system based on various conditions such as group membership, connection type, etc. Various touch points in the system are configured to allow for `acs` checks. In some cases ACS is a simple boolean check while others (via ACS blocks) allow to define what conditions must be true for certain _rights_ such as `read` and `write` (though others exist as well).
ENiGMA½ uses an Access Condition System (ACS) that is both familiar to oldschool BBS operators and has it's own style. With ACS, SysOp's are able to control access to various areas of the system based on various conditions such as group membership, connection type, etc. Various touch points in the system are configured to allow for `acs` checks. In some cases ACS is a simple boolean check while others (via ACS blocks) allow to define what conditions must be true for certain _rights_ such as `read` and `write` (though others exist as well).
## ACS Codes
The following are ACS codes available as of this writing:
@ -48,20 +48,30 @@ The following logical operators are supported:
ENiGMA½ also supports groupings using `(` and `)`. Lastly, some ACS codes allow for lists of acceptable values using `[` and `]` — for example, `GM[users,sysops]`.
### Examples
### Example ACS Strings
* `NC2`: User must have called two more more times for the check to return true (to pass)
* `ID1`: User must be ID 1 (the +op)
* `GM[elite,power]`: User must be a member of the `elite` or `power` user group (they could be both)
* `ID1|GM[co-op]`: User must be ID 1 (SysOp!) or belong to the `co-op` group
* `!TH24`: Terminal height must NOT be 24
## ACS Blocks
Some areas of the system require more than a single ACS string. In these situations an *ACS block* is used to allow for finer grain control. As an example, consider the following file area `acs` block:
```hjson
acs: {
read: GM[users]
write: GM[sysops,co-ops]
download: GM[elite-users]
}
```
All `users` can read (see) the area, `sysops` and `co-ops` can write (upload), and only members of the `elite-users` group can download.
## ACS Touch Points
The following touch points exist in the system. Many more are planned:
* Message conferences and areas
* File base areas
* Menus within `menu.hjson`. See [Menu HJSON](menu-hjson.md).
* [Message conferences and areas](/docs/messageareas/configuring-a-message-area.md)
* [File base areas](/docs/filebase/first-file-area.md) and [Uploads](/docs/filebase/uploads.md)
* Menus within [Menu HJSON (menu.hjson)](menu-hjson.md)
See the specific areas documentation for information on available ACS checks.

32
docs/messageareas/configuring-a-message-area.md
View File

@ -10,13 +10,18 @@ Message Conferences are the top level container for *1:n* Message *Areas* via th
Each conference is represented by a entry under `messageConferences`. Each entries top level key is it's *conference tag*.
| Config Item | Required | Description |
|-------------|----------|---------------------------------------------------------------------------------|
| `name` | :+1: | Friendly conference name |
| `desc` | :+1: | Friendly conference description. |
| `sort` | :-1: | Set to a number to override the default alpha-numeric sort order based on the `name` field. |
| `default` | :-1: | Specify `true` to make this the default conference (e.g. assigned to new users) |
| `areas` | :+1: | Container of 1:n areas described below |
| Config Item | Required | Description |
|-------------|----------|-------------|
| `name` | :+1: | Friendly conference name |
| `desc` | :+1: | Friendly conference description. |
| `sort` | :-1: | Set to a number to override the default alpha-numeric sort order based on the `name` field. |
| `default` | :-1: | Specify `true` to make this the default conference (e.g. assigned to new users) |
| `areas` | :+1: | Container of 1:n areas described below |
| `acs` | :-1: | A standard [ACS](/docs/configuration/acs.md) block. See **ACS** below. |
### ACS
An optional standard [ACS](/docs/configuration/acs.md) block can be supplied with the following rules:
* `read`: ACS require to read (see) this conference. Defaults to `GM[users]`.
### Example
@ -28,6 +33,9 @@ Each conference is represented by a entry under `messageConferences`. Each entri
desc: Local discussion
sort: 1
default: true
acs: {
read: GM[users] // default
}
}
}
}
@ -42,6 +50,11 @@ Message Areas are topic specific containers for messages that live within a part
| `desc` | :+1: | Friendly area description. |
| `sort` | :-1: | Set to a number to override the default alpha-numeric sort order based on the `name` field. |
| `default` | :-1: | Specify `true` to make this the default area (e.g. assigned to new users) |
| `acs` | :-1: | A standard [ACS](/docs/configuration/acs.md) block. See **ACS** below. |
### ACS
An optional standard [ACS](/docs/configuration/acs.md) block can be supplied with the following rules:
* `read`: ACS require to read (see) this conference. Defaults to `GM[users]`.
### Example
@ -54,7 +67,10 @@ messageConferences: {
name: ENiGMA 1/2 Development
desc: ENiGMA 1/2 discussion!
sort: 1
default: true
default: true
acs: {
read: GM[users] // default
}
}
}
}