/services/public-calendar also returns the professional's current opening
hours; the client threw them away and drew the day from the snapshot the
search list carried, which can be days old. It now uses the fresh ones.
Between picking an hour and pressing "Pedir cita" another patient can
take the slot. The confirm step asks the agenda again and, if the hour is
gone, says so and clears the selection instead of creating a service the
professional would have to deny. A failed re-check lets the booking
through: a network hiccup should not block a patient.
Also:
- tapping a busy slot with no id explains itself instead of doing nothing
- the profile refuses to save an empty rate with the rate switch on,
which was reaching the backend as rate: ''
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The two calendars each built their own list of hours. The patient's
enforced a 3-hour booking lead time; the professional's did not, so at
15:00 an 08:00-18:00 agenda reported "3 libres" (15, 16, 17) that no
patient could actually take.
Both now go through SlotGenerator. The professional still sees the
near-term hours (blocking the next hour is legitimate) but they are
labelled "Sin reserva" and excluded from the "libres" count, so the
number on his agenda means what the patient sees.
Also in this pass:
- endOf() clamps the slot end at 23:59; a 120-minute slot booked at
23:00 was sending "25:00" to the backend.
- ScheduleEntity.copyWith can set an hour back to null, so returning a
day to jornada continua no longer keeps the split hours around.
- Removed the Firebase-era schedule map ('habilitado', 'range1Hour1')
together with the dead ProfessionalEntity.fromDocument that fed it.
- Settings loads guard on mounted and swallow failures instead of
calling setState after dispose.
- "Pedir cita" says what is missing instead of doing nothing.
Tests: 9 passing, including the clamp and the empty/inverted ranges.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
getSettings rebuilt the response into a hand-written map and left both feature
flags out, so SettingEntity always read null. Everything gated on them stayed
off no matter what the backend said:
- "Mostrar tarifa" in the professional profile could not be switched on
- "Servicio a domicilio" never rendered, and touching the on-site switch forced
location to office, losing both/delivery
- the patient never saw the home-vs-office dialog, so every appointment was
created as office with the professional's address
- every appointment was created with rate 0
The web reads the response as-is and never had this. Note the backend does not
ship a `tarifas` key at all yet, so rates stay off until it is added to
settings.global — this fix only stops the app from discarding it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Saving opening hours from the app never did anything. The payload went to
PATCH /professionals/me as a map keyed by day name ({"monday": {"habilitado":
true, "range1Hour1": "8:0"}}), and that endpoint silently drops a `schedules`
key — it answers 200 with the record unchanged. So the professional edited
their hours, got "Información actualizada correctamente", and the agenda kept
whatever it had.
The real endpoint is PATCH /professionals/me/schedules and it takes an array
of {day_of_week, enabled, continuous_day, range*_hour*} with zero-padded
times, which is what the web has been sending all along.
Verified against the backend: the previous payload returns 200 and changes
nothing; the new one returns 200 and the rows come back updated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/chat/start/:id starts a chat between the caller and :id, so it takes the
counterpart — the web already passes the client when a professional opens it.
Mobile always sent the professional, so a professional opening the chat
started a conversation with themselves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/services/public-calendar/{professionalId} exists after all — the web has been
using it all along. My earlier probes missed it because they guessed the URL
shape, and because it is keyed by the professionals row id rather than the
owning user id, which ProfessionalEntity was discarding.
Adds ProfessionalEntity.recordId and points the client calendar at the public
endpoint. Until now a client browsing a professional's availability was served
their own agenda, so every slot looked free and two people could book the same
hour. A failed load now hides the slots and offers a retry instead of showing
them as available.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verified the real contracts against the backend before changing anything.
Chat (three defects, one root cause):
- every chat endpoint is keyed by the chat id, not the service id. The app
called POST /chat/start, threw away the id it returned and kept using the
service id, so every later request 404'd.
- messages arrive as {data, meta}; reading the body as a bare list threw and
surfaced as an empty conversation.
- the bloc created the chat and then never emitted ChatLoaded (the else hung
off `if (chat == null)`), leaving a permanent spinner. Sending a message
emitted nothing at all, so it vanished until reopening.
Messages now render optimistically and roll back if the send fails, and the
screen distinguishes "loading" from "could not open" with a retry.
Appointments:
- a null range1_hour2 parsed as 00:00, so new appointments were born
"Caducado" and every action was hidden. It now falls back to the start time.
- service requests validate the HTTP status and tolerate an empty body: a 4xx
was treated as success and a 204 as failure.
- creating a service with no id in the response no longer reports success and
navigates to a service that does not exist.
- dispatching LoadService from build() looped forever on failure; the three
detail screens now load once and offer a retry.
Ratings:
- both sides read userScored, so only one of the two could ever rate. The
client side now reads professionalScored.
- the screen closed before the request finished, killing the provider mid
flight while addComment swallowed every error. It now waits for confirmation.
- score/reputation parsing tolerates integers and numeric strings instead of
emptying the review list.
Also: guarded map lookups in ScoreBloc, a nullable name in the search list,
and error states with retry where a failure used to shimmer forever.
Verified against the backend: `accepted` is the status the API expects, so the
suspected spelling bug was a false alarm and was left alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DateTime.toString() renders "2026-07-13 00:00:00.000Z" while the backend
sends "2026-07-13T00:00:00.000Z", so every day comparison was false and no
booked slot was ever detected. Both calendars showed fully free days.
The client calendar now also treats an unloaded agenda as busy instead of
free: rendering a taken slot as available leads straight to a double booking.
Note: the client still reads /services/professional/calendar, which returns
the *caller's* calendar. There is no endpoint for another professional's
agenda, so a client cannot yet see which of that professional's slots are
taken. That needs a backend endpoint.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
_isOccupied matched any service on the slot regardless of status. Unblocking
sets the service to cancelled, so a released slot still rendered as occupied
and the unblock looked like it did nothing. Cancelled and denied services are
now ignored, and self-booked slots get their own "Bloqueado" state with a
release action, mirroring the web.
Self-booking now spans the professional's configured slot duration instead of
a hardcoded two hours, which no longer matched the generated slots.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Root cause behind most "stuck loading" reports: the backend changed shape
(schedules became an array, location_preferences a string) while the mobile
parser still hard-cast to Map/int. The TypeError was swallowed by a silent
catch that returned null, and screens only handled the success state, so a
parse failure rendered as a permanent spinner. Same class of bug appeared
across service lists via non-null map lookups and a total absence of
request timeouts.
Ported from prosappweb:
- in-app suggestions (POST /suggestions)
- policies/terms from GET /settings/policies
- configurable appointment length (slot_duration_minutes)
- block/unblock calendar slots (POST /services/block)
- GPS city detection on the profile (Nominatim)
- server-side professional search with haversine distance
- retry cooldown after a rejected professional application
Reliability:
- parse schedules array (day_of_week 0=Mon) and string location_preferences
- read times as wall clock, so 08:00 stays 08:00 across timezones
- carry minutes into hours in TimeOfDay.add; a minute-based step used to
loop forever and freeze the calendar (covered by test/time_slots_test.dart)
- semver update check instead of string equality, which blocked every build
that did not exactly match the configured version
- request timeouts across all repositories
- surface HTTP >= 400 instead of reporting failed writes as success
- error states with retry instead of an indefinite shimmer
Includes pre-existing uncommitted work from the UI redesign.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Port the same card UI pattern from the redesigned solicitudes screen
to the 4 remaining list screens (pro/user active services + history):
- 4px colored left strip matching service status color
- Circular avatar with status-colored border + letter fallback
- Status badge with icon + colored border (replaces solid filled badges)
- Date/time row with calendar icon
- Theme-aware colors via _Th extension (respects dark/light mode)
- AppBar with brand blue (replaces default grey)
- Empty state with icon + descriptive text
- Shimmer placeholders as rounded cards (replaces ListTile shimmer)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Port the 3 redesigned views from prosappweb to prosappco:
- Solicitudes: modern cards with 4px colored left strip, status badge with
icon+border, avatar with status-colored ring, date/time row, empty state
- Calendario: card-wrapped TableCalendar with custom CalendarStyle (blue
selected/ring today), day header card with date box + occupied/available
stat pills, slot cards with colored strip and time badge instead of
gradient circles
- Perfil profesional: gradient banner header with profession pill + camera
overlay, section cards with icon+title, payment method chips (animated)
instead of checkboxes, schedule rows with colored active/inactive dots,
theme-aware colors throughout (respects dark/light mode)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- professional_denied_screen: full UI with icon, bullet list of next steps,
re-register button and logout option (was just a Text widget)
- professional_pending_screen: replace static GIF screen with step-by-step
progress indicator (submitted → in review → approved), notification tip,
logout button
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- MyUser: add isPhoneVerified field (from is_phone_verified in API)
- ApiUserRepository: signInWithPhoneNumber calls POST /auth/send-otp,
verifyOTP calls POST /auth/phone, linkWithOTP calls POST /auth/verify-phone
Added updateFcmToken and changePassword methods
- AuthBloc: remove Firebase PhoneVerificationService, use repository OTP flow
- app_view.dart: gate authenticated users without verified phone to
PhoneVerifyRequiredScreen before showing HomeScreen
- welcome_screen.dart: full redesign with gradient header, logo, integrated
OTP flow (phone → code in same screen), 60s resend timer
- PhoneVerifyRequiredScreen: new screen for users who need to verify phone
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add firebase_core + firebase_messaging to pubspec.yaml
- Initialize Firebase in main.dart before runApp
- NotificationBloc: request permission, get FCM token, register with
backend (PATCH /users/me/fcm-token), show local notification on
foreground messages, refresh token on rotation
- app_view.dart: call initializePushNotifications() on authenticated state
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
score.createdAt is now String (ISO 8601) not Firebase Timestamp, so .toDate()
was a compile error. Use DateTime.tryParse() with fallback to DateTime.now().
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Deleted firebase_*_repository.dart files were still re-exported, causing
compile errors. Barrel files now only export the API implementations.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Delete all firebase_*_repository.dart files (replaced by api_* equivalents)
- Remove cloud_firestore, firebase_auth, firebase_storage, firebase_core from all package pubspecs
- Remove cloud_firestore from main pubspec.yaml
- Delete firebase_options.dart (no longer referenced)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Replace all Firebase* repositories with Api* repositories using HTTP + SharedPreferences JWT
- Remove Firebase.initializeApp() and firebase_messaging background handler from main.dart
- Update DI (app_di.dart) to inject Api* repositories instead of Firebase* ones
- Replace all Timestamp/cloud_firestore usage with ISO 8601 String dates
- Stub PhoneVerificationService (Firebase phone OTP → backend OTP when implemented)
- Add ApiService singleton with JWT management in lib/services/
- Legacy firebase_*_repository.dart files preserved for Fase 4 cleanup
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
