Skip to content

A user cannot change their own password — the Profile screen has no interactive elements at all #492

Description

@Aman-Mittal

What happens

/profile displays Username, Display Name, Office, Email and Roles as static text. It has zero interactive elements:

document.querySelector('main').querySelectorAll('button, a, ion-button, input, ion-input, select, [role="button"]')
// → length: 0

The User Profile screen showing username, display name, office, email and roles as plain read-only rows with no actions

Confirmed in source — src/app/features/profile/user-profile.component.ts is a template of .detail-row spans and ion-chips with no controls of any kind.

The gap is app-wide, not just this screen

There is no change-password capability anywhere in the application:

$ grep -rln "changePassword\|change-password\|CHANGE_PASSWORD" src/app --include=*.ts
src/app/api/model/commandWrapper.ts     # generated API model only

The only hit is in generated API bindings. No component, no route, no service call. app.routes.ts:242 registers profileUserProfileComponent and nothing else.

So a logged-in user has no way to rotate their own password, correct their email, or update any profile field. The only path is an administrator editing them through Users administration.

Why this matters for a production deployment

Password rotation is baseline security hygiene, and in many deployments it is a compliance requirement rather than a preference. Routing every password change through an administrator also means the administrator necessarily learns or sets the user's new credential, which is worse than the user setting it themselves.

The backend already supports it — PUT /users/{id} accepts password / repeatPassword, and Fineract exposes password-preference rules the UI could validate against (/system/password-preferences is already a screen in this app).

Suggested scope

  1. A Change Password action on /profile opening a form with current password, new password and confirmation, validated against the tenant's configured password preferences.
  2. An Edit action for the self-serviceable fields (email at minimum), leaving office and roles administrator-only.

Step 1 is the one that closes the security gap and is worth doing on its own.

Environment

Verified against a clean checkout of main (a24a06ba) served with ng serve, backend sandbox.mifos.community, logged in as mifos, 1366×900, Chrome.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions