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:

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:

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:

{
  "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": []
}

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:

Each error response is structured to provide meaningful insight into the problem, assisting in efficient diagnosis and resolution.

{
  "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.

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.

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.

The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object.

Required: Yes

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.

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

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.

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.

The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object.

Required: Yes

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.

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)

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.

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.

The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object.

Required: Yes

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

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

  axios({
    method: 'POST',
    url: '/v1/approvalrequests',
    data: {
            targetType:"Enum",  
            targetId:"ID",  
            requestedAt:"Date",  
            reviewedAt:"Date",  
            reviewedByUserId:"ID",  
            adminNote:"String",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'PATCH',
    url: `/v1/reviewapprovalrequest/${approvalRequestId}`,
    data: {
            status:"Enum",  
            reviewedAt:"Date",  
            reviewedByUserId:"ID",  
            adminNote:"String",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'GET',
    url: `/v1/approvalrequests/${approvalRequestId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"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)

targetId (ID): ID of entity being approved (user or project, depending on type)

status (Enum): Approval status: pending/approved/rejected

REST Request To access the api you can use the REST controller with the path GET /v1/approvalrequests

  axios({
    method: 'GET',
    url: '/v1/approvalrequests',
    data: {
    
    },
    params: {
    
        // Filter parameters (see Filter Parameters section above)
        // targetType: '<value>' // Filter by targetType
        // targetId: '<value>' // Filter by targetId
        // status: '<value>' // Filter by status
            }
  });

REST Response

{
	"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

  axios({
    method: 'POST',
    url: '/v1/reportlogs',
    data: {
            contentType:"Enum",  
            contentId:"ID",  
            reportType:"String",  
            reportedAt:"Date",  
            reviewAction:"String",  
            actionedByUserId:"ID",  
            actionedAt:"Date",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'PATCH',
    url: `/v1/reviewreportlog/${reportLogId}`,
    data: {
            reviewStatus:"Enum",  
            reviewAction:"String",  
            actionedByUserId:"ID",  
            actionedAt:"Date",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'GET',
    url: `/v1/reportlogs/${reportLogId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

contentId (ID): ID of the reported content (project ID, message ID, user ID)

reportType (String): Nature of report (abuse, spam, copyright, etc.)

reviewStatus (Enum): Open/closed/ignored

REST Request To access the api you can use the REST controller with the path GET /v1/reportlogs

  axios({
    method: 'GET',
    url: '/v1/reportlogs',
    data: {
    
    },
    params: {
    
        // Filter parameters (see Filter Parameters section above)
        // contentType: '<value>' // Filter by contentType
        // contentId: '<value>' // Filter by contentId
        // reportType: '<value>' // Filter by reportType
        // reviewStatus: '<value>' // Filter by reviewStatus
            }
  });

REST Response

{
	"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

  axios({
    method: 'POST',
    url: '/v1/suspensionrecords',
    data: {
            userId:"ID",  
            reason:"String",  
            suspendedByUserId:"ID",  
            suspendedAt:"Date",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'PATCH',
    url: `/v1/liftsuspensionrecord/${suspensionRecordId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'GET',
    url: `/v1/suspensionrecords/${suspensionRecordId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'GET',
    url: '/v1/suspensionrecords',
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'POST',
    url: '/v1/auditlogs',
    data: {
            actionType:"String",  
            actorUserId:"ID",  
            targetType:"String",  
            targetId:"ID",  
            details:"Text",  
            actionAt:"Date",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'GET',
    url: `/v1/auditlogs/${auditLogId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"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

  axios({
    method: 'GET',
    url: '/v1/auditlogs',
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"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.