[
https://issues.apache.org/jira/browse/FINERACT-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy updated FINERACT-2947:
---------------------------------
Fix Version/s: 1.16.0
> Users: after changing a user's office from Office A to Office B, the Users
> section can no longer be opened ("Staff with identifier 11 does not exist")
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2947
> URL: https://issues.apache.org/jira/browse/FINERACT-2947
> Project: Apache Fineract
> Issue Type: Bug
> Components: Client, User Management
> Reporter: Foo Developer
> Assignee: Foo Developer
> Priority: Major
> Labels: Beginner, beginner-friendly
> Fix For: 1.16.0
>
>
> Module
> Admin > Users (user office assignment and the users list / user details APIs).
> Preconditions
> A portal user exists in Office A and is linked to a staff member (staff ID
> 11) who belongs to Office A.
> Logged-in user has permission to view and edit users.
> Steps to reproduce
> Go to Admin > Users and open the user.
> Edit the user and change the Office from Office A to Office B, then save.
> Go back to Admin > Users (or reload the portal).
> Expected result
> The office change is saved and the Users section keeps loading normally. If
> the linked staff member does not belong to the new office (or its hierarchy),
> the update should either be rejected with a clear validation message, or the
> staff link should be cleared/handled, instead of leaving the user in an
> inconsistent state.
> Actual result
> The office change is saved, but the Users section is no longer accessible.
> The portal shows the error toast "Staff with identifier 11 does not exist"
> (also shown on the Home page after login), and the users list / user details
> do not load.
> Impact
> Admins lose access to user management after a routine office reassignment.
> Users cannot be viewed or corrected from the portal to undo the change, so it
> needs a backend/database fix to recover.
> Suspected root cause
> The user's office is updated, but the staff link (staffId 11, belonging to
> Office A) is kept. When the user/staff data is read, the staff lookup is
> scoped to the new office hierarchy (Office B), so staff 11 is not found and
> StaffNotFoundException ("Staff with identifier 11 does not exist") is thrown,
> breaking the whole response. Suggested fix: validate on user update that the
> linked staff belongs to the selected office hierarchy (reject otherwise, or
> clear the staff link), and make the users read path not fail entirely when a
> linked staff record is outside the office scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
