Personal and account settings

What account settings control

Account settings are personal. They affect the signed-in user, not the whole lab company. A user can update profile details, personal photo, phone number, date of birth, bio, language preference, password, multi-factor security, and in some cases notification preferences. Administrators still manage staff role, branch assignment, access roles, and direct permissions from the Users page.

This separation keeps responsibility clear. A receptionist can update a phone number or password without changing branch access. A manager can opt into operational alerts without changing the lab's report template. An owner can secure the account while administrators continue to control company-wide setup from Lab Settings, Branches, Report Settings, and Permissions.

Basic information

The profile form includes profile photo, name, email, phone number, and date of birth. Name and email identify the user inside the Lab Panel, activity logs, assignments, and notifications. Phone number helps the team contact the user during shift coordination or branch handover. Date of birth is optional personal information and should only be completed when the user is comfortable storing it.

Profile photos are public staff images, not private documents. Kashef accepts JPEG, PNG, or WebP up to 2 MB, generates the stored filename, and resizes the image to 512 × 512 pixels through the image editor. Choose a professional image without a patient, report, sample label, identity document, staff badge, password, QR code, or other confidential detail. Order and clinical evidence must never be uploaded as a profile photo.

About section

The About section contains an optional bio. Use it for short internal context such as role summary, specialization, branch responsibility, or contact note. Keep it professional. It is not a place for passwords, personal medical information, payment details, or private notes about patients.

Managers can use bios to make staff directories easier to read, but the real source of permissions is still the Users page. A bio that says "senior technician" does not grant result release permission.

Notification settings

Managers can control two optional in-app categories. Optional in-app order changes covers created orders, routine status updates, sample updates, results added, and order completion. Optional QC warnings covers warning-level QC results that need manager follow-up. Turning either option off stops only that routine category.

Rejected, failed, or error QC, overdue sample follow-up, and overdue instrument-service alerts are mandatory safety notices. They continue to reach every manager assigned to the affected branch even when optional notices are disabled. These safety categories cannot be switched off from the profile.

Kashef currently delivers these alerts through the retained in-app database channel. Email, SMS, and push are not active until an administrator configures and verifies those channels. Read notices remain in notification history unless a user intentionally clears that history.

Set Notification Timezone before setting quiet hours. Quiet hours use a 24-hour start and end time in that timezone and reserve future email, SMS, or push delivery; in-app notices continue immediately. Both times must be provided together. Mandatory safety escalation may bypass quiet hours. When queued external channels are enabled, transient failures are retried, while unresolved QC, sample, and instrument events escalate to branch managers under their workflow SLA.

Use notifications as a management aid, not as the only control process. A manager should still review the dashboard, results queue, QC results, and activity logs during important shifts. If too many notifications are noisy, review workflow discipline and responsibility assignments before turning everything off.

In the notification drawer, the close-shaped item control is named Mark notification as read. It changes the unread state; it does not delete the alert. Kashef confirms the change, keeps the item in notification history, and offers Undo. Use Clear notifications only when you intentionally want to remove the stored notification history shown in the drawer.

Language and direction

Kashef supports English and Arabic. The locale can be updated through the language switcher and is stored on the user account when signed in, then saved in the session and a long-lived cookie. Arabic switches the interface into right-to-left direction where supported.

If the panel appears in the wrong language, switch the locale and reload the page if needed. If the language keeps reverting, check whether the user account has a stored locale and whether the browser is using an older cookie. Language changes do not change permissions, records, prices, or workflow states; they only change labels, direction, and translated content.

Password and current-password confirmation

The security section lets a user change credentials. Changing the password requires the current password. This protects the account if someone opens an unlocked workstation. Use a strong password that is not shared with other users or external services.

Managers and owners should never share one account across multiple staff members. Shared accounts make activity logs unreliable. If a staff member needs access, create a real user account, assign the correct branch and role, and let them set or receive their own password.

Saved machines and account switching

When signing in, a user can choose Save account on this machine. This does not keep the user permanently logged in. It saves the account name and avatar on that browser so the next login can start by choosing the account and entering only the password.

If several staff members use the same workstation, each saved account appears on the login page. While the browser remains open and the user has not explicitly logged out, a saved account can be switched back to without typing the password. After logout or closing the browser, the account may still be listed, but the password is required again.

The user menu includes Switch account. Use it to open the login screen without logging out of the current account, then pick a saved account or sign in with a new account. Use the normal Log out action when the user is finished with the workstation.

The profile page separates Saved login shortcuts from Active authenticated sessions. A shortcut only controls whether the account appears on that browser's login screen; it does not prove that the browser is signed in. The session list always identifies the current browser and shows the device, network address, relative activity, and exact activity time.

Revoke one session if you do not recognize it, or use Sign out all other sessions after a lost device or suspected exposure. Revoking a session also disables temporary passwordless switching on every saved shortcut, so those browsers must enter the password again. Removing a shortcut does not sign out an active session. Central listing and remote revocation require the server's database session driver; the profile warns clearly if only the current browser can be shown.

Two-factor authentication

If multi-factor authentication is enabled for the panel, the profile page shows a Two-factor authentication (2FA) section. Available providers are listed by the panel configuration, and enabled providers are shown first. Owners, managers, finance users, and users who can release results or change settings should use 2FA whenever possible.

After enabling 2FA, store recovery details securely. Do not leave recovery codes on the same workstation used for daily reception or result entry.

Danger zone

The profile page includes a delete-account action. In this application the action deactivates access by soft deleting the account, signs the user out, invalidates the session, and preserves historical records and resource involvement. It requires current-password confirmation.

Do not use this action for normal staff offboarding without a plan. If a staff member is leaving, a manager should review ownership of open work, branch responsibilities, pending approvals, and activity history first. Administrators may need to adjust access from the Users page instead of asking the user to delete their own account.

Good practice

Every user should confirm name, email, phone, language, and password during onboarding. Managers should enable relevant notifications and 2FA. Owners should periodically review that staff accounts still match real roles and that former employees no longer have access.

If a user cannot access a page after updating settings, check the selected branch, assigned branches, access roles, direct permissions, subscription feature availability, and whether the user needs to sign out and sign in again.