Setup Wizard : 'Password field is empty in FacilityImportResource.grantsuperuserpermissions API call'

[Abhishek-Punhani]

Observed Behavior

During the “Import all data from an existing learning facility” flow, the password is always sent as an empty string when calling:

return FacilityImportResource.grantsuperuserpermissions({
  user_id: this.selected.value,
  password: this.password,
});

Even though the user enters a password in the field, the payload shows password: "". This prevents the API request from running as expected, resulting in a broken onboarding flow.

Steps to Reproduce

• Install build asset from “Conditionalize hideContinue...” Conditionalize hideContinue on whether we are displaying an error or not #12893 on Device A.
• Install the same build on Device B.
• On Device A, set up a facility (or multiple facilities).
• On Device B, choose “Import all data from an existing learning facility” and proceed.
• At step 4, when selecting a super admin and entering the password, observe the password is empty in the request payload.

Expected Behavior

The password typed in the input should be included in the API call body, and the super admin setup should succeed without sending an empty string.

Additional Notes

• After continuing beyond step 4,with a condition that in case this.password=="" , the onboarding redirects to Learn with “No resources available.”
• To run an additional Kolibri instance in parallel, firstly run yarn run devserver and than set a new KOLIBRI_HOME and a different port:

export KOLIBRI_HOME="/path" kolibri start --port=8002 --foreground --settings=kolibri.deployment.default.settings.dev

Then unset KOLIBRI_HOME before returning to your normal development server:

unset KOLIBRI_HOME 
yarn run devserver

To again use that folder for other instance just delete that directory and run command again

Screencast.from.02-24-2025.04.22.05.PM.webm

[marcellamaki]

Thank you for reporting this, @Abhishek-Punhani!

[rtibbles]

@pcenov @radinamatic to reproduce.

[pcenov]

Hi @Abhishek-Punhani and @rtibbles - this seems like a good explanation for the cause of the issue described by me in #12894 but I would expect that to be mentioned in the original issue and be the basis for resolving it. So I'm not sure why it's reported as a duplicate issue here?

Here's a video of what I am observing in both latest develop and the build asset from #12893:

2025-02-26_12-13-51.mp4

cc @radinamatic

[MisRob]

Hi @pcenov, that's on me. From all what we know, it could indeed be the same issue - it's possible I didn't connect the dots. It sounded to me that @Abhishek-Punhani was describing somewhat related but different issue around not sending password at all that we may nee to prioritize much higher compared to the original.

In any case, @Abhishek-Punhani since we prioritized this as critical and we are shortly before a new release, it is likely we will need to assign this to a team member. In any case, your findings are important and will help to prevent from potentially significant problem - thank you so much.

[pcenov]

Thanks for clarifying that @MisRob!

Here are also the logs from both devices in case they are needed:

server-logs.zip
importing-device-logs.zip

[Abhishek-Punhani]

@pcenov @MisRob , I'm not sure that solving this bug will solve #12894 . It may be possible we may need to debug that issue somewhat even after this issue is solved, that's what I thought.

[MisRob]

Alright, well we will see after we fix this one and then can decide on next steps :)