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

[Shujaulislam]

add a customFields array property to campaign filter query params, and introduce a new GET /v2/customfields/campaign endpoint (operationId: campaign-customfields-findAll) that returns available campaign custom field definitions (fields with _id, label, type, name, required, id, hidden, validation, isConsent, options, pub_hide).

Includes 200 and 400 responses and API Key Param security.

Summary by CodeRabbit

• New Features
  • New API endpoint to retrieve all available custom field definitions for campaigns, including comprehensive field metadata such as field type, validation rules, required flags, and consent options.
  • Campaign listing endpoint now supports optional filtering to retrieve campaigns by their associated custom field definitions.

[coderabbitai]

📝 Walkthrough

Walkthrough

The OpenAPI specification was extended with a new public endpoint GET /v2/customfields/campaign to retrieve campaign custom field definitions, including metadata like labels, types, and validation rules. Additionally, the existing campaigns listing endpoint was enhanced with a new optional customFields filter parameter.

Changes

Cohort / File(s)	Summary
OpenAPI Specification admin-openapi-1.2.59.yaml	Added new endpoint GET /v2/customfields/campaign to fetch campaign custom field schemas with fields and error responses. Extended GET /v2/campaigns with a new customFields filter array to support filtering campaigns by custom field definitions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A field for each campaign now blooms,
Custom definitions exit the rooms,
Filters spring forth, fresh and bright,
The API dances with new delight! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding campaign custom fields support to the OpenAPI spec, including both a new endpoint and a filter property.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch TV2-1248-Update-campaign-api-doc-with-custom-field-filter-support

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@admin-openapi-1.2.59.yaml`:
- Around line 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.
- Around line 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.

[coderabbitai]

⚠️ 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.

[coderabbitai]

⚠️ 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.