Repository navigation
Conversation
Backend no longer persists leaving_post_adhyayan, so drop the client-side question, form state, and payload field from both self and mumukshu travel booking flows.
…lows Task 6 removed this self-reported question from the standalone TravelBooking.tsx + preparingRequestBody.js, but it still lingered in TravelAddon.tsx, MumukshuTravelAddon.tsx, and the travel form initializers in booking/[booking].tsx and mumukshuBooking/[booking].tsx. Also drops the now-unused TRAVEL_ADHYAYAN_ASK_LIST dropdown.
Adds a One-way/Round trip toggle to travel booking. When round trip is selected, an editable return-leg section collects a return date (min = onward date) and return pickup/drop defaulting to the reverse of the onward route, plus a return flight/train time when required. On submit, the onward mumukshuGroup is mirrored into returnMumukshuGroup with swapped/edited endpoints, and preparingRequestBody emits return_date + returnMumukshuGroup (run through the same per-group transform as the onward leg) only when both are present, so one-way submissions are unchanged.
Adds a Guest chip to TravelBooking.tsx that books travel for a host's
guests via /guest -> guestGroup transform -> updateGuestBooking('travel')
-> guestBooking/[booking].tsx (dynamic route, booking='travel') ->
bookingReview.tsx -> /guest/validate + /guest/booking. Round trip works
for guest travel too by generalizing attachReturnLeg to branch on
guestGroup vs mumukshuGroup. Adds the guest travel case to
prepareGuestRequestBody and a travel branch to transformGuestGroup, plus
a GuestTravelBookingDetails card wired into the addons and review screens.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…-on flows Round trip is now a date RANGE (CustomCalender period): single date = one-way, range = round trip with the return leg auto-reversing the onward route on the end date. Replaces the earlier trip-type toggle + dual calendars. Applied to the main TravelBooking (self/mumukshu/guest) and both travel add-ons; the reversed return leg is built in transformAddons when a return_date is present. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…how round trip on primary travel cards
…verse-route sentence
… round-trip dates
…i-day stays); drop under-calendar helper text
…r (matches travel date UI)
… travel is primary; revert food Meal Dates label
…Clear control to add-on return date
… guest add-on date inheritance; align Room/Food endDay order; respect cleared one-way on re-sync
…DateField shared components; delete dead prepareSelfRequestBody
|
Claude finished @vendz's task in 9m 16s —— View job Review complete
Posted 1 inline comment + a summary comment. Highlights: Inline — In summary (outside this diff, so no inline anchor) — the Adhyayan add-on's date-range query wasn't updated to inherit round-trip travel's
Everything else — guest travel flow, |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| <CustomCalender | ||
| selectedDay={travelForm.date} | ||
| setSelectedDay={(day: any) => { | ||
| type={'period'} | ||
| startDay={travelForm.date} | ||
| setStartDay={(day: any) => { | ||
| setTravelForm((prev) => ({ ...prev, date: day })); | ||
| setMumukshuForm((prev) => ({ ...prev, date: day })); | ||
| setGuestTravelForm((prev) => ({ ...prev, date: day })); | ||
| setReturnDate(''); | ||
| }} | ||
| endDay={returnDate} | ||
| setEndDay={(day: any) => setReturnDate(day || '')} |
There was a problem hiding this comment.
CustomCalender's period mode (handlePeriodPress in CustomCalender.tsx) doesn't guard against the second tap landing before startDay: if day.dateString < startDay, its date-range loop never runs (so no visual highlight is shown) but it still calls setEndDay(day.dateString) with the earlier date. Here that flows straight into setReturnDate(day), so a user can end up with a returnDate before travelForm.date with zero visual feedback that anything happened.
isReturnLegValid() does catch this at validation time, but the only visible effect is that "Book Now" silently becomes disabled (isDisabled={... : !isMumukshuFormValid()}) — there's no message telling the user their return date is invalid or before the travel date. Worth either clamping/ignoring an out-of-order setEndDay here, or surfacing an explicit error state (e.g. a validation message) rather than a silently-disabled button.
Review summarySolid implementation overall — round-trip modeling as a start/end date range (mirroring the room-booking calendar), the shared Two things worth a look (one inline, one below since it's outside the diff):
Everything else (guest booking flow, |
…er return tap; adhyayan add-on inherits round-trip return date
|
Claude finished @vendz's task in 1m 53s —— View job Review complete — fix commit verified
Both previously-flagged issues are fixed correctly in
No new issues found in this diff ( |
|
Claude finished @vendz's task in 2m 11s —— View job Review complete — re-review of latest push (
|
|
Claude finished @vendz's task in 1m 39s —— View job Review complete — re-review of latest push (
|
|
Claude finished @vendz's task in 1m 11s —— View job Review complete — re-review of latest push (
|
- Unify requiresArrivalTime on the shared src/utils/travel.ts helper for both field visibility and validation everywhere, fixing an Utsav soft-lock where an EVENT_LOCATION_LIST airport/railway value required a time the UI never showed. - Resolve the return leg's guest cardnos from the post-/guest updatedGuests so a new guest's round trip no longer ships returnGuestGroup with cardno undefined. - Reset the return (re-mirror onward) on chip switch and on adding/removing a traveler, so stale travelerIndices can no longer book the wrong/missing person. - Block submission (with a clear reason) when a split return has an empty group or leaves any traveler unassigned. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extract reverseOnwardGroups into src/utils/travel.ts and use it in the mumukshu and guest travel add-ons; remove the unused colors import in TravelReturnDetails. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Claude finished @vendz's task in 3m 11s —— View job Review complete — re-review of latest push (
|
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Claude finished @vendz's task in 49s —— View job Review complete — re-review of latest push (
|
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Claude finished @vendz's task in 36s —— View job Review complete — re-review of latest push (
|
Swap the Guest and Mumukshu chip positions. Chip logic now keys off string literals instead of CHIPS array indices, so display order is decoupled from behavior. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Claude finished @vendz's task in 50s —— View job Review complete — re-review of latest push (
|
A one-way travel addon booked alongside a multi-day room/food/adhyayan stay silently became a round trip: the travel form's return_date was cross-referenced from the companion booking's end date. If the onward leg required an arrival time, the auto-generated return leg had none and submission hard-blocked with a generic 'fill all travel fields' error. Round trip is now strictly an explicit user opt-in; return_date is only seeded from existing travel data, never from a companion booking. Fixes both the mumukshu and guest booking screens (initial form + sync effect). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The travel-addon path set return_date whenever present and only attached the return group if it happened to exist, and treated an empty array as a valid group. A return_date without a resolved group triggers the backend's 'return_date and returnMumukshuGroup must be provided together' 400. Now both are sent together or not at all, matching the primary path, with an empty group array counting as absent. Guest and mumukshu paths both. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…n's SDK 57 app.config)
- Today's rule kept: the "Leaving post Adhyayan?" question is back for Self and Mumukshus, and leaving_post_adhyayan is sent as main sends it. Removing it is an owner decision (see the PR description). - Vendor is not in the guest types until the owner decides. - Return groups and the edited flag are kept per chip (Self / Mumukshus / Guest); the return date stays one shared range. - The itinerary shows a dash for an empty pickup or drop. - Guest Adhyayan add-on on a travel-only guest booking uses the travel dates when there is no room or flat, only asks when it has a valid start date, and shows a plain message instead of "Invalid time value". - Prettier on the PR's travel files. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Claude finished @vendz's task in 1m 9s —— View job Re-review of latest push (
|
| const base = { | ||
| pickup: rg.pickup, | ||
| drop: rg.drop, | ||
| type: rg.type, | ||
| luggage: rg.luggage || [], | ||
| arrival_time: rg.arrival_time || '', | ||
| special_request: rg.comments || '', | ||
| total_people: rg.total_people, | ||
| }; |
There was a problem hiding this comment.
Now that ec76d2f restores "Leaving post adhyayan?", the return leg never gets it. The question only shows when pickup is Research Centre (LOCATION_LIST[0]). On a normal round trip (city → RC onward, RC → city return), the return group is the leg that departs RC. But TravelReturnDetails/TravelReturnGroups don't render the question and this payload has no adhyayan. So transformMumukshuGroup leaves out leaving_post_adhyayan on every return group. The onward group still sends it (defaults to 'No' → 0), even though the onward leg doesn't leave RC.
Net effect: for the case the flag exists for (leaving RC after an adhyayan), round-trip bookings never send the user's answer. Same gap in the add-on payload builders (booking/[booking].tsx ~L102, mumukshuBooking/[booking].tsx ~L567).
Fix options: (a) ask the question on return groups whose pickup is RC (in TravelReturnGroups/the flat return form) and pass adhyayan through here, or (b) if the owner decides to drop the question, drop it everywhere. Either way, the onward and return legs should behave the same.
vendz
changed the title
… returns - On a round trip, the return group asks "Leaving post Adhyayan?" when it departs the Research Centre, and return groups send leaving_post_adhyayan. The member's answer goes on the leg leaving the centre; other legs send No. - The booking, guest and Mumukshu screens refuse an edited return that is incomplete or leaves a traveller out of every group. - The guest and Mumukshu payload builders reuse reverseOnwardGroups. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Review round handled in 855b13c: the return leg asks "Leaving post Adhyayan?" when it departs the Research Centre and sends the answer (other legs send No); the forms refuse an incomplete edited return; the payload builders reuse reverseOnwardGroups. Checked with the app's real request builder against SRATRC/aashray-backend#346 locally: a return leaving the centre saved 1, with the same trip_group_id as its onward leg. Title updated; the description's "Update 3 Oct" section supersedes the earlier "question removed" wording. |
|
Claude finished @vendz's task in 44s —— View job Re-review of latest push (
|
| onCancel={() => setTimeVisible(false)} | ||
| /> | ||
| </> | ||
| ) : null} |
There was a problem hiding this comment.
855b13c added "Leaving post adhyayan?" to the grouped editor (TravelReturnGroups), but the flat editor here never got it. The flat editor is what Self uses, both on the main travel form (TravelBooking.tsx) and in the add-on (TravelAddon.tsx).
So on a normal Self round trip (city → Research Centre (RC), then RC → city), the return group keeps its default adhyayan: 'No'. leavingPostAdhyayanFor(rg) then sends leaving_post_adhyayan = 0 on the leg that actually leaves RC, and the user has no way to change it. Self is the most common case, so the fix only works for Mumukshu and Guest.
The onward leg doesn't cover for it either. The onward question only shows when the onward pickup is RC, and on a city → RC trip it isn't.
Suggest mirroring the grouped editor:
| ) : null} | |
| ) : null} | |
| {firstGroup?.pickup === 'Research Centre' && ( | |
| <CustomSelectBottomSheet | |
| className="mt-5" | |
| label="Leaving post adhyayan?" | |
| options={dropdowns.TRAVEL_ADHYAYAN_ASK_LIST} | |
| selectedValue={firstGroup?.adhyayan || dropdowns.TRAVEL_ADHYAYAN_ASK_LIST[1].value} | |
| onValueChange={(val: any) => updateFlat({ adhyayan: val })} | |
| saveKeyInsteadOfValue={false} | |
| /> | |
| )} |
The read-only summary, shown before the user taps "Edit", has the same gap. An untouched round trip always sends No on the return. You could show the question outside the Edit panel whenever the return pickup is RC.
There was a problem hiding this comment.
Applied in ba318a0: the Self return card asks the question whenever the return leaves the Research Centre, outside the Edit panel. Any leg not leaving the centre sends 0, which also covers the stale onward Yes. Checked with the app's request builder against #346 locally: a Self round trip with the return leaving the centre saved 1, the onward leg saved 0, and a stale onward Yes saved 0.
- The Self return card shows "Leaving post adhyayan?" whenever the return leaves the Research Centre, outside the Edit panel, so a default return can be answered without editing it. - Any onward or return group that doesn't leave the Research Centre sends leaving_post_adhyayan = 0, so a Yes left over from an earlier pickup choice is sent as No. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Claude finished @vendz's task in 46s —— View job Re-review of latest push (
|
| options={dropdowns.TRAVEL_ADHYAYAN_ASK_LIST} | ||
| selectedValue={firstGroup.adhyayan || dropdowns.TRAVEL_ADHYAYAN_ASK_LIST[1].value} | ||
| onValueChange={(val: any) => updateFlat({ adhyayan: val })} | ||
| saveKeyInsteadOfValue={false} |
There was a problem hiding this comment.
Answering this question goes through updateFlat → onChangeReturnGroups. Both callers treat that as a user edit:
TravelBooking.tsx:1188:setReturnGroups(g); setReturnEdited(true)TravelAddon.tsx:309:returnEdited: true
After that, the return leg stops mirroring the onward leg. Example on the Self form:
- Onward: Mumbai Airport → Research Centre (RC), 2 bags. Pick a return date. The default return is RC → Mumbai Airport.
- Answer "Leaving post adhyayan?" = Yes.
returnEditedis now true. - Change the onward pickup to Pune, or change the luggage or vehicle type.
- The return still says RC → Mumbai Airport with the old luggage and type, and it gets submitted that way. The read-only card shows it, but nothing tells the user that the return no longer follows the onward leg.
Before this commit, a Self user who never tapped Edit always got a return that matched the onward leg. Now, just answering the question switches that off.
Suggested fix: keep the answer out of the "edited" flag. For example, add an onChangeReturnAdhyayan prop that patches only adhyayan on the groups, without calling setReturnEdited(true) or setting returnEdited: true. Then make the auto-sync effect in TravelBooking.tsx (and effectiveReturnGroups in TravelAddon.tsx) keep the existing adhyayan when it rebuilds the groups from the onward leg.
There was a problem hiding this comment.
Applied in 77e883f: the answer has its own callback and state and no longer marks the return as edited; the auto-sync carries it. Checked: answering Yes, then changing the onward leg to Dadar→RC, Large Bag, Full Car x3, rebuilds the return as RC→Dadar with the same values and saves 1 on the return and 0 on the onward.
The answer is stored on its own (per chip, and as returnAdhyayan in the add-on), not through the return-group change, so it no longer marks the return as edited. The default return keeps mirroring the onward leg (pickup, luggage, vehicle, people) and carries the answer when rebuilt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Claude finished @vendz's task in 30s —— View job Re-review of latest push (
|
|
Claude finished @vendz's task in 23s —— View job Re-review of latest push (
|
Travel: round-trip, guest booking & adhyayan question removal
Member app for the travel feature set (pairs with the aashray-backend PR).
What's included
GuestForm), routed through the dynamic guest-booking screen.swap-horizontalbetween the two dates).Review & simplify
Passed a high-recall code review + fixes (return-leg arrival-time clearing, guest add-on date inheritance, add-on end-date order, cleared-one-way persistence) and a simplify pass (shared
TravelReturnDateField+TravelDateDisplaycomponents, deadprepareSelfRequestBodyremoved).expo exportclean.Testing
No unit-test framework in this repo; verified via
expo exportcompile + manual smoke on iOS simulator (one-way, round-trip, guest, add-on inheritance).🤖 Generated with Claude Code
Update 3 Oct 2026: brought up to date and fixed (not merged)
mainmerged in (SDK 57; main'sapp.config.jskept).tsc shows the same errors as
main.TRAVEL_ADHYAYAN_ASK_LIST.Update 28 Oct 2026: merged with current main (SDK 58), verified, ready for review
mainmerged in (no conflicts). The app builds on SDK 58 (Android and iOS bundles export). Type and lint results match main exactly (no new errors).updatesrow, as for 1.1.62.iPhone (28 Oct, later): the same flow also passes end to end on an iPhone simulator (iOS 27, SDK 58 dev build): sign-in, round trip booked (return shown reversed), the repeat refused with "Travel already booked...", a guest found by phone and booked, then after staff confirmed in the panel the Bookings tab shows both legs confirmed and the guest trip awaiting. Re-run:
travel-logs/full/run-ios.sh(kept outside the repo).