Move user_auth onto the new resource methods

[rtibblesbot]

Summary

• Both facilityusername reads in SignInPage move to list.
• Sign-up POSTs through create, so the payload is no longer nested under data.
• The deprovision queue clear moves to TaskResource.clearAll_v2.

References

Fixes #15067. Recipe: #15057. New methods: #15056.

Reviewer guidance

Code review

• Repeated identical reads now hit the network; the legacy Collection cache was module-level.
• create resolves the response body, not the body merged over the payload. The sign-up .then reads picture_password, which is response-only.
• SignInPage.spec.js mocks kolibri/client rather than the resource: only the boundary proves facility still leaves as a query param, not a getParams blob.

QA steps

No UI changes — sign-in and sign-up should behave as on develop. Rig: a facility with password-free sign-in and account creation enabled (Facility > Settings), 16 users or fewer, three sharing a prefix (alice, alina, alvaro); a second facility with more; the APK for step 2.

1. Suggestions. Type ali on the small facility's sign-in page: the three usernames drop down. Select by mouse, then by arrow keys — both sign in. Backspacing to al empties it, Escape hides it.
2. App context. In the Android app the small facility lists its users instead of a username box, the large one shows the box. Change facility between them shows each facility's own users.
3. Sign up. Create an account with gender and birth year unset: the learner lands on Learn, signed in. An existing username is refused on step one.

Unverified: the deprovision clear tasks path renders only on a device with no usable superuser.

State	Screenshot
Suggestions, search=ali
App-context user list, max_results=16

AI usage

Claude Code applied the recipe and wrote the tests. Verified with the user_auth Jest suite, prek, and the QA above.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Ran pre-flight CI checks (lint, format, tests) and verified all pass
• Rebased onto the target branch and resolved any conflicts
• Reorganized commit history into clean, logical commits
• Audited the diff to ensure only issue-relevant files are changed
• Built PR body from the repository's PR template with evidence blocks

Deviations from the issue spec

Criterion	Why not
Reactive reads use useRetrieve / useList where possible	SignInPage mixes setup() with Options API; per review, useList there splits state across both halves. Both reads use list() instead.

🟡 Waiting for feedback Last updated: 2026-08-28 17:33 UTC

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.20.0a2.dev186_gf2d684f55.pex
Windows Installer (EXE)	kolibri-setup-0.20.0a2.dev186+gf2d684f55-unsigned.exe
Debian Package	kolibri_0.20.0a2.dev186+gf2d684f55-0ubuntu1_all.deb
Debian Package	kolibri-server_0.20.0~a2.dev186+gf2d684f55-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.20.0a2.dev186+gf2d684f55.dmg
Android Package (APK)	kolibri-0.20.0a2.dev186+gf2d684f55-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.20.0a2.dev186+gf2d684f55.zip
TAR file	kolibri-0.20.0a2.dev186+gf2d684f55.tar.gz
WHL file	kolibri-0.20.0a2.dev186+gf2d684f55-py3-none-any.whl

Smoke test screenshot

Download screenshot

[rtibblesbot]

Three red checks, one cause. Build WHL failed in make dist → Makefile:189: staticdeps-cext on a truncated wheel download:

ERROR: Could not install packages due to an OSError: ('Connection broken: IncompleteRead(220864 bytes read, 10598 more expected)')
Installation failed for package cffi-1.15.1-cp310-musllinux_1_1_x86_64.

Both WHL smoke tests failures are the needs gate on that job (exit 1, 2s) — not independent.

Transient PyPI/piwheels truncation rather than anything on this branch:

• The diff is five .vue/.spec.js files under kolibri/plugins/user_auth/frontend/ — no Python, requirements, or build inputs.
• The two failed runs truncate different platform wheels (musllinux_1_1_x86_64, manylinux_2_17_s390x, musllinux_1_1_i686) at identical byte counts — a CDN chunk boundary, not a poisoned .cext_cache, which would fail every run.
• An unrelated branch's WHL build went green at 20:41 UTC, after both failures here.

No code change to push, and re-running the job needs admin rights this account lacks.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

[AlexVelezLl]

Just a little request, please also rebase against develop again.

[AlexVelezLl]

Given that code is split into setup code and options API code, the useList usage has make this a bit harder to follow. Could you please revert the usage of useList here?

[rtibblesbot]

Reverted — created() and setSuggestions() are back in the Options API, with fetchCollection({ getParams }) swapped for list(params). Net diff on this file is now those two calls.

Swept the branch for the same pattern: git grep -n "useList\|useFetch" kolibri/plugins/user_auth/ — those two were the only composable-in-setup() conversions; the other three call sites (SignUpPage, DeviceUnusableMessage) were plain method renames.

Kept the spec on the kolibri/client mock rather than the resource module: it is what proves facility still leaves as a query param instead of a getParams blob.

Rebased onto develop (479b7962c5).

[AlexVelezLl]

Also, @rtibblesbot, please add QA steps for things that QA testing should check for this PR. Similar to other API Resource migration PRs.

[rtibblesbot]

Added ### QA steps to the body, split out from ### Code review: one step per migrated user-facing call site — the suggestions dropdown, the app-context user list, sign-up — plus the facility rig each needs.

Swept the branch's five call sites for flows the section misses: SignInPage's two reads are steps 1–2, SignUpPage is step 3, and DeviceUnusableMessage's clearAll_v2 is called out as unverifiable — it renders only on a device with no usable superuser. Nothing user-facing on this branch is left without a step.

Also force-pushed a history fix: the last self-review cycle left proceedToSignupSubmit hoisted out of its describe in the working tree but not in any commit, so the pushed tip called a helper it never defined. Folded back into the commit that moved it. pnpm test-jest --testPathPatterns user_auth — 14 suites, 140 tests green. Branch is on develop @ 479b7962c5.

[AlexVelezLl]

Thanks @rtibblesbot! Code changes look good, manual QA steps are clear and correct, ready for qa review :)

[rtibblesbot]

Holding off on changes while this PR is in 🧪 Needs QA — the branch will not move while it is being tested. Questions still get answered.

Change the board status when QA is done and I'll pick up any outstanding review feedback, CI failures and conflicts on the next cycle.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Ran pre-flight CI checks (lint, format, tests) and verified all pass
• Rebased onto the target branch and resolved any conflicts
• Reorganized commit history into clean, logical commits
• Audited the diff to ensure only issue-relevant files are changed
• Built PR body from the repository's PR template with evidence blocks

[radinamatic]

All three QA workflows pass:

1. Small facility's sign-in page: usernames drop down works when using both the mouse, and keyboard (backspace and ESC included). ✔️
2. Android app with 2 facilities: the small facility lists its users instead of a username box, the large one shows the box. ✔️

3. Sign up. Create an account with gender and birth year unset: the learner lands on Learn, signed in. An existing username is refused on step one. ✔️

One thing worth mentioning after testing on Android: right after confirming that on the small facility there's a lists of users instead of a username box, and taking the screenshot above, Kolibri app went literally blank (white), and stop responding, even after app restart and/or rebooting the device. Unsure if that is due to the changes in this PR, attaching the logcat and DB/logs:

logcat.txt
logs-db.zip

[rtibblesbot]

Holding off on changes while this PR is in 🧪 Needs QA — the branch will not move while it is being tested. Questions still get answered.

Change the board status when QA is done and I'll pick up any outstanding review feedback, CI failures and conflicts on the next cycle.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Ran pre-flight CI checks (lint, format, tests) and verified all pass
• Rebased onto the target branch and resolved any conflicts
• Reorganized commit history into clean, logical commits
• Audited the diff to ensure only issue-relevant files are changed
• Built PR body from the repository's PR template with evidence blocks

[rtibblesbot]

Thanks @radinamatic — the artifacts are enough to say the blank screen is not coming from this diff.

What the logs show

• The white page is /en/device/, not a sign-in page. admin is a superuser, so /api/device/initialize/… → / → RootURLRedirectView sends every launch to the Device page — which is why a restart and a reboot both land back on it.
• The frontend core stayed alive the whole time it was white: the session heartbeat kept firing on schedule — PUT /api/auth/session/current/ at 03:09:55 and 03:13:55 (port 48197), 03:25:39 (46959).
• What never fired is anything from the Device plugin. Across four launches (03:02:28, 03:03:00, 03:05:53, 03:21:38) GET /en/device/ returns 200 and the core bootstrap calls return 200, then silence — /content's handler never issues a request. Render-side failure, with a healthy server underneath.
• Nothing broke server-side: the only two ERRORs in kolibri.txt are the 03:00:02 perform_vacuum pair ("Cannot operate on a closed database"), the vacuum task racing a server shutdown. Non-fatal, and nothing to do with rendering.
• logcat has no crash, no ANR, no WebView renderer death. The only kills are MIUI's — SwipeUpClean at 03:20:28 and 03:27:26 (swiping from recents) and MiuiMemoryService taking :task_worker at 03:20:27 — all after the fact.

The diff is 5 files, all under kolibri/plugins/user_auth/frontend/. None ships in the device bundle; none is on screen at /en/device/.

Two things would settle it

1. The WebView console. The attached capture is system_server/launcher tags only — the crash buffer is empty and there are no app or chromium console lines. adb logcat chromium:I *:S during a repro would name the exception.
2. The Device page on a develop APK — separates branch from baseline.

One question: kolibri.txt has no HTTP access lines at all between 02:52:05 (Bus state: EXITED) and 03:02:26, which is exactly your step 2/3 window — so I can't see the sign-in requests. Was the app force-stopped, or the server stopped, around then?

No code changes while this is in 🧪 Needs QA. If it turns out to be real, filing it with these artifacts is deferred until QA finishes.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

[pcenov]

@radinamatic - after further investigation I can confirm that the white screen issue can be traced back to the changes made in learningequality/kolibri-installer-android#259.

It can be replicated by the following steps:

1. Launch the Android app.
2. Go through the Setup Wizard: Group learning > Full device > Create a new learning facility > Non-formal facility
3. Once at the Device > Channels page click the Menu icon and then click 'Sign out'
4. Force close the app
5. Launch the app again and observe the white screen

Logs, DB and logcat logs: android-logs.zip

Also a note that the issue is not happening if I have gone through the Setup Wizard > On my own workflow.

[rtibblesbot]

Thanks @pcenov — filed as #15232 with both sets of artifacts.

Your repro ran on release 0.19.4 (New install, version: 0.19.4, Chaquopy paths in logcat), so this PR's code is not in that binary — the APK built here is 0.20.0a2.dev155+g01969faf3. Nothing to change on this branch. Since kolibri-installer-android is archived, the issue is on learningequality/kolibri against platforms/android.

Two things from your logs that went into it:

• Sign-out saves /en/auth/ as the restored path and the app-key re-login redirects past it to /en/device/ — but that chain is not required: the next launch (19:25:15) restores /en/device/ directly and is white too.
• Neither capture has WebView console lines. adb logcat chromium:I *:S during a repro is what names the exception.

#15232 has no issue type — this account can't call UpdateIssueIssueType, so someone with write access needs to set Bug.

QA is green (thanks @radinamatic) and CI is green. This PR needs a re-review to clear the earlier CHANGES_REQUESTED, @AlexVelezLl.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

[rtibblesbot]

Rebased onto develop @ 109027298c (31 commits, no conflicts, diff byte-identical).

Checked the rebase for semantic risk: git log 479b7962c5..upstream/develop -- packages/kolibri/apiResource.js packages/kolibri/apiResources/TaskResource.js kolibri/plugins/user_auth/ is empty — none of the new commits touch the resource layer or this plugin.

pnpm test-jest --testPathPatterns user_auth — 14 suites, 140 tests green. prek run --from-ref upstream/develop --to-ref HEAD clean.

No other outstanding feedback: the useList revert landed in 3844180752 and QA is green (5433436999). @AlexVelezLl this needs a re-review to clear the CHANGES_REQUESTED.