Download this file
| 1 | //go:build !idear_peers |
| 2 | |
| 3 | package idear |
| 4 | |
| 5 | // PeerGrants reports how far an actor's authority reaches, and it is |
| 6 | // fixed at COMPILE TIME by the idear_peers build tag rather than read |
| 7 | // from Config. |
| 8 | // |
| 9 | // Without the tag (this file) it is false: an actor grants and manages |
| 10 | // only ranks STRICTLY BELOW their own. An Admin invites, promotes, |
| 11 | // demotes and removes Members, and never another Admin. |
| 12 | // |
| 13 | // Built with -tags idear_peers (peers_on.go) it is true: the reach |
| 14 | // extends to the actor's OWN rank. An Admin may then invite or promote |
| 15 | // someone to Admin, and may demote, remove and restore other Admins. |
| 16 | // |
| 17 | // The Owner is the same in both modes, because ownership is not a rank |
| 18 | // that has peers — there is exactly one. Nobody is ever granted |
| 19 | // RoleOwner (Transfer is the only route), and nobody at any rank acts |
| 20 | // on the Owner. See reaches. |
| 21 | // |
| 22 | // It is a build tag and not a Config field because MayActOn and |
| 23 | // Grantable are pure package functions an app calls with no Roster in |
| 24 | // hand — to render a members page, say — and they must answer exactly |
| 25 | // as the store will. A per-Roster setting would give them a second |
| 26 | // source of truth to disagree with. It is exported so an app can |
| 27 | // assert the mode it was built in, or word its own copy to match. |
| 28 | const PeerGrants = false |
| 29 | |
amadan