Roles and Permissions
Lanview uses role-based access control to decide what each operator can see and do.
A Lanview user receives permissions through assigned roles. Permissions control access to product areas, device actions, settings, security administration, remote support, package deployment, monitoring and other administrative features.
Lanview Studio uses effective permissions to shape the user interface, but Lanview Server checks permissions when actions are requested.
How roles work
A role is a named collection of permissions.
Users can be assigned one or more roles. The permissions from those roles combine to form the user’s effective access.
For example, an organisation may create separate roles for:
- Helpdesk support.
- Desktop support.
- Senior technicians.
- Server administrators.
- Security administrators.
- Read-only auditors.
The exact role model should match the organisation’s own support structure.
Module permissions and action permissions
Lanview permissions usually fall into two broad types.
| Type | Purpose |
|---|---|
| Module permissions | Control whether a major area appears in Lanview Studio. |
| Action permissions | Control whether the user can perform a specific operation. |
A user may be able to see a module without being able to perform every action inside it.
For example, a user may be able to view devices but not reboot them, or view roles but not edit them.
Where to manage roles
Roles are managed from Lanview Studio > Security.
Administrators with the required permissions can create roles, rename roles, update descriptions, copy roles, delete roles and change permission assignments.
Required permissions
| Permission | Allows |
|---|---|
studio.module.security | Shows the Security module in Lanview Studio. |
security.view_roles | View roles and permission assignments. |
security.manage_roles | Create, edit, copy, delete and update role permissions. |
security.view_users | View users and their assigned roles. |
security.manage_users | Assign or remove user roles where supported by user management. |
Permission enforcement
Lanview Studio may hide areas or disable buttons based on the signed-in user’s permissions.
That is for usability, not security. Lanview Server still checks permissions when the action is requested. A user cannot bypass Server-side permissions by finding a hidden command, using the console, or calling an unsupported process.
Permission denied events
When a user attempts an action they are not allowed to perform, Lanview can record a permission-denied audit event.
This helps administrators identify misconfigured roles, attempted overreach, or situations where users need a more suitable permission set.
Designing roles
When designing roles, start from the work the user needs to perform rather than from job titles alone.
Consider separating permissions for:
- Viewing devices.
- Managing devices.
- Remote View.
- Remote Control.
- Remote command execution.
- Package deployment.
- Security administration.
- Settings management.
- Console access.
- Audit viewing and export.
Avoid building one large near-administrator role for convenience. Broad roles are harder to review and easier to overuse.
Audit behaviour
Lanview audits role administration actions on the Server.
Audit records may include:
- Role created.
- Role renamed.
- Role description changed.
- Role copied.
- Role deleted.
- Permission added to a role.
- Permission removed from a role.
- Permission denied during an attempted action.
Role and permission changes can require an audit reason when reason prompts are enabled.
Console commands
The command reference can show permission metadata for console commands. Useful commands include:
command.meta [command]
security.status
Role creation and editing should normally be performed through Lanview Studio unless a supported console process is documented for the specific task.
Good practice
- Use roles to represent real responsibilities.
- Keep high-risk permissions in smaller trusted roles.
- Review roles after product updates or process changes.
- Avoid shared operator accounts.
- Do not treat Studio UI hiding as the only access control.
- Keep console access tightly controlled.