# **WORKFORCEOS** **FRONTEND GUIDE FOR AI CODING AGENTS - PART 11 - LeaveManagement Service** This document is a part of a REST API guide for the workforceos project. It is designed for AI agents that will generate frontend code to consume the project’s backend. This document provides extensive instruction for the usage of leaveManagement ## Service Access LeaveManagement service management is handled through service specific base urls. LeaveManagement service may be deployed to the preview server, staging server, or production server. Therefore,it has 3 access URLs. The frontend application must support all deployment environments during development, and the user should be able to select the target API server on the login page (already handled in first part.). For the leaveManagement service, the base URLs are: * **Preview:** `https://workforceos.prw.mindbricks.com/leavemanagement-api` * **Staging:** `https://workforceos-stage.mindbricks.co/leavemanagement-api` * **Production:** `https://workforceos.mindbricks.co/leavemanagement-api` ### Tenant URL Prefix and Header Forwarding Tenant context is resolved by frontend routing strategy: - preview/test: URL prefix `/{tenantCodename}` (example: `/babil/products`) - production: tenant subdomain (example: `babil.appname...`) Then backend API calls must always claim target tenant with header: ```js headers["mbx-company-codename"] = tenantCodenameFromUrl; ``` URL prefix/subdomain is frontend-only tenant selection. Use header forwarding for all tenant-scoped calls to `leaveManagement` service. ## Scope **LeaveManagement Service Description** Handles employee leave/absence requests, review/approval workflows, and automatic integration with shift assignments, ensuring company data isolation and leave history access for employees and managers/admins. LeaveManagement service provides apis and business logic for following data objects in workforceos application. Each data object may be either a central domain of the application data structure or a related helper data object for a central concept. Note that data object concept is equal to table concept in the database, in the service database each data object is represented as a db table scheme and the object instances as table rows. **`leaveRequest` Data Object**: Tracks employee leave/absence requests including period, type, status, reason, and approval state. Linked to a user and (optionally) department, with audit fields for request and approval. Company-tenant scoped. ## LeaveManagement Service Frontend Description By The Backend Architect # UX Hints - leaveManagement Service - Employees can submit leave requests with start/end dates, reason, and type; can view their own leave history and status. - Managers/admins see pending leave requests for review, and can approve/reject/cancel with audit trace (approver, decision, date, reason). - Approval of leave may unassign user from overlapping shifts automatically (notified on shift update). - Leave requests cannot be edited by employee after review begins (status != pending). - Employees get notifications upon decision; managers/admins see team/company-wide leave history. ## API Structure ### Object Structure of a Successful Response When the service processes requests successfully, it wraps the requested resource(s) within a JSON envelope. This envelope includes the data and essential metadata such as configuration details and pagination information, providing context to the client. **HTTP Status Codes:** * **200 OK**: Returned for successful GET, LIST, UPDATE, or DELETE operations, indicating that the request was processed successfully. * **201 Created**: Returned for CREATE operations, indicating that the resource was created successfully. **Success Response Format:** For successful operations, the response includes a `"status": "OK"` property, signaling that the request executed successfully. The structure of a successful response is outlined below: ```json { "status":"OK", "statusCode": 200, "elapsedMs":126, "ssoTime":120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName":"products", "method":"GET", "action":"list", "appVersion":"Version", "rowCount":3, "products":[{},{},{}], "paging": { "pageNumber":1, "pageRowCount":25, "totalRowCount":3, "pageCount":1 }, "filters": [], "uiPermissions": [] } ``` * **`products`**: In this example, this key contains the actual response content, which may be a single object or an array of objects depending on the operation. ### Additional Data Each API may include additional data besides the main data object, depending on the business logic of the API. These will be provided in each API’s response signature. ### Error Response If a request encounters an issue—whether due to a logical fault or a technical problem—the service responds with a standardized JSON error structure. The HTTP status code indicates the nature of the error, using commonly recognized codes for clarity: * **400 Bad Request**: The request was improperly formatted or contained invalid parameters. * **401 Unauthorized**: The request lacked a valid authentication token; login is required. * **403 Forbidden**: The current token does not grant access to the requested resource. * **404 Not Found**: The requested resource was not found on the server. * **500 Internal Server Error**: The server encountered an unexpected condition. Each error response is structured to provide meaningful insight into the problem, assisting in efficient diagnosis and resolution. ```js { "result": "ERR", "status": 400, "message": "errMsg_organizationIdisNotAValidID", "errCode": 400, "date": "2024-03-19T12:13:54.124Z", "detail": "String" } ``` ## LeaveRequest Data Object Tracks employee leave/absence requests including period, type, status, reason, and approval state. Linked to a user and (optionally) department, with audit fields for request and approval. Company-tenant scoped. ### LeaveRequest Data Object Frontend Description By The Backend Architect - Employees submit leave requests for specific periods and types (vacation/sick/etc.). - Request status/pending until reviewed by an authorized manager/admin. - Approval auto-triggers removal from conflicting shifts and triggers notifications. - History and current status visible to both employee and department/company managers/admins. ### LeaveRequest Data Object Properties LeaveRequest data object has got following properties that are represented as table fields in the database scheme. These properties don't stand just for data storage, but each may have different settings to manage the business logic. | Property | Type | IsArray | Required | Secret | Description | |----------|------|---------|----------|--------|-------------| | `userId` | ID | false | Yes | No | ID of employee/user requesting leave (auth:user.id) | | `departmentId` | ID | false | No | No | Department (userGroup) id, for scoping leave if relevant | | `requestDate` | Date | false | Yes | No | Datetime when leave requested | | `leaveType` | String | false | Yes | No | Type of leave (e.g. vacation, sick, emergency). | | `startDate` | Date | false | Yes | No | First day of leave (inclusive). | | `endDate` | Date | false | Yes | No | Last day of leave (inclusive). | | `reason` | String | false | No | No | Employee-provided reason/message for leave request | | `status` | Enum | false | Yes | No | Leave request status (pending, approved, rejected, cancelled). | | `approverId` | ID | false | No | No | UserId of manager/admin who approved/rejected/cancelled the request | | `approvedDate` | Date | false | No | No | Date/time leave was approved/rejected/cancelled, if applicable. | | `companyId` | ID | false | Yes | No | An ID value to represent the tenant id of the company | * Required properties are mandatory for creating objects and must be provided in the request body if no default value, formula or session bind is set. ### Enum Properties Enum properties are defined with a set of allowed values, ensuring that only valid options can be assigned to them. The enum options value will be stored as strings in the database, but when a data object is created an additional property with the same name plus an idx suffix will be created, which will hold the index of the selected enum option. You can use the {fieldName_idx} property to sort by the enum value or when your enum options represent a hiyerarchy of values. In the frontend input components, enum type properties should only accept values from an option component that lists the enum options. - **status**: [pending, approved, rejected, cancelled] ### Relation Properties `userId` `departmentId` `approverId` Mindbricks supports relations between data objects, allowing you to define how objects are linked together. The relations may reference to a data object either in this service or in another service. Id the reference is remote, backend handles the relations through service communication or elastic search. These relations should be respected in the frontend so that instaead of showing the related objects id, the frontend should list human readable values from other data objects. If the relation points to another service, frontend should use the referenced service api in case it needs related data. The relation logic is montly handled in backend so the api responses feeds the frontend about the relational data. In mmost cases the api response will provide the relational data as well as the main one. In frontend, please ensure that, 1- instaead of these relational ids you show the main human readable field of the related target data (like name), 2- if this data object needs a user input of these relational ids, you should provide a combobox with the list of possible records or (a searchbox) to select with the realted target data object main human readable field. - **userId**: ID Relation to `user`.id The target object is a sibling object, meaning that the relation is a many-to-one or one-to-one relationship from this object to the target. Required: Yes - **departmentId**: ID Relation to `userGroup`.id The target object is a sibling object, meaning that the relation is a many-to-one or one-to-one relationship from this object to the target. Required: No - **approverId**: ID Relation to `user`.id The target object is a sibling object, meaning that the relation is a many-to-one or one-to-one relationship from this object to the target. Required: No ### Filter Properties `userId` `departmentId` `leaveType` `startDate` `endDate` `status` `companyId` Filter properties are used to define parameters that can be used in query filters, allowing for dynamic data retrieval based on user input or predefined criteria. These properties are automatically mapped as API parameters in the listing API's. - **userId**: ID has a filter named `userId` - **departmentId**: ID has a filter named `departmentId` - **leaveType**: String has a filter named `leaveType` - **startDate**: Date has a filter named `startDate` - **endDate**: Date has a filter named `endDate` - **status**: Enum has a filter named `status` - **companyId**: ID has a filter named `companyId` ## Default CRUD APIs For each data object, the backend architect may designate **default APIs** for standard operations (create, update, delete, get, list). These are the APIs that frontend CRUD forms and AI agents should use for basic record management. If no default is explicitly set (`isDefaultApi`), the frontend generator auto-discovers the most general API for each operation. ### LeaveRequest Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | `createLeaveRequest` | `/v1/leaverequests` | Yes | | Update | `updateLeaveRequest` | `/v1/leaverequests/:leaveRequestId` | Yes | | Delete | `deleteLeaveRequest` | `/v1/leaverequests/:leaveRequestId` | Yes | | Get | `getLeaveRequest` | `/v1/leaverequests/:leaveRequestId` | Yes | | List | `listLeaveRequests` | `/v1/leaverequests` | Yes | When building CRUD forms for a data object, use the default create/update APIs listed above. The form fields should correspond to the API's body parameters. For relation fields, render a dropdown loaded from the related object's list API using the display label property. ## API Reference ### `Create Leaverequest` API **[Default create API]** — This is the designated default `create` API for the `leaveRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Create a new leave/absence request as an employee user. Sets status to pending. Only allowed if user is creating for themselves. Start and end date are both inclusive. **API Frontend Description By The Backend Architect** - UX: Employee fills leave request form (type, date range, reason). Submission creates pending request. Cannot be submitted for past dates, or overlapping with another approved request. User receives feedback/confirmation; entry appears in leave history. **Rest Route** The `createLeaveRequest` API REST controller can be triggered via the following route: `/v1/leaverequests` **Rest Request Parameters** The `createLeaveRequest` api has got 7 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | departmentId | ID | false | request.body?.["departmentId"] | | leaveType | String | true | request.body?.["leaveType"] | | startDate | Date | true | request.body?.["startDate"] | | endDate | Date | true | request.body?.["endDate"] | | reason | String | false | request.body?.["reason"] | | approverId | ID | false | request.body?.["approverId"] | | approvedDate | Date | false | request.body?.["approvedDate"] | **departmentId** : Department (userGroup) id, for scoping leave if relevant **leaveType** : Type of leave (e.g. vacation, sick, emergency). **startDate** : First day of leave (inclusive). **endDate** : Last day of leave (inclusive). **reason** : Employee-provided reason/message for leave request **approverId** : UserId of manager/admin who approved/rejected/cancelled the request **approvedDate** : Date/time leave was approved/rejected/cancelled, if applicable. **REST Request** To access the api you can use the **REST** controller with the path **POST /v1/leaverequests** ```js axios({ method: 'POST', url: '/v1/leaverequests', data: { departmentId:"ID", leaveType:"String", startDate:"Date", endDate:"Date", reason:"String", approverId:"ID", approvedDate:"Date", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "201", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "leaveRequest", "method": "POST", "action": "create", "appVersion": "Version", "rowCount": 1, "leaveRequest": { "id": "ID", "userId": "ID", "departmentId": "ID", "requestDate": "Date", "leaveType": "String", "startDate": "Date", "endDate": "Date", "reason": "String", "status": "Enum", "status_idx": "Integer", "approverId": "ID", "approvedDate": "Date", "companyId": "ID", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Update Leaverequest` API **[Default update API]** — This is the designated default `update` API for the `leaveRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Update an existing leave request. Employee can only edit their own request if status is pending. Manager/admin may change status (approve/reject/cancel), set approver/approval date. On approval, will trigger automatic removal from overlapping shifts via scheduleManagement service. **API Frontend Description By The Backend Architect** - UX: Employees can only edit/cancel pending requests. Managers/Admins see status change controls for review (approve/reject/cancel), must provide response (automatically audits approver, time). On approval, user is removed from overlapping shifts and notified. **Rest Route** The `updateLeaveRequest` API REST controller can be triggered via the following route: `/v1/leaverequests/:leaveRequestId` **Rest Request Parameters** The `updateLeaveRequest` api has got 8 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | leaveRequestId | ID | true | request.params?.["leaveRequestId"] | | departmentId | ID | false | request.body?.["departmentId"] | | leaveType | String | false | request.body?.["leaveType"] | | startDate | Date | false | request.body?.["startDate"] | | endDate | Date | false | request.body?.["endDate"] | | reason | String | false | request.body?.["reason"] | | approverId | ID | false | request.body?.["approverId"] | | approvedDate | Date | false | request.body?.["approvedDate"] | **leaveRequestId** : This id paremeter is used to select the required data object that will be updated **departmentId** : Department (userGroup) id, for scoping leave if relevant **leaveType** : Type of leave (e.g. vacation, sick, emergency). **startDate** : First day of leave (inclusive). **endDate** : Last day of leave (inclusive). **reason** : Employee-provided reason/message for leave request **approverId** : UserId of manager/admin who approved/rejected/cancelled the request **approvedDate** : Date/time leave was approved/rejected/cancelled, if applicable. **REST Request** To access the api you can use the **REST** controller with the path **PATCH /v1/leaverequests/:leaveRequestId** ```js axios({ method: 'PATCH', url: `/v1/leaverequests/${leaveRequestId}`, data: { departmentId:"ID", leaveType:"String", startDate:"Date", endDate:"Date", reason:"String", approverId:"ID", approvedDate:"Date", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "leaveRequest", "method": "PATCH", "action": "update", "appVersion": "Version", "rowCount": 1, "leaveRequest": { "id": "ID", "userId": "ID", "departmentId": "ID", "requestDate": "Date", "leaveType": "String", "startDate": "Date", "endDate": "Date", "reason": "String", "status": "Enum", "status_idx": "Integer", "approverId": "ID", "approvedDate": "Date", "companyId": "ID", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Delete Leaverequest` API **[Default delete API]** — This is the designated default `delete` API for the `leaveRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Delete (soft) a leave request. Only the owner (employee) can delete a pending request; manager/admin may delete any cancelable request. Deletion is soft for audit/history. **API Frontend Description By The Backend Architect** - UX: Employees can delete their own pending requests before review. Admin/manager can delete any not yet actioned or as override. Deletion removes from request history listing (soft deletes only). **Rest Route** The `deleteLeaveRequest` API REST controller can be triggered via the following route: `/v1/leaverequests/:leaveRequestId` **Rest Request Parameters** The `deleteLeaveRequest` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | leaveRequestId | ID | true | request.params?.["leaveRequestId"] | **leaveRequestId** : This id paremeter is used to select the required data object that will be deleted **REST Request** To access the api you can use the **REST** controller with the path **DELETE /v1/leaverequests/:leaveRequestId** ```js axios({ method: 'DELETE', url: `/v1/leaverequests/${leaveRequestId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "leaveRequest", "method": "DELETE", "action": "delete", "appVersion": "Version", "rowCount": 1, "leaveRequest": { "id": "ID", "userId": "ID", "departmentId": "ID", "requestDate": "Date", "leaveType": "String", "startDate": "Date", "endDate": "Date", "reason": "String", "status": "Enum", "status_idx": "Integer", "approverId": "ID", "approvedDate": "Date", "companyId": "ID", "isActive": false, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Get Leaverequest` API **[Default get API]** — This is the designated default `get` API for the `leaveRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Retrieve the details of a single leave request record. Enriches with user and department data in response. Owner (employee) can always view own request; admin/manager can view all requests in their company. **API Frontend Description By The Backend Architect** - UX: Employee can view own leave request with details and status. Manager/admin see details and audit info. Related user, department, and approver info shown (join). **Rest Route** The `getLeaveRequest` API REST controller can be triggered via the following route: `/v1/leaverequests/:leaveRequestId` **Rest Request Parameters** The `getLeaveRequest` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | leaveRequestId | ID | true | request.params?.["leaveRequestId"] | **leaveRequestId** : This id paremeter is used to query the required data object. **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/leaverequests/:leaveRequestId** ```js axios({ method: 'GET', url: `/v1/leaverequests/${leaveRequestId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "leaveRequest", "method": "GET", "action": "get", "appVersion": "Version", "rowCount": 1, "leaveRequest": { "id": "ID", "userId": "ID", "departmentId": "ID", "requestDate": "Date", "leaveType": "String", "startDate": "Date", "endDate": "Date", "reason": "String", "status": "Enum", "status_idx": "Integer", "approverId": "ID", "approvedDate": "Date", "companyId": "ID", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "user": { "email": "String", "fullname": "String", "avatar": "String" }, "approver": { "email": "String", "fullname": "String", "avatar": "String" } } } ``` ### `List Leaverequests` API **[Default list API]** — This is the designated default `list` API for the `leaveRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. List leave requests visible to the user. Employees see their own; managers/admins can filter by department, user, status, and date. Response includes enrichment joins for user, department, and approver. **API Frontend Description By The Backend Architect** - UX: Employees see their own requests; managers/admins can search/filter requests for department, user, date, or status; list includes enrichment data for related fields. **Rest Route** The `listLeaveRequests` API REST controller can be triggered via the following route: `/v1/leaverequests` **Rest Request Parameters** **Filter Parameters** The `listLeaveRequests` api supports 6 optional filter parameters for filtering list results: **userId** (`ID`): ID of employee/user requesting leave (auth:user.id) - Single: `?userId=` - Multiple: `?userId=&userId=` - Null: `?userId=null` **departmentId** (`ID`): Department (userGroup) id, for scoping leave if relevant - Single: `?departmentId=` - Multiple: `?departmentId=&departmentId=` - Null: `?departmentId=null` **leaveType** (`String`): Type of leave (e.g. vacation, sick, emergency). - Single (partial match, case-insensitive): `?leaveType=` - Multiple: `?leaveType=&leaveType=` - Null: `?leaveType=null` **startDate** (`Date`): First day of leave (inclusive). - Single date: `?startDate=2024-01-15` - Multiple dates: `?startDate=2024-01-15&startDate=2024-01-20` - Special: `$today`, `$ltoday`, `$week`, `$lweek`, `$month`, `$leq-`, `$lin-` - Null: `?startDate=null` **endDate** (`Date`): Last day of leave (inclusive). - Single date: `?endDate=2024-01-15` - Multiple dates: `?endDate=2024-01-15&endDate=2024-01-20` - Special: `$today`, `$ltoday`, `$week`, `$lweek`, `$month`, `$leq-`, `$lin-` - Null: `?endDate=null` **status** (`Enum`): Leave request status (pending, approved, rejected, cancelled). - Single: `?status=` (case-insensitive) - Multiple: `?status=&status=` - Null: `?status=null` **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/leaverequests** ```js axios({ method: 'GET', url: '/v1/leaverequests', data: { }, params: { // Filter parameters (see Filter Parameters section above) // userId: '' // Filter by userId // departmentId: '' // Filter by departmentId // leaveType: '' // Filter by leaveType // startDate: '' // Filter by startDate // endDate: '' // Filter by endDate // status: '' // Filter by status } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "leaveRequests", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "leaveRequests": [ { "id": "ID", "userId": "ID", "departmentId": "ID", "requestDate": "Date", "leaveType": "String", "startDate": "Date", "endDate": "Date", "reason": "String", "status": "Enum", "status_idx": "Integer", "approverId": "ID", "approvedDate": "Date", "companyId": "ID", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "user": [ { "email": "String", "fullname": "String", "avatar": "String" }, {}, {} ], "department": [ null, null, null ], "approver": [ { "email": "String", "fullname": "String", "avatar": "String" }, {}, {} ] }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `List Myleaverequests` API List the currently logged-in user's own leave requests. Always scoped to the authenticated user's userId. Available to all roles. **API Frontend Description By The Backend Architect** - UX: Shows the logged-in user's own leave requests with status, dates, and approver info. Supports pagination and sorting by most recent first. **Rest Route** The `listMyLeaveRequests` API REST controller can be triggered via the following route: `/v1/myleaverequests` **Rest Request Parameters** **Filter Parameters** The `listMyLeaveRequests` api supports 6 optional filter parameters for filtering list results: **userId** (`ID`): ID of employee/user requesting leave (auth:user.id) - Single: `?userId=` - Multiple: `?userId=&userId=` - Null: `?userId=null` **departmentId** (`ID`): Department (userGroup) id, for scoping leave if relevant - Single: `?departmentId=` - Multiple: `?departmentId=&departmentId=` - Null: `?departmentId=null` **leaveType** (`String`): Type of leave (e.g. vacation, sick, emergency). - Single (partial match, case-insensitive): `?leaveType=` - Multiple: `?leaveType=&leaveType=` - Null: `?leaveType=null` **startDate** (`Date`): First day of leave (inclusive). - Single date: `?startDate=2024-01-15` - Multiple dates: `?startDate=2024-01-15&startDate=2024-01-20` - Special: `$today`, `$ltoday`, `$week`, `$lweek`, `$month`, `$leq-`, `$lin-` - Null: `?startDate=null` **endDate** (`Date`): Last day of leave (inclusive). - Single date: `?endDate=2024-01-15` - Multiple dates: `?endDate=2024-01-15&endDate=2024-01-20` - Special: `$today`, `$ltoday`, `$week`, `$lweek`, `$month`, `$leq-`, `$lin-` - Null: `?endDate=null` **status** (`Enum`): Leave request status (pending, approved, rejected, cancelled). - Single: `?status=` (case-insensitive) - Multiple: `?status=&status=` - Null: `?status=null` **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/myleaverequests** ```js axios({ method: 'GET', url: '/v1/myleaverequests', data: { }, params: { // Filter parameters (see Filter Parameters section above) // userId: '' // Filter by userId // departmentId: '' // Filter by departmentId // leaveType: '' // Filter by leaveType // startDate: '' // Filter by startDate // endDate: '' // Filter by endDate // status: '' // Filter by status } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "leaveRequests", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "leaveRequests": [ { "id": "ID", "userId": "ID", "departmentId": "ID", "requestDate": "Date", "leaveType": "String", "startDate": "Date", "endDate": "Date", "reason": "String", "status": "Enum", "status_idx": "Integer", "approverId": "ID", "approvedDate": "Date", "companyId": "ID", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "user": [ { "email": "String", "fullname": "String", "avatar": "String" }, {}, {} ], "department": [ null, null, null ], "approver": [ { "email": "String", "fullname": "String", "avatar": "String" }, {}, {} ] }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `Get Myleaverequest` API Retrieve the details of a single leave request by ID, scoped to the currently logged-in user. The user can only see their own leave request. Enriches response with user, department, and approver info. **API Frontend Description By The Backend Architect** - UX: Employee views their own leave request detail with full info. Enriched with user, department, and approver joins. Returns 404 if the record doesn't exist or doesn't belong to the logged-in user. **Rest Route** The `getMyLeaveRequest` API REST controller can be triggered via the following route: `/v1/myleaverequest/:leaveRequestId` **Rest Request Parameters** The `getMyLeaveRequest` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | leaveRequestId | ID | true | request.params?.["leaveRequestId"] | **leaveRequestId** : This id paremeter is used to query the required data object. **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/myleaverequest/:leaveRequestId** ```js axios({ method: 'GET', url: `/v1/myleaverequest/${leaveRequestId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "leaveRequest", "method": "GET", "action": "get", "appVersion": "Version", "rowCount": 1, "leaveRequest": { "id": "ID", "userId": "ID", "departmentId": "ID", "requestDate": "Date", "leaveType": "String", "startDate": "Date", "endDate": "Date", "reason": "String", "status": "Enum", "status_idx": "Integer", "approverId": "ID", "approvedDate": "Date", "companyId": "ID", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "user": { "email": "String", "fullname": "String", "avatar": "String" }, "approver": { "email": "String", "fullname": "String", "avatar": "String" } } } ``` **After this prompt, the user may give you new instructions to update the output of this prompt or provide subsequent prompts about the project.**