Skip to content

Update admin-openapi-1.2.59.yaml to support campaign custom fields: #87

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Shujaulislam wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update admin-openapi-1.2.59.yaml to support campaign custom fields: #87

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions admin-openapi-1.2.59.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1435,6 +1435,11 @@ paths:
description: Traffic channels name
items:
type: string
customFields:
type: array
description: List of available custom field definitions for campaigns
items:
type: string
Comment on lines +1438 to +1442
Copy link

@coderabbitai coderabbitai bot Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Clarify which identifier filters.customFields accepts.

Line 1440 doesn’t specify whether items are id, _id, or name, which can lead to mismatched filters in client integrations.

✍️ Suggested doc tweak 
               customFields:
                 type: array
-                description: List of available custom field definitions for campaigns
+                description: List of campaign custom field identifiers to filter by (specify which identifier—e.g., `id` or `_id`—is expected).
                 items:
                   type: string
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
customFields:
type: array
description: List of available custom field definitions for campaigns
items:
type: string
customFields:
type: array
description: List of campaign custom field identifiers to filter by (specify which identifier—e.g., `id` or `_id`—is expected).
items:
type: string
🤖 Prompt for AI Agents 
In `@admin-openapi-1.2.59.yaml` around lines 1438 - 1442, The OpenAPI schema for
the response property customFields (under filters.customFields) is ambiguous
about which identifier clients must supply; update the schema description for
customFields (and/or the items) to explicitly state whether the array items are
campaign custom field "id", "_id", or "name" and the expected type/format (e.g.,
UUID or string). Locate the customFields definition (property name:
customFields, items: type: string) and change its description to say something
like "List of available custom field identifiers (use the field's id/UUID)" or
"List of custom field names" as appropriate for your implementation, and if
necessary adjust items.type/format to match the identifier format.

in: query
name: filters
post:
Expand Down Expand Up @@ -11114,6 +11119,67 @@ paths:
x-examples:
Example 1:
message: This is a Note
'/v2/customfields/campaign':
get:
summary: Get Campaign Custom Fields
operationId: campaign-customfields-findAll
tags:
- Campaigns
description: >
Returns the list of custom fields that can be used to filter campaigns.
Each custom field includes its key, label, type and any allowed values.
security:
- API Key Param: []
responses:
'200':
description: OK
content:
application/json:
schema:
type: object
properties:
fields:
type: array
items:
type: object
properties:
_id:
type: string
label:
type: string
type:
type: string
description: Field input type (e.g. text, select)
name:
type: string
required:
type: boolean
id:
type: string
hidden:
type: boolean
validation:
nullable: true
isConsent:
Comment on lines +11160 to +11163
Copy link

@coderabbitai coderabbitai bot Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Define an explicit schema for validation.

Line 11162 sets nullable: true without a type, which often degrades client generation to any and obscures the contract.

🛠️ Suggested schema shape 
                         validation:
-                          nullable: true
+                          type: object
+                          nullable: true
+                          additionalProperties: true
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
type: boolean
validation:
nullable: true
isConsent:
type: boolean
validation:
type: object
nullable: true
additionalProperties: true
isConsent:
🤖 Prompt for AI Agents 
In `@admin-openapi-1.2.59.yaml` around lines 11160 - 11163, The OpenAPI property
"validation" currently only sets "nullable: true" which leaves its type
undefined and causes clients to generate ambiguous types; update the schema for
the "validation" property (adjacent to "isConsent") to include an explicit
"type" (e.g., "object" or the correct primitive) and a concrete sub-schema
(properties, required, or enum) that describes expected fields and allows null
via "nullable: true" so code generators produce a precise contract.

type: boolean
options:
type: array
items:
type: string
pub_hide:
type: integer
description: Visibility flag for publishers
'400':
description: Bad Request
content:
application/json:
schema:
type: object
properties:
errors:
type: array
items:
$ref: ./models/error.v1.yaml
'/v2/publishers/{pubId}/notes':
parameters:
- schema:
Expand Down