Helpers HMS Administration & Permissions

This guide is for administrators responsible for user access, roles, security, and operational configuration in Helpers HMS.

Critical rule: Never publish invented group names or permission behavior. Verify all groups, ACLs, record rules, and menu visibility against the actual deployed code and database.

1. Administration responsibilities

An HMS administrator may be responsible for:

Creating users
Assigning access groups
Managing company access
Configuring healthcare roles
Reviewing menu visibility
Managing record-level access
Supporting users who receive access errors
Maintaining selected HMS settings

2. Creating a user

In standard Odoo, user administration is typically available under:

Settings
→ Users & Companies
→ Users

TODO: Verify the exact menu path in the Helpers ERP deployment.

Configure:

Name
Login / Email
Company access
Allowed companies
Application permissions
HMS-related groups
Other role-specific access

Do not give administrator privileges to normal operational users.

3. Role design

Helpers HMS should use role-based access.

Typical conceptual roles may include:

HMS Administrator

Reception

Physician / Doctor

Nurse

Billing / Accounting

Specialized users

Specialized users may include:

Laboratory
Radiology
Pharmacy
Hospitalization
Surgery
Insurance
Other installed modules

The final documentation must replace these conceptual roles with the actual groups available in the deployed instance.

4. Access rights vs record rules

Access Control Lists

ACLs determine whether a group can:

Read
Create
Write
Delete

a model.

Record Rules

Record rules control which records a user can access.

Menu and view visibility

A user may also see different:

Menus
Buttons
Fields
Views
Actions

based on their groups.

5. Why two users may see different data

Possible causes include:

Different security groups
Different companies
Different departments
Physician-specific rules
Record ownership
Record rules
Different date filters
Different active/archive status
Different installed modules

6. Recommended least-privilege policy

Give each user only the access needed to perform their job.

Recommended approach:

Start with the operational role
→ Add only required permissions
→ Test with a non-admin account
→ Confirm menus and records
→ Document exceptions

7. User onboarding checklist

[ ] User created
[ ] Correct company assigned
[ ] Correct HMS role assigned
[ ] Required menus visible
[ ] Restricted menus hidden
[ ] Patient access tested
[ ] Appointment access tested
[ ] Clinical access tested if required
[ ] Billing access tested if required
[ ] Login tested using the real user account

8. Permission testing

Test representative accounts separately:

Reception Test User
Doctor Test User
Billing Test User

For each role, confirm:

Which menus appear
Which records are visible
Whether create is allowed
Whether edit is allowed
Whether delete is allowed
Which buttons are available
Whether reports can be printed
Whether other users' records are visible

9. Administrator audit for the implementation agent

For every HMS-related group, extract:

Group technical name
Display name
Implied groups
Menus
Model access
Important record rules
Main user role

Inspect:

security/*.xml
security/ir.model.access.csv
views/*.xml
models/*.py

Also inspect database-defined groups and rules where required.

10. Department-based access

Verify:

Can a doctor see all departments?
Can a doctor see only their department?
Can reception see appointments across departments?
Are medical records restricted by department?
Is department access implemented by record rules or custom fields?

11. Physician-specific access

Document:

Which appointments a physician sees
Whether physicians can see other doctors' appointments
Which group grants broader appointment visibility
Whether the rule applies to patient records or only appointments

12. Troubleshooting permissions

User cannot see an HMS menu

Check:

User is active.
User has the correct company.
Required HMS group is assigned.
Parent menu groups permit access.
Required module is installed.
Browser session has been refreshed.

User sees the menu but cannot open records

Check ACLs, record rules, company restrictions, department rules, and physician-specific rules.

User can open records but cannot edit

The user may have read access without write access.

User can see too many records

Review record rules immediately.

Do not solve overexposure by only hiding menus.

13. Backup and operational access

HMS users should not automatically receive access to:

Database administration
Server shell
Backups
Docker
PostgreSQL
Odoo configuration files
Helpers ERP infrastructure

14. Recommended documentation matrix

Feature	Reception	Physician	Billing	HMS Admin
View Patients	Verify	Verify	Verify	Verify
Create Patients	Verify	Verify	Verify	Verify
Manage Appointments	Verify	Verify	Verify	Verify
Clinical Notes	Verify	Verify	Verify	Verify
Prescriptions	Verify	Verify	Verify	Verify
Billing	Verify	Verify	Verify	Verify
User Administration	Verify	Verify	Verify	Verify

Replace every Verify with a value confirmed from the deployed implementation.

15. Security documentation rule

Every published permission statement should be traceable to one of:

Installed module source code
Odoo security configuration
Live non-admin user test
Database configuration
Approved customer configuration

16. Suggested Quick Demo behavior

For public Quick Demo sessions:

Do not expose administrator settings unless intentionally required.
Use controlled demo users.
Prevent infrastructure access.
Reset or delete session data according to Quick Demo lifecycle rules.
Keep demo permissions consistent between sessions.
Document which demo role the visitor receives.

Suggested text:

The Quick Demo uses a controlled demonstration account. Some administrative features may be unavailable in the public demo.

Back to documentation

Return to:

Getting Started

Medical Workflow