Users & Permissions

Users & Permissions

A publishing team needs room to work, but not everyone needs the keys to the entire system.

VerdinCore separates everyday editorial work from site administration through a focused set of account roles and permissions. Authors can concentrate on writing, administrators can manage the website, and the people responsible for user accounts retain control over who gets access in the first place.

The principle is simple: give each person access to the work they need to do, without turning permissions into another project to manage.

Four roles, four clear responsibilities

VerdinCore defines four account roles. Each has a specific place in the publishing process.

These are built-in roles with defined responsibilities, not a customizable role builder. That distinction keeps both the interface and the permission model understandable.

The most important difference is not between four labels. It is between three kinds of activity: operating the site, creating its content, and reading it.

((Screenshot from VerdinCore Admin > Dashboard > Users: show the users table with four harmless demonstration accounts representing Superadmin, Admin, Editor, and Member, if available. Keep the Groups and Status columns clearly visible; include the Add User button. Use fabricated usernames and non-sensitive example email addresses, not actual account details. Capture approximately 1500 × 900 on desktop. Place immediately after the roles table. Suggested caption: "Each account has a defined role and a clearly visible status."))

Administration and authorship are different jobs

A small publication may be run by one person. As it grows, however, the person writing an article does not necessarily need access to system settings, other authors' work, or account administration.

VerdinCore reflects that distinction in its dashboard:

• Superadmins have access to user management as well as editorial and system functions.

• Admins can handle the website's content and operations but cannot manage user accounts or assign roles.

• Editors receive a narrower workspace focused on Posts they are allowed to manage.

• Members can sign in to read eligible restricted content, without entering the administration area.

This separation helps preserve a straightforward authoring experience. An Editor does not need to navigate through analytics, system information, user administration, and Page settings simply to publish a Post.

It also makes responsibilities explicit. Someone who needs to maintain a site's Page hierarchy has a different job from someone who only writes articles. Those jobs need not share the same access level.

An Editor works on their own Posts

The Editor role is deliberately limited. Editors can create Posts, edit their own Posts, and upload images needed for authorized editorial work. They do not receive permission to create or manage Pages, edit another author's Posts, administer the media library, manage Topics or Content Blocks, or change system settings.

The ownership restriction is more than a filtered list. The application also checks ownership when a Post is opened or modified through its editing operations. An Editor cannot gain access to another author's Post simply by changing an ID in the address bar or submitting a different Post ID.

For a publication with multiple contributors, this gives each author a clearly defined working area without introducing a complicated per-Post sharing configuration.

((Screenshot from VerdinCore Admin using a dedicated test account with the Editor role: capture the Posts dashboard with two or three Posts authored by that account and the reduced editor navigation visible. Avoid superadmin or admin controls in this screenshot. At approximately 1440 × 900, include the page heading, Add Post action if visible, and the content list. Place after "An Editor works on their own Posts". Suggested caption: "The Editor workspace keeps the focus on the author's own publishing work."))

Managing accounts from one place

Account administration belongs to the Superadmin role. The Users area brings together account identity, assigned group, account status, and basic activity information in a single list.

A Superadmin can:

1. Create an account with a username, email address, password, and assigned role.

2. Update an account, including its basic details, role, or password when required.

3. Block or reactivate an account using its active status.

4. Delete an account through the user management interface.

The account editor uses a focused layout: account information on one side and access settings on the other. This makes it immediately clear that changing a user's email address is a different decision from granting administrative authority.

((Screenshot from VerdinCore Admin > Dashboard > Users > Add User: open the account modal and show both Account and Access sections, including Username, Email address, Password, Group, and Active account. Select "Editor" in the Group dropdown without saving a real account. Use fabricated sample values only and leave the password empty or masked. Capture the entire modal at approximately 1500 × 950. Place after the account-management steps. Suggested caption: "Account details and access settings are managed together without mixing their responsibilities."))

Safeguards for privileged accounts

Several operations receive additional checks rather than relying only on a visible confirmation button.

For example, the account management service prevents the current Superadmin from blocking their own account, deleting their own account, or changing their own assigned group through the user editor. Passwords are checked against the configured authentication validation rules, and duplicate usernames and email addresses are rejected.

Blocking an account marks it inactive and removes its persistent remember-me tokens. It is an account access control, not a promise that every already-open browser session is immediately terminated.

These are modest but useful protections. A permissions interface should help an administrator avoid obvious mistakes, not merely expose every possible switch.

Permissions are enforced beyond the interface

VerdinCore uses CodeIgniter Shield for account authentication and permission handling. Administrative routes require a signed-in session and the relevant permissions. The application then applies additional checks where the operation calls for them, such as confirming Post ownership for Editors.

That creates two complementary layers:

The distinction matters. Hiding the Users menu from an Editor is useful for clarity, but it would not by itself protect user administration. The corresponding requests must also be restricted, and in the reviewed implementation they are.

This is a deliberately defined permission model, not a claim of unlimited custom roles, enterprise single sign-on, or independently configurable access rights for every database record.

Signing in is not the same as administering the website

Not every account is intended to contribute content. VerdinCore can also use authentication to make selected published Posts and Pages available to signed-in readers.

A Member account has no administrative dashboard permissions. It is a reader account. The Members Only content access setting, however, checks whether a visitor is authenticated: it is not a paid-membership tier and does not require the reader to have the specific Member role. A signed-in Editor or Admin may also read content intended for authenticated visitors.

This creates a useful separation between two questions:

• What can this account do inside VerdinCore? Its role and permissions answer that.

• Can this visitor read a restricted published item? The content access setting and signed-in state answer that.

For example, a site might publish product news for everyone, maintain an additional set of resources for signed-in readers, and let a small team of Editors write the public updates. Those functions can coexist without making reader accounts into editorial accounts.

See Visibility & Access for the content-level rules, including access restrictions in Page hierarchies, and Publishing Workflows for publication status and scheduling.

Public registration is optional

A site does not necessarily need to let every visitor create an account. In VerdinCore, public registration is configurable and disabled by default in the reviewed source configuration.

When enabled, the application provides a registration flow and an email activation process. Newly registered accounts are assigned the Member role by default. This supports sites that want reader accounts while allowing other deployments to keep account creation under administrative control.

The availability of registration does not imply a subscription checkout, paid access plan, or a guarantee about email deliverability in every deployment. Those are separate concerns.

Clear boundaries make teams more effective

A good permissions system is not measured by the number of switches it exposes. It is measured by whether people can work confidently within responsibilities they understand.

For VerdinCore, that means a small number of purposeful roles, ownership-aware editing, centralized account administration, and a clean division between publishing rights and reading access.

The result is a system where the people creating content can focus on publishing, while the people responsible for the website retain control over how it is operated.