# User Management & Security User Management & Security covers everything related to user accounts, personal profiles, and the permission system that controls what each user can see and do inside OtisEd.Nimble. Administrators manage user accounts and assign role-based access. End users manage their own profile information and can review their current roles and permissions. ## Table of Contents * [Overview](#overview) * [User Administration](#user-administration) * [Searching for Users](#searching-for-users) * [Editing a User Account](#editing-a-user-account) * [Deleting a User Account](#deleting-a-user-account) * [Unlinking External Logins](#unlinking-external-logins) * [User Permissions (Admin)](#user-permissions-admin) * [Viewing a User's Current Permissions](#viewing-a-users-current-permissions) * [Adding a Permission](#adding-a-permission) * [Removing a Permission](#removing-a-permission) * [Setting the Default Role](#setting-the-default-role) * [My Profile](#my-profile) * [Editing Profile Information](#editing-profile-information) * [Changing Your Profile Image](#changing-your-profile-image) * [Viewing Your Roles and Permissions](#viewing-your-roles-and-permissions) * [Message History](#message-history) * [Security Model Overview](#security-model-overview) * [Security Users](#security-users) * [Security Modules](#security-modules) * [Security Menus](#security-menus) * [Security Routes](#security-routes) * [Security Report Groups](#security-report-groups) * [Authentication Providers](#authentication-providers) * [User Login Tracking](#user-login-tracking) * [Troubleshooting](#troubleshooting) *** ## Overview OtisEd.Nimble uses a layered security model. At the foundation, every person has an **identity account** (username, email, name, phone). On top of that, one or more **Security User** records link each identity account to an **organization unit** and a **role**. Those roles then determine which modules, menus, application routes, and report groups a person can access. Administrators control this through the **User Administration** page. Individual users can update their own contact details and language preference through the **My Profile** page. *** ## User Administration The **User Administration** page is the central hub for managing all user accounts in the system. It is available to users who hold the appropriate administrative permission. ### Searching for Users 1. Navigate to **User Administration** in the portal menu. 2. In the search bar, type at least three characters to search by username, email, first name, or last name. 3. The table updates automatically as you type. You can also click **Refresh** to reload the full list. 4. The table shows each user's username (displayed as a link), first name, last name, email, creation and modification dates, and the date and time of their last successful login. 5. You can sort the list by clicking any column heading, and you can page through results using the pagination controls at the bottom. Page sizes of 10, 25, 50, or 100 records are available. If you arrive at the User Administration page from a link that includes an email address (for example, from a notification or workflow), the search field is pre-filled with that email and the results load automatically. ### Editing a User Account 1. Click the username link in the table. An **Edit User** dialog opens. 2. The following fields are editable: * **First Name** (required, 2–250 characters) * **Last Name** (required, 2–250 characters) * **Email** (required, 2–250 characters) * **Phone Number** (optional) 3. The **Username** field is read-only and cannot be changed from this screen. 4. Click **Save** to apply the changes or **Cancel** to discard them. A success notification confirms the update. ### Deleting a User Account 1. Locate the user in the table and click the **Delete** (trash) icon in the Actions column. 2. A confirmation dialog appears with the user's username and email. Confirm to proceed or cancel to return to the list. 3. Deleting a user is permanent. The user's login history and any associated security assignments are removed. > Deleting a Security User assignment also automatically removes the corresponding role from the user's identity account, and the system rebuilds that user's page filters to reflect the change. ### Unlinking External Logins Users who sign in through an external identity provider (such as Azure AD, Azure B2C, or RapidIdentity) accumulate external login records that link their provider identity to their portal account. If a user switches providers, changes their organizational account, or encounters sign-in problems, an administrator can remove these external login links. 1. Locate the user in the table and click the **Unlink Logins** icon in the Actions column. 2. A confirmation dialog asks you to verify the action for the named user. 3. Confirm to remove all external login associations. The user will need to re-authenticate through their provider the next time they sign in. 4. A success notification appears after the logins are removed. *** ## User Permissions (Admin) Permissions in OtisEd.Nimble are always scoped to a combination of **organization unit** and **role**. To grant a user access to a part of the system, you assign them at least one organization-unit/role pair. ### Viewing a User's Current Permissions 1. Locate the user in the **User Administration** table. 2. Click the **Permissions** (key) icon in the Actions column. The **Current Roles** dialog opens. 3. The dialog lists all existing organization-unit/role assignments for that user as individual cards. Each card shows the organization unit name and the role name. 4. One assignment can be marked as the **Default**. The default assignment is used when the system needs to resolve the user's primary context. ### Adding a Permission 1. Open the **Current Roles** dialog for a user (see above). 2. Click **Add Permission**. A two-step wizard appears inside the dialog. **Step 1 — Select Organization:** * A searchable, paginated table lists all available organization units. * Filter by name, import ID, or type using the search fields at the top. * Click the **Select** icon next to the organization unit you want. **Step 2 — Select Roles:** * The dialog shows the roles available for the selected organization unit's type. * Roles are split into two columns: **Selected** and **Available**. * Click a role to move it between columns. * Only roles that are not already assigned to the user for this organization unit are shown as available. * Click **Save** to confirm your selections, or **Back to Organization List** to choose a different organization. 3. After completing the wizard, the new assignment appears in the Current Roles list. 4. Click **Save** in the main dialog to commit all pending changes. Changes are not saved until you click this button. > All pending additions, updates, and deletions are queued in the dialog and applied in sequence when you click Save. A success notification confirms each operation. ### Removing a Permission 1. In the **Current Roles** dialog, click the **Delete** icon on the permission card you want to remove. 2. The card is immediately removed from the list (pending save). 3. Click **Save** to commit the removal. The system removes the assignment and rebuilds the user's page filters automatically. ### Setting the Default Role 1. In the **Current Roles** dialog, click the **Default** toggle on the permission card you want to designate as primary. 2. Only one assignment can be the default at a time. Setting a new default automatically clears the flag from the previous default. 3. Click **Save** to persist the change. *** ## My Profile Every signed-in user has access to their own **My Profile** page. This page is divided into tabs. ### Editing Profile Information 1. Navigate to **My Profile** from the user menu or portal navigation. 2. The **Profile** tab opens by default. 3. The following fields are available: * **Username** (read-only) * **First Name** (required, 2–250 characters) * **Last Name** (required, 2–250 characters) * **Email** (required, 2–250 characters) * **Phone Number** (optional) * **Default Language** — choose between English and Spanish. Selecting a language activates the portal's translation layer immediately. 4. Click **Save** to apply your changes. Clicking **Cancel** returns you to the home page. ### Changing Your Profile Image 1. From **My Profile**, click the **My Profile Image** tab. 2. Upload or replace your profile photo using the image form on this tab. 3. Save to apply the new image. The page refreshes to reflect the update throughout the portal. ### Viewing Your Roles and Permissions 1. From **My Profile**, click the **My Roles/Permissions** tab. 2. This tab shows a read-only view of your current organization-unit/role assignments — the same data an administrator sees when managing your permissions. 3. One assignment is marked as your default. ### Message History 1. From **My Profile**, click the **Message History** tab. 2. This tab displays a history of alert messages and notifications sent to your account. *** ## Security Model Overview OtisEd.Nimble extends ABP Framework's identity system with a set of custom security entities. Together they define not just who can log in, but what each person can see and do once they are inside. ### Security Users A **Security User** record binds a portal identity account to a specific organization unit and role. A single person can have multiple Security User records — one per organization unit they belong to, each potentially with a different role. Key properties of each Security User record: | Property | Description | | ----------------- | --------------------------------------------------------------- | | User | The identity account this record belongs to | | Organization Unit | The organization or sub-organization this assignment applies to | | Role | The role granted to this user within that organization unit | | Is Default | Whether this is the user's primary assignment | When a Security User record is created or deleted, the system automatically adds or removes the corresponding role from the user's identity account, and rebuilds the user's page filters to ensure dashboards and reports reflect the updated access. ### Security Modules Modules are the top-level functional areas of the portal (for example, a data collection module or a reporting module). A **Security Module** record ties a role to a module, granting all users holding that role access to that module. Roles without a Security Module record for a given module cannot access it. ### Security Menus Navigation menus in the portal are also role-controlled. A **Security Menu** record ties a role to a specific menu item. Users only see menu items for which their assigned role has a corresponding Security Menu entry. This keeps the navigation clean and relevant for each audience. ### Security Routes Application routes are the individual pages or views within the portal. A **Security Route** record ties a role to a specific route. If a user's role does not have a Security Route entry for a page, the portal can restrict navigation to that page. This provides granular, page-level access control layered on top of module and menu visibility. ### Security Report Groups Report groups organize reports into logical sets. A **Security Report Group** record ties a role to a report group, so only users whose role includes a Security Report Group entry for that group can see the reports inside it. This is the primary mechanism for scoping data visibility to the correct audience in a multi-organization environment. *** ## Authentication Providers OtisEd.Nimble supports multiple external identity providers. The provider used depends on how your organization's tenant is configured. End users do not choose a provider at login — the portal routes them to the correct provider automatically. | Provider | Use case | | ------------------------------------------ | ------------------------------------------------------------------------------- | | **Azure Active Directory (Azure AD)** | Organizations using Microsoft Entra ID (corporate or district Azure AD tenants) | | **Azure Active Directory B2C (Azure B2C)** | Consumer-facing or federated scenarios with a dedicated B2C directory | | **RapidIdentity** | Districts and organizations using the RapidIdentity identity platform | When a user signs in through any of these providers, the provider identity is linked to the user's portal account via an external login record. Administrators can remove these links using the **Unlink Logins** action in User Administration if a user needs to re-authenticate or switch providers. All providers use OpenID Connect (OIDC) under the hood. The portal's ASP.NET Core authentication layer manages token exchange and session management transparently. *** ## User Login Tracking The portal records every successful login event. This data is visible in two places: * **User Administration table** — the **Last Login** column shows the most recent successful login date and time (UTC) for each user. This field is sortable. * **Security logs** — the underlying identity security log captures the full history of `LoginSucceeded` events per user, which supports auditing and troubleshooting. Login timestamps are stored in UTC and displayed in the portal in `mm/dd/yyyy hh:mm` format. *** ## Troubleshooting **A user cannot see a menu item or page they should have access to.** Verify that the user has a Security User record with the appropriate role for the relevant organization unit. Then confirm that the role has Security Menu and Security Route entries for the item in question. After making changes, use the **Build Page Filters** action (available from User Administration) to force a rebuild of the user's access filters. **A user's Last Login column is blank.** The user has not yet completed a successful login, or their login history predates when login tracking was introduced. This is informational and does not affect access. **A user sees a "no restrictions selected, all users will have access" message in the Permission Restrictions dialog.** This means no role-based restrictions have been configured for the item being edited. Any authenticated user with general access can reach it. Add one or more roles to the restrictions list to limit visibility. **An administrator receives an error when creating or deleting a permission.** The most common causes are a missing organization unit selection (step one of the wizard must be completed before roles can be selected) or a missing role selection (at least one role must be chosen before clicking Save in step two). Review the error message in the dialog for specifics. **A user's page filters appear stale after a permission change.** Page filters are rebuilt automatically when Security User records are created, updated, or deleted. If a filter rebuild fails (for example, due to a transient error), an administrator can trigger a manual rebuild by clicking the **Build Page Filters** option for that user in User Administration. **A user cannot sign in after being unlinked from an external provider.** After unlinking, the user must sign in again through their identity provider. If the provider is Azure AD or B2C, they may need to clear browser cookies or use a private browsing window to force a fresh authentication flow. Contact your system administrator if the issue persists. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://nimble.docs.otised.com/guides/user-management-security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.