Identity Module — User Guide

Identity Module — User Guide

Users, roles, permissions, audit, and administration.

ProductVertex ERP
ModuleIdentity (ABP Identity + custom administration screens)
AudienceSystem administrators, host operators, and security officers
FormatHTML + Mermaid diagrams

1. Overview

The Identity area manages login accounts, roles, permissions, and related administration. Vertex ERP builds on open-source ABP Identity and presents custom Arabic screens for Users, Roles, and Audit Logs.

Area Capabilities
Accounts Create, edit, deactivate, lockout flag, role assignment
Authorization Roles and permission tree grants
HR link Employee hire auto-creates a user with PersonId
Self-service Account manage + employee portal account tab
Host ops Audit logs, tenants, host hub, white label
flowchart LR Admin[Admin] --> Users[Users] Admin --> Roles[Roles] Roles --> Perms[Permissions] Perms --> Users HR[HR employee create] --> Users Users --> Login[Login] Login --> Modules[Business modules]

Business modules (HR, Evaluation, Workflow, Payroll, and others) often resolve the current person through ExtraProperties.PersonId on the identity user. Creating a user only in Identity does not attach a Person unless that link is set via HR.


2. Getting started

2.1 Recommended setup order

flowchart TD A[Host admin login] --> B[Define roles and permissions] B --> C[Ensure Employee role exists] C --> D[Create users or hire employees] D --> E[Verify Person link for portal staff] E --> F[Configure email and account settings] F --> G[Optional tenants branding audit]
  1. Sign in as host admin.
  2. Open Roles and grant module permissions for each business role.
  3. Confirm the Employee role exists (created by seed or first employee hire).
  4. Create staff users manually or create HR employees (preferred for portal users).
  5. For portal staff, verify login and Person-linked own-data screens.
  6. Configure Setting Management (email / account) if resets and mail are needed.
  7. Optionally configure tenants, white label, and audit review (host).

2.2 Main navigation

Menu Path Purpose
Users /identity/users Account list and CRUD
Roles /identity/roles Role list and permission matrix
Audit logs /identity/audit-logs HTTP/API activity (Host)
Settings /setting-management Email and account settings
Tenants /tenant-management/tenants Tenant administration when multi-tenancy is used
Host tenant hub /admin/host-tenant-hub Aggregated host overview
White label /admin/white-label Branding
Login /account/login Sign-in
My account /account/manage Self profile/account

Parent menu: Administration → Identity Management.

2.3 Multi-tenancy note

MultiTenancy:IsEnabled is typically false in default appsettings. With multi-tenancy off, you operate in a single host context. Tenant menus remain useful mainly when multi-tenancy is turned on.


3. Users

Path: /identity/users
Permission: AbpIdentity.Users (+ Create / Update / Delete)

Key fields

Field Guidance
Username Required unique login name
Password Required on create; optional on edit to keep current
Name / surname Display identity
Email / phone Contact fields
Active inactive users cannot use the system effectively
Lockout enabled allows lock after failed logins
Two-factor flag on the user form
Roles Assign one or more roles

Admin create / edit flow

flowchart TD A[Open Users] --> B[Add or Edit] B --> C[Enter account fields] C --> D[Set flags] D --> E[Assign roles] E --> F[Save] F --> G[User can sign in if active]
  1. Add user with username and password.
  2. Set active, lockout, and two-factor flags as required.
  3. Assign roles.
  4. Save.
  5. Use Permissions on a user to view rights inherited from roles (read-only in the custom UI).

Filters

Search by text and filter by role. The grid shows locked status when lockout is in effect.

Operating notes

  • Prefer granting rights through roles, not direct user permissions (the custom Users screen does not save direct user permission edits).
  • There is no email-invite button and no explicit Unlock action on this screen.
  • PersonId is not shown or edited here — use HR employee create/update for that link.

4. Roles and permissions

Path: /identity/roles
Permission: AbpIdentity.Roles (+ ManagePermissions)

Role attributes

Attribute Meaning
Name Technical / display role name
Default New users may receive it automatically when configured as default
Public Visible as a public role where ABP applies that flag

Known friendly labels in the product include Admin and Employee.

Permission assignment flow

flowchart LR Admin[Admin] --> RolesUI[Roles screen] RolesUI --> Tree[Permission tree] Tree --> Role[Role] Admin --> UsersUI[Users screen] UsersUI --> Assign[Assign roles] Assign --> User[User] Role --> User
  1. Create or edit a role.
  2. Open permission management for the role.
  3. Grant or revoke permissions across Identity, HR, Evaluation, Communication, and other modules.
  4. Assign the role to users on the Users screen.

Module feature access across Vertex ERP is primarily controlled here.


5. Employee accounts and Person link

Preferred business path

When HR creates an employee, the system can auto-create an Identity user:

Field Typical rule
Username Derived from employee identifiers (for example Emp_{digits})
Password Generated initial password pattern
Email Local placeholder style address when no business email is set
ExtraProperties PersonId = HR person id
Role Employee with portal permission set

If an employee is updated and still has no linked user, the system can ensure an account is created.

sequenceDiagram participant HR as HR Admin participant Emp as Employee service participant Id as Identity participant Portal as Employee portal

HR->>Emp: Create employee Emp->>Id: Create user Emp->>Id: Set PersonId Emp->>Id: Add Employee role Portal->>Id: Login Portal->>Emp: Resolve current employee via PersonId

