MegaMoveDB — internal engineering note

Upload wizard debugging session

Seven bugs, told as what the user did, what went wrong, what should have happened, and how each was fixed — plus a follow-up audit of what's still broken in the deployment-metadata upload wizard.

7
Bugs fixed & verified
9
Open issues found in audit
2×
Full wizard re-run, clean
114
Automated tests still passing

BackgroundContext

The current codebase was inherited from a previous developer, handed over as a single squashed commit — 2026-01-12 for the backend, 2026-03-10 for the frontend, authored by prateek. We're calling this the Mobikasa baseline. Since then (2026-08-11–12) the current team ran a large security/refactor pass — auth scoping, removal of dynamic eval validation, telemetry hardening, wizard-component extraction — tracked as Plans 001–008.

Reported symptom: partway through the upload wizard, after choosing a date format and then UTC/timezone settings, the app returned HTTP 400 with the message "Please check the date format" and couldn't proceed. All seven bugs below were found chasing that one report down.

All seven trace back to the Mobikasa baseline, confirmed with git blame — none are new breakage from the recent refactor. Every one only triggers under a narrow data condition (a blank optional field, an ambiguous date, an account with no institution set) that a tidy demo CSV would never hit — which is why they went unnoticed until this session tested the wizard with real, messy data.

ResolvedBugs fixed

Each one told the same way: what the user did, what went wrong, what should have happened, and how it's fixed now.

1

Owner institutional contact wrongly blocked uploads

Fixed
data_upload/views.py
User didUploaded a Deployment Metadata CSV and left the "owner institutional contact" column blank — an optional field.
Went wrongThe app treated it as required, marked the row invalid, and silently refused to save it — with no clear message explaining why.
Should happenA blank value should be accepted, and the app should quietly fill in the user's own institution name if left blank.
FixThe backend was using the "must not be blank" validation rule instead of the "blank is fine" rule for this one field — a copy-paste slip from the field above it. Switched it to the correct rule.
2

Auto-fill crashed for users with no institution on file

Fixed
data_upload/serializer.py
User didLeft that same field blank, on an account with no institution set — true of the admin test account, plausibly true of real users too.
Went wrongThe app crashed outright with a raw server error while trying to auto-fill the field, because there was no institution to read from.
Should happenIf there's no institution on file, leave the field blank. Don't crash.
FixAdded a check before the app tries to read the institution — if there isn't one, it skips the auto-fill instead of crashing.
3

Device & Input file date choices were silently thrown away

Fixed
src/Screens/DataUpload/DeploymentMeta.js
User didUploaded a Device Metadata or Input Data file with an ambiguous date (like 01/02/2023). The app asked: Day/Month/Year or Month/Day/Year? User picked one and clicked Submit.
Went wrongNothing looked wrong — no error, the wizard moved on normally. But the app never actually recorded the answer. That file's data silently never got saved to the database at all, with zero indication anything was wrong.
Should happenPicking a format should save it and use it to read every date in that file correctly — this already worked for the first file type, Deployment Metadata.
FixThe code that remembers the user's choice was only wired up for Deployment Metadata. Added the missing piece for Device Metadata and Input Data, so all three file types now keep the answer.
4

Choosing a timezone triggered the reported error

Fixed
data_upload/serializer.py
User didPicked a date format, submitted it, then in the next popup picked a timezone (e.g. UTC) and submitted that too.
Went wrongThe timezone submission got rejected with "Please check the date format" — even though the user had done nothing wrong and the data was valid. This was the exact error reported.
Should happenSubmitting the timezone choice should just move the wizard to the next step.
FixEarlier in the process, the app was accidentally saving an old, outdated progress snapshot on top of a newer one, confusing its own bookkeeping about where the user actually was. Fixed the save so it only touches the one piece of data it's meant to, instead of overwriting the whole progress record.
5

Confirming units crashed the app

Fixed
data_upload/views.py — UpdateDocFields
User didAfter the timezone popup, a third popup asked to confirm units of measurement (weight/size). User clicked Submit.
Went wrongThe app crashed with a server error instead of accepting the confirmation — a knock-on effect of Bug 1, which had already blocked the record the app expected to update from being created.
Should happenConfirming units should succeed, even the first time through.
FixMade this step handle "the record doesn't exist yet" safely instead of crashing — on top of fixing Bug 1, so the record normally exists by this point anyway.
6

The final review page crashed on a blank field

Fixed
data_upload/views.py — DataSummaryApiView
User didReached the last review page before submitting, where the app shows a plain-language recap — species, individual counts, male/female breakdown, and so on.
Went wrongIf any row left "organism sex" blank — a normal, allowed thing to do — the whole review page crashed instead of showing the recap.
Should happenA blank sex value should just count as "unknown," the same as an entry explicitly marked "unknown" already does.
FixThe counting code called a text function directly on the value without checking for blank first. Added that check, so blank now counts the same as "unknown" instead of crashing.
7

Popups piled up and blocked the Next button

Fixed
src/Screens/DataUpload/DeploymentMeta.js — third-party popup library
User didWent through the date-format popup, then the timezone popup, then the units popup, one after another — the normal sequence when a file has ambiguous dates.
Went wrongEach new popup opened on top of the previous one instead of replacing it. After two or three, several invisible-but-clickable popups were stacked on the page — clicking Next hit a leftover invisible layer instead. From the user's side, the wizard looked frozen.
Should happenOnly one popup should be interactive on screen at a time; closing one should fully remove it before the next appears.
FixThe app was correctly telling each popup "you're closed" internally — the popup library just wasn't removing it from the page. Changed how popups are shown so each one is fully removed when closed, instead of just told to hide.

Confirmed workingVerification after fixing

Full wizard walked end to end in a real authenticated browser session, twice, with no errors:

Upload→ Column matching→ Row validation→ Date format→ Timezone→ Units→ Device Metadata→ Input Data→ Cross-file check→ Map→ Summary→ Licence→ Submit
Full wizard passes clean
Upload confirmed in My Uploads
55 backend tests pass
59 frontend tests pass
Production build succeeds

Not fixed yetStill open — blocking severity

Found in a follow-up UI/UX pass across the same wizard. These will stop real users, not just automated testing.

A

Sticky top navigation overlaps the confirm checkbox

Open
User doesReaches the map-confirmation or data-summary screen and tries to click the required "I confirm…" checkbox.
Goes wrongThe checkbox sits directly under the sticky top navbar. A normal click on it lands on the navbar instead — reproduced directly, the browser rejected the click as landing on the wrong element.
Should happenThe checkbox should be fully clickable without scroll or layout tricks.
StatusNot yet fixed.
B

Success toasts cover the Next button

Open
User doesMoves through the wizard at a normal pace, triggering toasts like "Columns matched successfully" and "Units selected successfully."
Goes wrongToasts stack in the bottom-right and don't clear fast enough. A click aimed at Next can land on a toast instead — reproduced repeatedly during normal-speed navigation.
Should happenToasts should clear quickly, or never overlap the primary action button.
StatusNot yet fixed.
C

No confirmation a date-format choice actually saved

Open
User doesPicks a date format in the disambiguation popup and submits it (Bug 3 above is now fixed — the value does save).
Goes wrongNothing on screen shows what the choice actually resolved to — e.g. that 01/02/2023 will be read as 1 February 2023 — before moving on.
Should happenThe one screen designed specifically to resolve date ambiguity should show the resolved result, so the user can catch a wrong guess immediately.
StatusNot yet fixed.

Not fixed yetStill open — real problems, not blocking

D

Generic fallback error text hides the real error

Open
User doesHits any server error anywhere in the wizard that doesn't come back with a proper message.
Goes wrongThe app shows a hardcoded generic string — "Please check the date format" or "Please check the unit format" — regardless of what actually went wrong. This is a systemic pattern, not a one-off: only the specific causes found this session were fixed; the fallback-text pattern itself is still there.
Should happenError messages should reflect the real problem, or at minimum say "something went wrong, contact support" rather than naming a specific (and possibly wrong) cause.
StatusNot yet fixed — will keep misleading users about future bugs in this area.
E

No visible progress within a step

Open
User doesWorks through Match → Validate → date popup → timezone popup → unit popup for one file type.
Goes wrongThe wizard shows top-level progress across the three file types, but none of that inner sequence — so the user has no way to know how many more popups remain.
Should happenSome visible indicator of sub-step progress within each file type.
StatusNot yet fixed.
F

Raw backend validation text shown to users

Open
User doesUploads a row with an invalid value, e.g. a tracking-device type the app doesn't recognize.
Goes wrongSees raw internal validator text: Field 'trackingDevice' expected string (e.g Argos, GLS, GLC, GPS, Fastloc-GPS, acoustic, Cam tag, Camera, Accelerometer) but got 'yes' — internal field names, not designed copy.
Should happenA user-facing message naming the field in plain language and the accepted values.
StatusNot yet fixed.
G

Deployment ID uniqueness checked very late

Open
User doesUploads, matches, and validates all three files, using a deployment ID that already exists in the database.
Goes wrongThe collision is only caught at the cross-file consistency check — after all three files have been uploaded and validated through several modals each.
Should happenChecked as early as possible, ideally right after the first file uploads, before the user invests time in the rest of the flow.
StatusNot yet fixed.
H

Reupload flow drops into an unlabeled state

Open
User doesClicks "Reupload this File" after a validation error on one of the three files.
Goes wrongThe matching table clears to "No record found in the list" and shows a bare, unlabeled file picker with no visible way to cancel back out.
Should happenClear instructions and a visible cancel path back to the previous state.
StatusNot yet fixed.
I

Reload/resume mid-wizard is broken

Open
User doesRefreshes the browser partway through the wizard — accidentally, or to recover from a stuck screen.
Goes wrongThe app always resets to the very first step, regardless of actual progress. Found by code inspection: the function meant to save "which step am I on" to the browser is never actually called anywhere.
Should happenA refresh should return the user to the step they were actually on.
StatusNot yet fixed. Workaround: avoid refreshing mid-wizard — use only the in-app Back/Next/reupload buttons.

Not fixed yetMinor / cosmetic

For balanceWhat's working well