permissions
Wagn's powerful permissions system lets you set CRUD (create, read, update, and delete) permissions on any set of cards.
These permissions are checked when a card is included. That means, for example, that if a public page includes a private card, that private card won't be shown to folks without permission. Permissions are also checked wherever cards are queried, so that search results will never turn up a card that a user doesn't not have permission to see.
Wagn also supports true file permissions, meaning that permissions are checked whenever a file is requested.
Example
Permission to update a given card is based on its *update rule. A new Wagn comes with several update rules, including these two:
- All cards can be updated by Anyone Signed In.
- Layout cards can be updated only by Administrators.
By "Layout cards", we mean cards that have the type "Layout". Since the set of "Layout cards" is narrower than the set of "all cards", the second rule overrides the first, and only Administrators are permitted to edit Layout cards.
How To
Basics
Wagn's permissions system is both powerful and simple. It uses just 4 main kinds of rules: *create, *read, *update, and *delete. (It currently also supports *comment rules, but that will soon be handled differently.)
All Wagn permissions can be assigned to any combination of Users and Roles (user group). For example, a "Conference Call" card could be restricted so that it could be updated only by persons with the Staff role or the Board role or by Justin Blauchen (the CEO's husband).
Editing card permissions is just like editing any other rule; just go to "advanced" or "advanced > rules" on the card menu.
Inheritance
A card with the compound name A+B can inherit its permissions from A.
Suppose we have a card named "Jin's Dossier" and another named "Jin's Dossier+overview". The common use for such compound names is as fields. Which is to say that the +overview card is used as a field of Jin's Dossier. Often we want our field cards (+overview) to have the same permission as their subject (Jin's Dossier).
We call this pattern "inheriting" permissions, and every Wagn comes with default create, read, update, and delete rules that make all plus cards (all cards withcompound names) inherit from their parents. These rule can, of course be changed or overridden like any other rule.
File permissions
When serving files and images, many systems rely on "security through obscurity": the hope that hard-to-guess urls will prevent users from stumbling upon their files. But as soon as the url becomes known to search engines, that approach flops. Wagn checks for file permissions (which are no different from any other card permission) on every request, so clicking a link to a restricted file will only work for permitted users.
Tips
- in general, an attempt to update a card that doesn't exist will fall back to the create action and use the create permission.
- changing a card type requires permission to delete the old card and create the new
- one special case in inheritance is adding new children to an existing parent. In the example above, this would be like editing an Audition later to add some missing information, like, say, the timeslot. Since, in this case, creating the child is akin to updating the parent, then whenever the child is set to inherit update permissions, it inherits them from the parent's create permissions.
- the commenting overhaul blueprint proposes to get rid of the *comment setting, so that this will no longer be considered a separate permission. (instead comments will have full CRUD permissions based on a +*comment card).