# **AUTEURLABB** **FRONTEND GUIDE FOR AI CODING AGENTS - PART 9 - ModerationAdmin Service** This document is a part of a REST API guide for the auteurlabb 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 moderationAdmin ## Service Access ModerationAdmin service management is handled through service specific base urls. ModerationAdmin 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 moderationAdmin service, the base URLs are: * **Preview:** `https://auteurlabb.prw.mindbricks.com/moderationadmin-api` * **Staging:** `https://auteurlabb-stage.mindbricks.co/moderationadmin-api` * **Production:** `https://auteurlabb.mindbricks.co/moderationadmin-api` ## Scope **ModerationAdmin Service Description** Handles approval workflows for studios, investors, and projects; facilitates platform content moderation, user suspensions, and records all related admin actions for audit and compliance. ModerationAdmin service provides apis and business logic for following data objects in auteurlabb 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. **`approvalRequest` Data Object**: Tracks approval workflows for studios, investors, and submitted projects. Each request points to a specific entity and is reviewed by admin. **`reportLog` Data Object**: Logs moderation/reporting actions: for project, message, or user. Each report includes status, type, review/action info. **`suspensionRecord` Data Object**: Admin action to suspend or lift suspension on a user. Each record logs a suspension/lift action for audit/compliance. **`auditLog` Data Object**: Generic audit log for all admin/moderation actions across services/objects for compliance and traceability. ## ModerationAdmin Service Frontend Description By The Backend Architect This service is not user-facing and is used strictly for admin and moderation workflows. Typical frontend behaviors involve presenting lists of pending approvals, moderation reports, and audit logs to admins, allowing them to perform workflow actions and review logs. End users can see the status of their own approval requests and reports only. All actions are strictly role-gated. There are no public endpoints. ## 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" } ``` ## ApprovalRequest Data Object Tracks approval workflows for studios, investors, and submitted projects. Each request points to a specific entity and is reviewed by admin. ### ApprovalRequest Data Object Frontend Description By The Backend Architect Admins are shown lists of pending, approved, or rejected requests. Only admins can approve/reject; creators can view their own request status but not others. Status and review notes are shown to creators only after decision. All changes are audit-logged. ### ApprovalRequest Data Object Properties ApprovalRequest 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 | |----------|------|---------|----------|--------|-------------| | `targetType` | Enum | false | Yes | No | Type of entity being approved (studio, investor, project) | | `targetId` | ID | false | Yes | No | ID of entity being approved (user or project, depending on type) | | `requestedAt` | Date | false | Yes | No | Request creation time | | `requestedByUserId` | ID | false | Yes | No | User ID who created the request | | `status` | Enum | false | Yes | No | Approval status: pending/approved/rejected | | `reviewedAt` | Date | false | No | No | Date/time request reviewed | | `reviewedByUserId` | ID | false | No | No | Admin userId who reviewed the request | | `adminNote` | String | false | No | No | Review note left by admin. | * 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. - **targetType**: [studio, investor, project, filmmaker] - **status**: [pending, approved, rejected] ### Relation Properties `requestedByUserId` `reviewedByUserId` 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. - **requestedByUserId**: ID Relation to `user`.id The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: Yes - **reviewedByUserId**: ID Relation to `user`.id The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: No ### Filter Properties `targetType` `targetId` `status` 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. - **targetType**: Enum has a filter named `targetType` - **targetId**: ID has a filter named `targetId` - **status**: Enum has a filter named `status` ## ReportLog Data Object Logs moderation/reporting actions: for project, message, or user. Each report includes status, type, review/action info. ### ReportLog Data Object Frontend Description By The Backend Architect Admins are shown lists of open/closed/ignored reports and take action by marking as reviewed, adding action notes. Reporting users can see their own report status. All logs reference the original content by type and ID. ### ReportLog Data Object Properties ReportLog 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 | |----------|------|---------|----------|--------|-------------| | `contentType` | Enum | false | Yes | No | Type of content being reported: project/message/user | | `contentId` | ID | false | Yes | No | ID of the reported content (project ID, message ID, user ID) | | `reportType` | String | false | Yes | No | Nature of report (abuse, spam, copyright, etc.) | | `reportedByUserId` | ID | false | Yes | No | ID of user reporting | | `reportedAt` | Date | false | Yes | No | Report creation timestamp | | `reviewStatus` | Enum | false | Yes | No | Open/closed/ignored | | `reviewAction` | String | false | No | No | Action taken by admin (removed, warned, etc.) or note | | `actionedByUserId` | ID | false | No | No | Admin making the moderation action | | `actionedAt` | Date | false | No | No | Time of moderation action | * 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. - **contentType**: [project, message, user] - **reviewStatus**: [open, closed, ignored] ### Relation Properties `reportedByUserId` `actionedByUserId` 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. - **reportedByUserId**: ID Relation to `user`.id The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: Yes - **actionedByUserId**: ID Relation to `user`.id The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: No ### Filter Properties `contentType` `contentId` `reportType` `reviewStatus` 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. - **contentType**: Enum has a filter named `contentType` - **contentId**: ID has a filter named `contentId` - **reportType**: String has a filter named `reportType` - **reviewStatus**: Enum has a filter named `reviewStatus` ## SuspensionRecord Data Object Admin action to suspend or lift suspension on a user. Each record logs a suspension/lift action for audit/compliance. ### SuspensionRecord Data Object Frontend Description By The Backend Architect Admins may suspend or reinstate users for violation of policies. Each action is logged; suspension status controls actual access (isActive in core user record). Only admins may create suspension records. All changes update the core auth:user record (isActive). ### SuspensionRecord Data Object Properties SuspensionRecord 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 | Suspended user id | | `reason` | String | false | Yes | No | Reason for suspension action | | `suspendedByUserId` | ID | false | Yes | No | Admin ID who performed the suspension action | | `suspendedAt` | Date | false | Yes | No | Time of action (suspend/lift) | | `status` | Enum | false | Yes | No | Current state: active (suspended), lifted (reinstated) | * 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**: [active, lifted] ### Relation Properties `userId` `suspendedByUserId` 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 parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: Yes - **suspendedByUserId**: ID Relation to `user`.id The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: Yes ## AuditLog Data Object Generic audit log for all admin/moderation actions across services/objects for compliance and traceability. ### AuditLog Data Object Frontend Description By The Backend Architect Admins/reviewers can list or view audit log entries. All log entries are immutable and trace detailed actions for compliance. No updates or deletions allowed. ### AuditLog Data Object Properties AuditLog 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 | |----------|------|---------|----------|--------|-------------| | `actionType` | String | false | Yes | No | Type of admin action (created, updated, suspended, approved, etc.) | | `actorUserId` | ID | false | Yes | No | User ID of admin/staff performing the action | | `targetType` | String | false | Yes | No | Type of object affected by this action (approvalRequest, reportLog, suspensionRecord, etc.) | | `targetId` | ID | false | Yes | No | ID of the object affected by this action | | `details` | Text | false | No | No | Freeform details, note, or JSON blob describing action context | | `actionAt` | Date | false | Yes | No | When the action occurred | * 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. ## 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. ### ApprovalRequest Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | `createApprovalRequest` | `/v1/approvalrequests` | Yes | | Update | `reviewApprovalRequest` | `/v1/reviewapprovalrequest/:approvalRequestId` | Yes | | Delete | _none_ | - | Auto | | Get | `getApprovalRequest` | `/v1/approvalrequests/:approvalRequestId` | Yes | | List | `listApprovalRequests` | `/v1/approvalrequests` | Yes | ### ReportLog Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | `createReportLog` | `/v1/reportlogs` | Yes | | Update | `reviewReportLog` | `/v1/reviewreportlog/:reportLogId` | Yes | | Delete | _none_ | - | Auto | | Get | `getReportLog` | `/v1/reportlogs/:reportLogId` | Yes | | List | `listReportLogs` | `/v1/reportlogs` | Yes | ### SuspensionRecord Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | `createSuspensionRecord` | `/v1/suspensionrecords` | Yes | | Update | `liftSuspensionRecord` | `/v1/liftsuspensionrecord/:suspensionRecordId` | Yes | | Delete | _none_ | - | Auto | | Get | `getSuspensionRecord` | `/v1/suspensionrecords/:suspensionRecordId` | Yes | | List | `listSuspensionRecords` | `/v1/suspensionrecords` | Yes | ### AuditLog Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | `createAuditLog` | `/v1/auditlogs` | Yes | | Update | _none_ | - | Auto | | Delete | _none_ | - | Auto | | Get | `getAuditLog` | `/v1/auditlogs/:auditLogId` | Yes | | List | `listAuditLogs` | `/v1/auditlogs` | 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 Approvalrequest` API **[Default create API]** — This is the designated default `create` API for the `approvalRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Create a new approval request for studio, investor, or project. Status defaults to pending. Only non-admins can create requests for themselvessss. **Rest Route** The `createApprovalRequest` API REST controller can be triggered via the following route: `/v1/approvalrequests` **Rest Request Parameters** The `createApprovalRequest` api has got 6 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | targetType | Enum | true | request.body?.["targetType"] | | targetId | ID | true | request.body?.["targetId"] | | requestedAt | Date | true | request.body?.["requestedAt"] | | reviewedAt | Date | false | request.body?.["reviewedAt"] | | reviewedByUserId | ID | false | request.body?.["reviewedByUserId"] | | adminNote | String | false | request.body?.["adminNote"] | **targetType** : Type of entity being approved (studio, investor, project) **targetId** : ID of entity being approved (user or project, depending on type) **requestedAt** : Request creation time **reviewedAt** : Date/time request reviewed **reviewedByUserId** : Admin userId who reviewed the request **adminNote** : Review note left by admin. **REST Request** To access the api you can use the **REST** controller with the path **POST /v1/approvalrequests** ```js axios({ method: 'POST', url: '/v1/approvalrequests', data: { targetType:"Enum", targetId:"ID", requestedAt:"Date", reviewedAt:"Date", reviewedByUserId:"ID", adminNote:"String", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "201", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "approvalRequest", "method": "POST", "action": "create", "appVersion": "Version", "rowCount": 1, "approvalRequest": { "id": "ID", "targetType": "Enum", "targetType_idx": "Integer", "targetId": "ID", "requestedAt": "Date", "requestedByUserId": "ID", "status": "Enum", "status_idx": "Integer", "reviewedAt": "Date", "reviewedByUserId": "ID", "adminNote": "String", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Review Approvalrequest` API **[Default update API]** — This is the designated default `update` API for the `approvalRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Approve or reject an approval request. Only superAdmin or admin may update status or add review notes. **Rest Route** The `reviewApprovalRequest` API REST controller can be triggered via the following route: `/v1/reviewapprovalrequest/:approvalRequestId` **Rest Request Parameters** The `reviewApprovalRequest` api has got 5 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | approvalRequestId | ID | true | request.params?.["approvalRequestId"] | | status | Enum | true | request.body?.["status"] | | reviewedAt | Date | false | request.body?.["reviewedAt"] | | reviewedByUserId | ID | false | request.body?.["reviewedByUserId"] | | adminNote | String | false | request.body?.["adminNote"] | **approvalRequestId** : This id paremeter is used to select the required data object that will be updated **status** : Approval status: pending/approved/rejected **reviewedAt** : Date/time request reviewed **reviewedByUserId** : Admin userId who reviewed the request **adminNote** : Review note left by admin. **REST Request** To access the api you can use the **REST** controller with the path **PATCH /v1/reviewapprovalrequest/:approvalRequestId** ```js axios({ method: 'PATCH', url: `/v1/reviewapprovalrequest/${approvalRequestId}`, data: { status:"Enum", reviewedAt:"Date", reviewedByUserId:"ID", adminNote:"String", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "approvalRequest", "method": "PATCH", "action": "update", "appVersion": "Version", "rowCount": 1, "approvalRequest": { "id": "ID", "targetType": "Enum", "targetType_idx": "Integer", "targetId": "ID", "requestedAt": "Date", "requestedByUserId": "ID", "status": "Enum", "status_idx": "Integer", "reviewedAt": "Date", "reviewedByUserId": "ID", "adminNote": "String", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Get Approvalrequest` API **[Default get API]** — This is the designated default `get` API for the `approvalRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Get a single approvalRequest. Only owner or admin may view. **Rest Route** The `getApprovalRequest` API REST controller can be triggered via the following route: `/v1/approvalrequests/:approvalRequestId` **Rest Request Parameters** The `getApprovalRequest` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | approvalRequestId | ID | true | request.params?.["approvalRequestId"] | **approvalRequestId** : 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/approvalrequests/:approvalRequestId** ```js axios({ method: 'GET', url: `/v1/approvalrequests/${approvalRequestId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "approvalRequest", "method": "GET", "action": "get", "appVersion": "Version", "rowCount": 1, "approvalRequest": { "id": "ID", "targetType": "Enum", "targetType_idx": "Integer", "targetId": "ID", "requestedAt": "Date", "requestedByUserId": "ID", "status": "Enum", "status_idx": "Integer", "reviewedAt": "Date", "reviewedByUserId": "ID", "adminNote": "String", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "requester": { "email": "String", "fullname": "String", "roleId": "String" }, "reviewer": { "email": "String", "fullname": "String" } } } ``` ### `List Approvalrequests` API **[Default list API]** — This is the designated default `list` API for the `approvalRequest` data object. Frontend generators and AI agents should use this API for standard CRUD operations. List approval requests. Admins see all, non-admins see only their own. **Rest Route** The `listApprovalRequests` API REST controller can be triggered via the following route: `/v1/approvalrequests` **Rest Request Parameters** **Filter Parameters** The `listApprovalRequests` api supports 3 optional filter parameters for filtering list results: **targetType** (`Enum`): Type of entity being approved (studio, investor, project) - Single: `?targetType=` (case-insensitive) - Multiple: `?targetType=&targetType=` - Null: `?targetType=null` **targetId** (`ID`): ID of entity being approved (user or project, depending on type) - Single: `?targetId=` - Multiple: `?targetId=&targetId=` - Null: `?targetId=null` **status** (`Enum`): Approval status: pending/approved/rejected - 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/approvalrequests** ```js axios({ method: 'GET', url: '/v1/approvalrequests', data: { }, params: { // Filter parameters (see Filter Parameters section above) // targetType: '' // Filter by targetType // targetId: '' // Filter by targetId // 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": "approvalRequests", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "approvalRequests": [ { "id": "ID", "targetType": "Enum", "targetType_idx": "Integer", "targetId": "ID", "requestedAt": "Date", "requestedByUserId": "ID", "status": "Enum", "status_idx": "Integer", "reviewedAt": "Date", "reviewedByUserId": "ID", "adminNote": "String", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "requester": [ { "email": "String", "fullname": "String", "roleId": "String" }, {}, {} ], "reviewer": [ { "email": "String", "fullname": "String" }, {}, {} ] }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `Create Reportlog` API **[Default create API]** — This is the designated default `create` API for the `reportLog` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Create a content/user/project moderation report **Rest Route** The `createReportLog` API REST controller can be triggered via the following route: `/v1/reportlogs` **Rest Request Parameters** The `createReportLog` api has got 7 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | contentType | Enum | true | request.body?.["contentType"] | | contentId | ID | true | request.body?.["contentId"] | | reportType | String | true | request.body?.["reportType"] | | reportedAt | Date | true | request.body?.["reportedAt"] | | reviewAction | String | false | request.body?.["reviewAction"] | | actionedByUserId | ID | false | request.body?.["actionedByUserId"] | | actionedAt | Date | false | request.body?.["actionedAt"] | **contentType** : Type of content being reported: project/message/user **contentId** : ID of the reported content (project ID, message ID, user ID) **reportType** : Nature of report (abuse, spam, copyright, etc.) **reportedAt** : Report creation timestamp **reviewAction** : Action taken by admin (removed, warned, etc.) or note **actionedByUserId** : Admin making the moderation action **actionedAt** : Time of moderation action **REST Request** To access the api you can use the **REST** controller with the path **POST /v1/reportlogs** ```js axios({ method: 'POST', url: '/v1/reportlogs', data: { contentType:"Enum", contentId:"ID", reportType:"String", reportedAt:"Date", reviewAction:"String", actionedByUserId:"ID", actionedAt:"Date", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "201", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "reportLog", "method": "POST", "action": "create", "appVersion": "Version", "rowCount": 1, "reportLog": { "id": "ID", "contentType": "Enum", "contentType_idx": "Integer", "contentId": "ID", "reportType": "String", "reportedByUserId": "ID", "reportedAt": "Date", "reviewStatus": "Enum", "reviewStatus_idx": "Integer", "reviewAction": "String", "actionedByUserId": "ID", "actionedAt": "Date", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Review Reportlog` API **[Default update API]** — This is the designated default `update` API for the `reportLog` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Admin-only: Close/ignore a report, add review action/note. Only superAdmin/admin allowed. **Rest Route** The `reviewReportLog` API REST controller can be triggered via the following route: `/v1/reviewreportlog/:reportLogId` **Rest Request Parameters** The `reviewReportLog` api has got 5 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | reportLogId | ID | true | request.params?.["reportLogId"] | | reviewStatus | Enum | true | request.body?.["reviewStatus"] | | reviewAction | String | false | request.body?.["reviewAction"] | | actionedByUserId | ID | false | request.body?.["actionedByUserId"] | | actionedAt | Date | false | request.body?.["actionedAt"] | **reportLogId** : This id paremeter is used to select the required data object that will be updated **reviewStatus** : Open/closed/ignored **reviewAction** : Action taken by admin (removed, warned, etc.) or note **actionedByUserId** : Admin making the moderation action **actionedAt** : Time of moderation action **REST Request** To access the api you can use the **REST** controller with the path **PATCH /v1/reviewreportlog/:reportLogId** ```js axios({ method: 'PATCH', url: `/v1/reviewreportlog/${reportLogId}`, data: { reviewStatus:"Enum", reviewAction:"String", actionedByUserId:"ID", actionedAt:"Date", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "reportLog", "method": "PATCH", "action": "update", "appVersion": "Version", "rowCount": 1, "reportLog": { "id": "ID", "contentType": "Enum", "contentType_idx": "Integer", "contentId": "ID", "reportType": "String", "reportedByUserId": "ID", "reportedAt": "Date", "reviewStatus": "Enum", "reviewStatus_idx": "Integer", "reviewAction": "String", "actionedByUserId": "ID", "actionedAt": "Date", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Get Reportlog` API **[Default get API]** — This is the designated default `get` API for the `reportLog` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Get a single report log. Only admins or reporting user may view. **Rest Route** The `getReportLog` API REST controller can be triggered via the following route: `/v1/reportlogs/:reportLogId` **Rest Request Parameters** The `getReportLog` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | reportLogId | ID | true | request.params?.["reportLogId"] | **reportLogId** : 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/reportlogs/:reportLogId** ```js axios({ method: 'GET', url: `/v1/reportlogs/${reportLogId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "reportLog", "method": "GET", "action": "get", "appVersion": "Version", "rowCount": 1, "reportLog": { "id": "ID", "contentType": "Enum", "contentType_idx": "Integer", "contentId": "ID", "reportType": "String", "reportedByUserId": "ID", "reportedAt": "Date", "reviewStatus": "Enum", "reviewStatus_idx": "Integer", "reviewAction": "String", "actionedByUserId": "ID", "actionedAt": "Date", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "reportedBy": { "email": "String", "fullname": "String", "roleId": "String" }, "actionedBy": { "email": "String", "fullname": "String" } } } ``` ### `List Reportlogs` API **[Default list API]** — This is the designated default `list` API for the `reportLog` data object. Frontend generators and AI agents should use this API for standard CRUD operations. List moderation reports. Admins see all; other users see only their reports. **Rest Route** The `listReportLogs` API REST controller can be triggered via the following route: `/v1/reportlogs` **Rest Request Parameters** **Filter Parameters** The `listReportLogs` api supports 4 optional filter parameters for filtering list results: **contentType** (`Enum`): Type of content being reported: project/message/user - Single: `?contentType=` (case-insensitive) - Multiple: `?contentType=&contentType=` - Null: `?contentType=null` **contentId** (`ID`): ID of the reported content (project ID, message ID, user ID) - Single: `?contentId=` - Multiple: `?contentId=&contentId=` - Null: `?contentId=null` **reportType** (`String`): Nature of report (abuse, spam, copyright, etc.) - Single (partial match, case-insensitive): `?reportType=` - Multiple: `?reportType=&reportType=` - Null: `?reportType=null` **reviewStatus** (`Enum`): Open/closed/ignored - Single: `?reviewStatus=` (case-insensitive) - Multiple: `?reviewStatus=&reviewStatus=` - Null: `?reviewStatus=null` **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/reportlogs** ```js axios({ method: 'GET', url: '/v1/reportlogs', data: { }, params: { // Filter parameters (see Filter Parameters section above) // contentType: '' // Filter by contentType // contentId: '' // Filter by contentId // reportType: '' // Filter by reportType // reviewStatus: '' // Filter by reviewStatus } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "reportLogs", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "reportLogs": [ { "id": "ID", "contentType": "Enum", "contentType_idx": "Integer", "contentId": "ID", "reportType": "String", "reportedByUserId": "ID", "reportedAt": "Date", "reviewStatus": "Enum", "reviewStatus_idx": "Integer", "reviewAction": "String", "actionedByUserId": "ID", "actionedAt": "Date", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "reportedBy": [ { "email": "String", "fullname": "String", "roleId": "String" }, {}, {} ], "actionedBy": [ { "email": "String", "fullname": "String" }, {}, {} ] }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `Create Suspensionrecord` API **[Default create API]** — This is the designated default `create` API for the `suspensionRecord` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Admin: suspend a user from the platform. Action triggers update to auth:user isActive = false. **Rest Route** The `createSuspensionRecord` API REST controller can be triggered via the following route: `/v1/suspensionrecords` **Rest Request Parameters** The `createSuspensionRecord` api has got 4 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | userId | ID | true | request.body?.["userId"] | | reason | String | true | request.body?.["reason"] | | suspendedByUserId | ID | true | request.body?.["suspendedByUserId"] | | suspendedAt | Date | true | request.body?.["suspendedAt"] | **userId** : Suspended user id **reason** : Reason for suspension action **suspendedByUserId** : Admin ID who performed the suspension action **suspendedAt** : Time of action (suspend/lift) **REST Request** To access the api you can use the **REST** controller with the path **POST /v1/suspensionrecords** ```js axios({ method: 'POST', url: '/v1/suspensionrecords', data: { userId:"ID", reason:"String", suspendedByUserId:"ID", suspendedAt:"Date", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "201", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "suspensionRecord", "method": "POST", "action": "create", "appVersion": "Version", "rowCount": 1, "suspensionRecord": { "id": "ID", "userId": "ID", "reason": "String", "suspendedByUserId": "ID", "suspendedAt": "Date", "status": "Enum", "status_idx": "Integer", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Lift Suspensionrecord` API **[Default update API]** — This is the designated default `update` API for the `suspensionRecord` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Admin: lift user suspension, set status to lifted & update user isActive=true in auth service. **Rest Route** The `liftSuspensionRecord` API REST controller can be triggered via the following route: `/v1/liftsuspensionrecord/:suspensionRecordId` **Rest Request Parameters** The `liftSuspensionRecord` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | suspensionRecordId | ID | true | request.params?.["suspensionRecordId"] | **suspensionRecordId** : This id paremeter is used to select the required data object that will be updated **REST Request** To access the api you can use the **REST** controller with the path **PATCH /v1/liftsuspensionrecord/:suspensionRecordId** ```js axios({ method: 'PATCH', url: `/v1/liftsuspensionrecord/${suspensionRecordId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "suspensionRecord", "method": "PATCH", "action": "update", "appVersion": "Version", "rowCount": 1, "suspensionRecord": { "id": "ID", "userId": "ID", "reason": "String", "suspendedByUserId": "ID", "suspendedAt": "Date", "status": "Enum", "status_idx": "Integer", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Get Suspensionrecord` API **[Default get API]** — This is the designated default `get` API for the `suspensionRecord` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Get a suspension record. Only admin/superAdmin or suspended user. **Rest Route** The `getSuspensionRecord` API REST controller can be triggered via the following route: `/v1/suspensionrecords/:suspensionRecordId` **Rest Request Parameters** The `getSuspensionRecord` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | suspensionRecordId | ID | true | request.params?.["suspensionRecordId"] | **suspensionRecordId** : 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/suspensionrecords/:suspensionRecordId** ```js axios({ method: 'GET', url: `/v1/suspensionrecords/${suspensionRecordId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "suspensionRecord", "method": "GET", "action": "get", "appVersion": "Version", "rowCount": 1, "suspensionRecord": { "id": "ID", "userId": "ID", "reason": "String", "suspendedByUserId": "ID", "suspendedAt": "Date", "status": "Enum", "status_idx": "Integer", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "user": { "email": "String", "fullname": "String", "roleId": "String" }, "suspendedByUser": { "email": "String", "fullname": "String" } } } ``` ### `List Suspensionrecords` API **[Default list API]** — This is the designated default `list` API for the `suspensionRecord` data object. Frontend generators and AI agents should use this API for standard CRUD operations. List suspension records. Admins see all; users see only their own. **Rest Route** The `listSuspensionRecords` API REST controller can be triggered via the following route: `/v1/suspensionrecords` **Rest Request Parameters** The `listSuspensionRecords` api has got no request parameters. **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/suspensionrecords** ```js axios({ method: 'GET', url: '/v1/suspensionrecords', data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "suspensionRecords", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "suspensionRecords": [ { "id": "ID", "userId": "ID", "reason": "String", "suspendedByUserId": "ID", "suspendedAt": "Date", "status": "Enum", "status_idx": "Integer", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "user": [ { "email": "String", "fullname": "String", "roleId": "String" }, {}, {} ], "suspendedByUser": [ { "email": "String", "fullname": "String" }, {}, {} ] }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `Create Auditlog` API **[Default create API]** — This is the designated default `create` API for the `auditLog` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Create audit log entry. Only used by system or admin workflows. **Rest Route** The `createAuditLog` API REST controller can be triggered via the following route: `/v1/auditlogs` **Rest Request Parameters** The `createAuditLog` api has got 6 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | actionType | String | true | request.body?.["actionType"] | | actorUserId | ID | true | request.body?.["actorUserId"] | | targetType | String | true | request.body?.["targetType"] | | targetId | ID | true | request.body?.["targetId"] | | details | Text | false | request.body?.["details"] | | actionAt | Date | true | request.body?.["actionAt"] | **actionType** : Type of admin action (created, updated, suspended, approved, etc.) **actorUserId** : User ID of admin/staff performing the action **targetType** : Type of object affected by this action (approvalRequest, reportLog, suspensionRecord, etc.) **targetId** : ID of the object affected by this action **details** : Freeform details, note, or JSON blob describing action context **actionAt** : When the action occurred **REST Request** To access the api you can use the **REST** controller with the path **POST /v1/auditlogs** ```js axios({ method: 'POST', url: '/v1/auditlogs', data: { actionType:"String", actorUserId:"ID", targetType:"String", targetId:"ID", details:"Text", actionAt:"Date", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "201", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "auditLog", "method": "POST", "action": "create", "appVersion": "Version", "rowCount": 1, "auditLog": { "id": "ID", "actionType": "String", "actorUserId": "ID", "targetType": "String", "targetId": "ID", "details": "Text", "actionAt": "Date", "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "isActive": true } } ``` ### `Get Auditlog` API **[Default get API]** — This is the designated default `get` API for the `auditLog` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Get a single audit log record. Only superAdmin/admin. **Rest Route** The `getAuditLog` API REST controller can be triggered via the following route: `/v1/auditlogs/:auditLogId` **Rest Request Parameters** The `getAuditLog` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | auditLogId | ID | true | request.params?.["auditLogId"] | **auditLogId** : 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/auditlogs/:auditLogId** ```js axios({ method: 'GET', url: `/v1/auditlogs/${auditLogId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "auditLog", "method": "GET", "action": "get", "appVersion": "Version", "rowCount": 1, "auditLog": { "id": "ID", "actionType": "String", "actorUserId": "ID", "targetType": "String", "targetId": "ID", "details": "Text", "actionAt": "Date", "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "isActive": true } } ``` ### `List Auditlogs` API **[Default list API]** — This is the designated default `list` API for the `auditLog` data object. Frontend generators and AI agents should use this API for standard CRUD operations. List audit log records. Only superAdmin/admin. **Rest Route** The `listAuditLogs` API REST controller can be triggered via the following route: `/v1/auditlogs` **Rest Request Parameters** The `listAuditLogs` api has got no request parameters. **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/auditlogs** ```js axios({ method: 'GET', url: '/v1/auditlogs', data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "auditLogs", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "auditLogs": [ { "id": "ID", "actionType": "String", "actorUserId": "ID", "targetType": "String", "targetId": "ID", "details": "Text", "actionAt": "Date", "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "isActive": true }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` **After this prompt, the user may give you new instructions to update the output of this prompt or provide subsequent prompts about the project.**