Users, Roles, and Trust Levels
The single most common question from new site owners: "How does someone become a Jetonomy user?" The answer is that they already are one. This page explains the three layers that decide what a person can do in your community, and which one to reach for.
The one-sentence model
Jetonomy members ARE your WordPress users. There is no separate registration, no separate account table, no import step. Anyone with a WordPress account on your site is a community member the moment they visit; a community profile row is created for them automatically the first time they visit a community page while logged in.
Registration flow (public communities)
Registration is WordPress's own:
- Enable Settings → General → "Anyone can register" in WordPress (not a Jetonomy setting).
- A visitor registers through your normal WordPress signup (or any membership/social-login plugin you use - Jetonomy inherits whatever handles
wp_users). - On their first visit to the community they get a Jetonomy profile automatically - starting at Trust Level 0 with the WordPress role your site assigns new users (usually Subscriber).
Nothing else to configure. If your membership plugin gates registration, that gate IS the community's gate.
The three layers
| Layer | Set by | Controls | Where to manage |
|---|---|---|---|
| WordPress role (Subscriber, Editor, Administrator…) | You / WordPress | wp-admin access and Jetonomy capabilities (jetonomy_moderate, jetonomy_manage_settings…) per the editable role mapping |
Assign roles on the WordPress Users screen; edit the role → capability mapping under Jetonomy → Settings → Permissions |
| Trust level (0-5: Newcomer → Moderator) | Earned automatically by participation (posts, replies, likes received, days visited) - or pinned manually | Community privileges that should be earned, not assigned: posting links/images, editing wikis, flag weight, rate limits | Jetonomy → Users (filter by level, override per user) |
| Space role (member, moderator, admin) | Space owners/admins | Powers inside one space only: moderating its topics, managing its members | Each space's Members screen |
The three are deliberately independent:
- A Subscriber (WP role) can be a Trust Level 5 Moderator and a space admin - a star community member with zero wp-admin access.
- An Administrator always bypasses trust gates and holds every capability.
- Making someone a space moderator gives them power in that space only - it never grants wp-admin or site-wide moderation.
Which layer do I use when?
| I want to… | Use |
|---|---|
| Let someone moderate the whole community from the frontend | Tick jetonomy_moderate for their role in the Settings → Permissions capability matrix |
| Let someone run one space | Make them that space's admin/moderator on its Members screen |
| Let regulars post links/images sooner (or later) | Adjust the Trust Level Thresholds table in Jetonomy → Settings → Permissions |
| Promote one specific person past the gates | Pin their trust level on Jetonomy → Users |
| Give a client access to Jetonomy settings without full admin | Tick jetonomy_manage_settings for their role in Settings → Permissions (the role → capability mapping itself stays admin-only) |
Capabilities reference
Defaults are seeded per role and fully editable in the Jetonomy → Settings → Permissions capability matrix - unticking a box revokes on save. Administrators always hold every capability and cannot be edited (so an owner can never lock themselves out):
| Capability | What it unlocks |
|---|---|
jetonomy_moderate |
Site-wide moderation: flag queue, member restrictions, content actions |
jetonomy_manage_settings |
Jetonomy settings + the Spaces admin screen |
jetonomy_manage_spaces |
Space administration in wp-admin |
jetonomy_create_spaces |
Creating spaces from the frontend |
Tick the capabilities for any role - custom roles included - in the Jetonomy → Settings → Permissions matrix; every check falls back safely to manage_options, so Administrators are never locked out.
Custom roles do not need this just to take part. The capabilities above are for the site-wide powers they describe - moderating, managing settings and spaces. Reading, posting, replying and voting inside a space a member belongs to are decided by their membership of that space, so a member whose WordPress role comes from another plugin - an LMS student role, a membership tier - can take part without appearing in this matrix at all.
Changed in 1.9.1. Before this, only the five roles that ship with WordPress carried Jetonomy capabilities, and every other plugin's role was turned away at the capability check before their space membership was ever read. Such a member could open a space and do nothing in it - worse off than a logged-out visitor, who is judged on the space's visibility instead. Membership is now consulted for those actions. This grants nothing on its own: the space's visibility, its who-can-post and who-can-reply settings, bans and trust-level gates all still apply exactly as before.