List requests

What people asked for, and what became of it — leave, schedule changes, corrections and money.

Read this to learn that a timesheet moved. Half of everything here is a batch clock-in correction: somebody forgot to punch, a manager approved the fix, and the attendance for those days changed after the fact. Only 48 per cent of those are approved within three days of the day they correct, and a third reach back more than a week — so a caller that pulled a timesheet last week cannot assume it still holds. Attendance carries no timestamps of its own, which makes this listing paged on updated_since the only signal that anything has moved.

period is the field that makes that usable: the span of days a request concerns, wherever its kind happens to keep them. A clock-in correction keeps them inside the punches, a leave request as a period or a list, a request for a certificate not at all — both ends are null there rather than invented.

subtype is the second half of type, and the product keeps it in two different places — content.type for most kinds, content.leave_type for leave. It is answered as one field, and subtypes filters on both.

comment is what the author wrote when filing it, ordinarily the reason. Comments the workflow writes itself — on acknowledgement, or when a spawned task closes — are not answered here.

Oldest first. A first call lands on the earliest request this company ever filed, which for a long-standing one is years back. That order is what lets a full export finish in one walk, and it is not what you want for "what changed lately": ask with updated_since.

content is behind include=content: its shape depends on the kind, and one schema describes one shape everywhere else on this surface.

Reading only. Creating a request enters a workflow — approval routes resolve, approvers are notified, tasks are spawned — and approving one is a person's decision that a dismissal application or a sick note gives weight to.