Consolidate the Attendance API type

[AbhishekGhimires225777323]

Consolidate the Attendance API type

[LoopyB]

Thanks Abhishek - the consolidation direction looks good, but I need the current Backend contract confirmed before merge.
Please update the PR description with:

• the ticket and problem addressed;
• affected screens/endpoints;
• evidence that shiftId, guardId, checkInTime and checkOutTime match all current Attendance responses;
• Guard App screenshots for check-in, check-out, My Shifts and Timesheets;
• TypeScript/lint output and any known limitations.

Please also confirm whether shiftId can ever be populated as an object. Then formally request review.

[Krisha190235]

Nice cleanup — consolidating to a single Attendance shape and killing the anys is the right direction. I confirmed nothing else in the app uses the removed fields (clockIn/Out, hoursWorked, status, scheduledStart/End), and I also checked them against main's backend: the ShiftAttendance model is exactly guardId, shiftId, checkInTime, checkOutTime, locationVerified — none of the removed fields exist there or in any response, so this is correcting the type to match the real contract, not dropping anything. 👍

Two things I checked so we're covered:

• shiftId / guardId as objects — this PR removes all the object-handling and matches with String(record.shiftId) === String(shift._id), so it relies on these being plain string ids. I confirmed that's safe: there's no .populate() anywhere in shiftattendance.controller.js or attendance.service.js, the service returns raw docs, and the Swagger for GET /attendance/:userId documents shiftId/guardId as type: string. So they're always unpopulated string ids and the matching holds. (If we ever add .populate() later, we'd want a small const toId = (v) => (v && typeof v === 'object' ? v._id : String(v)) normalizer — worth a code comment noting the assumption.)

• Timesheet label — fmtShiftLabel now returns Shift ID: . Just to flag: since shiftId was never populated, the old Title • Date • Time branch was actually dead code, so this isn't a regression — the label already showed the raw id. But it's a poor label either way; can we do a follow-up (separate ticket is fine) to show a human-readable Title • Date • Time by deriving it from the shift?

Could you also update the PR description with the ticket link, the field-mapping evidence that these match all current Attendance responses, Guard App screenshots (check-in, check-out, My Shifts, Timesheets), and the tsc/lint output? With those I'm happy to approve.

[AbhishekGhimires225777323]

Ticket link : https://teams.microsoft.com/l/entity/com.microsoft.teamspace.tab.planner/planner.v1.ed40f198-c027-4924-91bb-49876c26834a_p_0fSba1sGJUO-HZQzZmq1bsgAFkcJ?tenantId=d02378ec-1688-46d5-8540-1c28b5f470f6&webUrl=https%3A%2F%2Ftasks.teams.microsoft.com%2Fteamsui%2FpersonalApp%2Falltasklists&context=%7B%22subEntityId%22%3A%22%2Fv1%2Fplan%2F0fSba1sGJUO-HZQzZmq1bsgAFkcJ%2Fview%2Fboard%2Ftask%2F-rLAA_CMgk6xEqPRW360-sgANOMz%22%2C%22channelId%22%3A%2219%3Ab7682747b0184969aa3fc27c00be8a6a%40thread.tacv2%22%7D

Field Mapping evidence :

Backend Response :

AppScreenshots :

My Shift :

Check In

Checkout :

Timesheet :

Tsc lint :

[Krisha190235]

Thanks for the follow-up commit — the navigation fix is a good catch. Passing the full shift object (and Alerting when it's missing) is the right call, since ShiftDetailsScreen reads route.params.shift, not a shiftId.

I checked getMyShifts on the backend: with no status param the guard query is { $or: [{ applicants }, { acceptedBy }] } across all statuses, so myShifts() already includes completed/past shifts — and since an attendance record implies the guard was the assigned guard, shiftsById[item.shiftId] will resolve for any real timesheet row. So the "unavailable" Alert is just a safe fallback, not a common path — looks good. (And good that you didn't pass status=past, which would've filtered out current shifts.)

Just confirm Alert is imported from react-native (lint would flag it otherwise) and I'm happy.