Guide rules

  1. Hire in HR when the person needs portal own-data features.
  2. Create Identity-only users for pure system operators who do not need a Person.
  3. Evaluation, Workflow, and similar modules expect a PersonId for many actor actions.

6. Self-service account

Channel Path / place Who
ABP Account /account/manage Any authenticated user
Employee portal HR employee area Employees with own-view rights

Employees can typically change username, email, and password through the portal account tab when permitted. Admins still manage roles and activation from Identity Users.


7. Audit logs

Path: /identity/audit-logs
Permission: AuditLogs (Host)

Purpose

Review HTTP/API audit entries: who called what, when, with which status. Filters typically include user, URL, date range, and status. Entity-change summaries may appear on detail views.

Notes

  • This is application audit logging, not the ABP Security Logs browser (security logs have no dedicated live screen here).
  • Host-scoped: intended for system-wide review.
  • Communication and other modules may keep their own audit lists under those modules.

8. Settings

Path: /setting-management

Use Setting Management for:

  • Emailing configuration (needed for mail-based flows)
  • Account-related settings exposed by ABP Account

Exact tabs depend on installed ABP setting contributors and permissions such as SettingManagement.Emailing and AbpAccount.SettingManagement.


9. Tenants, host hub, and branding

These screens sit in the same administration / identity system filter in the UI.

Screen Path Permission Purpose
Tenants /tenant-management/tenants AbpTenantManagement.Tenants Create and manage tenants / features
Host tenant hub /admin/host-tenant-hub HostTenantOverview Aggregated host overview
White label /admin/white-label Branding.Manage Visual branding

When multi-tenancy is disabled, focus on Users, Roles, Settings, and Audit. Enable multi-tenancy only when you intend to isolate organizations as tenants.

Host tooling may also support impersonation where configured; it is not a primary Identity submenu item.


10. Password policy, lockout, and two-factor

Topic Behavior
Password complexity Project defaults soften ABP complexity flags; settings can still override where exposed
Lockout Enabled per user; grid shows locked state; wait for lockout window to end — no Unlock button in the custom UI
Two-factor Flag on the user form; no authenticator enrollment wizard in the Identity admin UI
Initial employee passwords Set by HR auto-create rules — change promptly after first login

Advise users to change initial passwords and keep Active accurate for leavers.


11. What is not in the live UI

Document these as not available in the current open-source Identity UI so operators do not expect them:

Feature Status
Organization units tree DB exists; no admin menu — HR uses Departments
Claim types editor Not exposed
Security logs browser Not exposed
Sessions revoke UI Not exposed
Email invite from Users Not exposed
PersonId editor on Users form Not exposed — use HR
Direct user permission edit UI View inherited only
Calibration / module-specific auth Handled inside each module’s permissions

12. Permissions summary

Identity (ABP)

Permission Ability
AbpIdentity.Users Open users list
AbpIdentity.Users.Create / Update / Delete Account CRUD
AbpIdentity.Users.ManagePermissions Direct user permissions API (not used by custom edit UI)
AbpIdentity.Roles Open roles
AbpIdentity.Roles.Create / Update / Delete Role CRUD
AbpIdentity.Roles.ManagePermissions Role permission matrix
AbpIdentity.UserLookup Lookups / system tile gates
AbpIdentity.Users.Impersonation Host impersonation where enabled

Host administration

Permission Ability
AuditLogs Audit log screen
HostTenantOverview Host tenant hub
Branding.Manage White label
AbpTenantManagement.Tenants Tenant management

Related

Permission Ability
SettingManagement.Emailing Email settings
AbpAccount.SettingManagement Account settings
FeatureManagement.ManageHostFeatures Host features

The Employee role receives portal permissions (own HR data, leaves, agenda, and similar) — not Identity administration rights.

Parent Identity / administration system opens with Users, Roles, UserLookup, Setting Management, or Feature Management as configured in the system filter.


Appendix A — Quick procedures

A.1 Onboard a system operator

  1. Roles → create role → grant needed module permissions.
  2. Users → add user → assign role → Active.
  3. User signs in at /account/login.

A.2 Onboard an employee portal user

  1. HR → create employee with complete person data.
  2. Confirm Identity user was created and Employee role assigned.
  3. Employee signs in and opens portal account settings to change password.

A.3 Offboard a user

  1. Users → set Active off (and remove sensitive roles).
  2. Optionally delete when policy allows.
  3. For employees, also complete HR exit processes.

A.4 Investigate an API action

  1. Host → Audit logs.
  2. Filter by user, URL, and date.
  3. Open detail for status and entity changes.

Appendix B — Operating notes

Topic Guidance
Source of truth ABP Identity packages + frontend/src/app/components/identity
Person link Set via HR employee flows (PersonId extra property)
Roles first Grant permissions on roles; assign roles to users
Security logs Not a live screen — do not promise login-event browsing here
OUs Not used in UI; organizational structure lives in HR Departments
Multi-tenancy Confirm MultiTenancy:IsEnabled before documenting tenant workflows
Module actors Evaluation and Workflow need PersonId for many actions

Appendix C — Document control

Item Value
Title Identity Module User Guide
Source of truth ABP Identity packages, frontend/src/app/components/identity, HR PersonId integration
Format Markdown + Mermaid (PDF edition embeds rendered figures)
Screenshots Not included (by design)

This guide describes functional capabilities of the Identity / administration area as implemented in the Vertex ERP codebase. UI labels may appear in English or Arabic depending on language settings.