Skip to content

Employee self-service: own full profile + Education/Work Experience - #15

Open
hamad-clustox wants to merge 1 commit into
developfrom
feature/employee-self-service
Open

hamad-clustox wants to merge 1 commit into
developfrom
feature/employee-self-service

Conversation

@hamad-clustox

Copy link
Copy Markdown
Collaborator

What & why

The HR manager asked to let each employee see their own full profile (personal details, education, everything) and a scoped dashboard, via the /hrms self-service PWA. Two gaps blocked this:

  1. Our field-level confidentiality layer hid sensitive fields (DOB / phone / CNIC / bank) from the Employee role — which also blanked them on the employee's own profile.
  2. The stock mobile profile never showed Education or Work Experience at all.

This PR closes both while keeping colleagues' confidential data unreachable.

Changes

setup/permissions/apply_self_service.py (new)

  • Record-scopes the Employee doctype to the employee's own record for pure self-service logins (User Permission allow=Employee, applicable_for=Employee).
  • Grants the Employee Self Service role read on permlevel 1 (personal) and 2 (bank). Permlevels aren't record-scoped natively, so the record scope is what makes this safe: an employee can only ever reach their own record.
  • Idempotent; skips broad-role users; re-run after new logins.

hrms/api/get_all_employees — runs with ignore_permissions so the company directory / org chart still lists everyone (only 9 non-confidential fields are returned) despite the record scope.

Frontend — new ProfileChildTableModal.vue renders read-only child-table sections; Profile.vue adds Education (education) and Work Experience (external_work_history), with labels pulled from the child doctype meta (robust to custom fields).

Verification (as a scoped test employee)

  • Own profile: DOB / CNIC / bank visible
  • has_permission("Employee","read", colleague)False
  • permissioned get_list("Employee")1 (own only) ✅
  • directory get_all_employees()all 121 (safe fields) ✅
  • create Leave Type / write others' salary → False

Deploy / ops notes

  • After deploy: bench --site <site> execute hrms.apply_self_service.run, and re-run whenever new employee logins are created (not yet automatic — same gap as scope_employees.py).
  • Frontend requires a yarn build in frontend/ and shipping the built assets.
  • Profile is read-only. Editing should be a later phase, done as an approval-based change request so employees can't alter their own designation/salary.

🤖 Generated with Claude Code

…ience

Let each employee view their OWN full profile in the /hrms PWA (personal
details, CNIC, bank) without exposing any colleague's confidential fields,
and surface Education and Work Experience — which the stock mobile profile
did not show at all.

Backend (setup/permissions/apply_self_service.py):
- Record-scope the Employee doctype to the employee's own record for pure
  self-service logins (User Permission allow=Employee, applicable_for=Employee).
- Grant the "Employee Self Service" role read on permlevel 1 (personal) and 2
  (bank). Because the record is scoped, this can only ever reveal the
  employee's own data — a colleague's record is unreachable even via the API.
- Idempotent; skips users holding a broad role. Re-run after new logins.

hrms/api/get_all_employees: run with ignore_permissions so the company
directory / org chart still lists everyone (only 9 non-confidential fields
are returned) despite the record scope above.

Frontend: new ProfileChildTableModal renders read-only child-table sections;
Profile.vue adds Education (education) and Work Experience
(external_work_history), with labels pulled from the child doctype meta.

Verified as a scoped test employee: own confidential fields visible,
has_permission read of a colleague = False, permissioned Employee list = 1,
directory still lists all, no admin capabilities.

Note: run `bench execute hrms.apply_self_service.run` after deploy, and
re-run whenever new employee logins are created (not yet automatic). Profile
is read-only; editing should be added later as an approval-based change
request so employees cannot alter their own designation/salary.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants