adjustment as per new signup form in app

[vvshk]

No description provided.

[claude]

Claude finished @vvshk's task in 4m 32s —— View job

---

PR Review: adjustment as per new signup form in app

I reviewed the diff against origin/dev (4 files, +742/−272). The refactor to reference-phone lookup + department/seva-kutir handling is solid and internally consistent, and the Prettier reformat is welcome. I left 6 inline comments — none are hard blockers, but two are worth resolving before merge.

• Read repo conventions & context (no CLAUDE.md present)
• Review admin/card/createCard.html
• Review admin/card/createCard.js
• Review admin/card/updateCard.html
• Review admin/card/updateCard.js
• Post inline findings & summary

---

Key findings (inline)

🟠 Should address

1. Phone lookup skips auth & error handling — the checkMobile call hits the client API (CONFIG.baseUrl) with no Authorization header (every other request here sends a token; there's even an authenticated admin card/by-mobile endpoint). It also never checks res.ok, so a 401/500 renders as the misleading "Phone number is not registered!". createCard.js · updateCard.js
2. updateCard submits stale referencePhone/guestType/department regardless of res_status, because hidden fields aren't cleared. Switching a GUEST/SEVA KUTIR card to MUMUKSHU still sends the old values. createCard.js already does this correctly (conditional attach). Inline + suggestion →

🟡 Worth confirming / nice-to-have
3. Empty cardno submitted — the field is now readonly/auto-generated but nothing sets its value, so cardno: "" is sent. Confirm the backend generates it (or omit the key). Inline →
4. No debounce + duplicated logic — the reference-phone handler fires per keystroke (out-of-order responses can show stale names) and is copy-pasted between the two files; consider a shared helper. Inline →

👍 Looks good

• referencePhone / guestType / department field names are consistent across both forms and payloads.
• Required-field validation for GUEST and SEVA KUTIR with early return + button re-enable; double-submit guard retained.
• updateCard correctly awaits loadDepartments() before populating, so the saved department resolves to an existing option.

Note: I reviewed for correctness/conventions only and did not run a linter or tests (this is a static frontend with no test suite in the repo).
· feat/signup-form

[claude]

Missing auth header + no res.ok check on the phone lookup.

Every other fetch in this codebase sends Authorization: Bearer <token>, and there's already an authenticated admin endpoint for mobile lookups — ${CONFIG.basePath}/card/by-mobile/${mobno} (see admin/wifi/permanentCodeRequests.js:408). This new call instead hits the client API (CONFIG.baseUrl, not basePath) with no token.

• If /client/checkMobile requires auth, this will 401. Because the code never checks res.ok and only reads data.exists, the admin will always see the misleading "Phone number is not registered!" message instead of an error.
• Please confirm the endpoint is intentionally public. If it isn't, switch to the authenticated admin endpoint.

At minimum, guard on the response status:

Suggested change

	const res = await fetch(
	`${CONFIG.baseUrl}/client/checkMobile/${val}`
	);
	const res = await fetch(
	`${CONFIG.baseUrl}/client/checkMobile/${val}`
	);
	if (!res.ok) {
	nameEl.textContent = 'Error checking phone number';
	nameEl.style.color = '#c62828';
	return;
	}

[claude]

Same phone-lookup concern as in createCard.js: this hits the client API (CONFIG.baseUrl) with no Authorization header — a deviation from every other request here — and never checks res.ok, so an error response silently renders as "Phone number is not registered!". Please verify the endpoint is public; otherwise use the authenticated admin lookup. A minimal safety guard:

Suggested change

	const res = await fetch(`${CONFIG.baseUrl}/client/checkMobile/${val}`);
	const data = await res.json();
	const res = await fetch(`${CONFIG.baseUrl}/client/checkMobile/${val}`);
	if (!res.ok) {
	nameEl.textContent = 'Error checking phone number';
	nameEl.style.color = '#c62828';
	return;
	}
	const data = await res.json();

[claude]

Stale data: referencePhone / guestType / department are always submitted regardless of res_status.

These fields are hidden (not cleared) when the status changes, and populateForm fills them from the fetched record. So editing a card that was a GUEST/SEVA KUTIR and switching it to MUMUKSHU/PR will still send the old reference phone / guest type / department to the backend.

createCard.js handles this correctly by only attaching these keys inside the matching res_status block. Mirror that here so irrelevant fields are sent as null:

Suggested change

	referencePhone: document.getElementById('referencePhone')?.value || null,
	guestType: document.getElementById('guestType')?.value || null,
	department: document.getElementById('department')?.value || null
	referencePhone:
	document.getElementById('res_status').value === 'GUEST'
	? document.getElementById('referencePhone')?.value || null
	: null,
	guestType:
	document.getElementById('res_status').value === 'GUEST'
	? document.getElementById('guestType')?.value || null
	: null,
	department:
	document.getElementById('res_status').value === 'SEVA KUTIR'
	? document.getElementById('department')?.value || null
	: null

[claude]

Two smaller points on this listener:

1. No debounce / out-of-order responses. A request fires on every keystroke once the value hits 10 chars (and again on each subsequent edit). Since responses are async, a slower earlier request can resolve after a later one and overwrite the label with stale data. Consider debouncing, or tracking the latest query and ignoring outdated responses.
2. Duplication. This inline handler is a near-exact copy of checkReferencePhone() in updateCard.js. Extracting a shared helper (or reusing the same function name/logic) would keep the two forms in sync as this evolves.

Neither blocks the PR, but worth cleaning up while the code is fresh.

[claude]

cardno is now readonly / auto-generated and lost its previous required + pattern="[0-9]{10}". Nothing in createCard.js populates this field, so the submit handler sends cardno: form.cardno.value as an empty string (createCard.js:231).

Please confirm the /card/create backend treats an empty cardno as "generate one". If it still validates the format, "" will be rejected; if it auto-generates, consider dropping cardno from the request payload entirely to make the intent explicit.