Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (3)
WalkthroughAdds OpenAPI 3.0 REST API specifications and Redoc documentation for Workflow Management across Asgardeo and WSO2 Identity Server (7.2.0 and next), introducing endpoints for workflows, workflow associations, workflow instances, and workflow engines with pagination, filtering, and security schemes. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (3)
en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml (3)
5-5: Use "REST" (all caps) for the acronym.The title uses "Rest API" but the standard capitalization for this acronym is "REST API".
Suggested fix
- title: WSO2 Identity Server - Workflow Rest API + title: WSO2 Identity Server - Workflow REST API🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml` at line 5, Update the YAML title value that currently reads "WSO2 Identity Server - Workflow Rest API" to use the correct acronym capitalization "REST" so it becomes "WSO2 Identity Server - Workflow REST API"; locate and edit the title key in workflow.yaml (the line with title: WSO2 Identity Server - Workflow Rest API) to replace "Rest" with "REST".
593-600: Consider adding pagination for workflow engines endpoint.Unlike other list endpoints (
/workflows,/workflow-associations,/workflow-instances), the/workflow-enginesendpoint returns an unbounded array without pagination parameters. If the number of workflow engines can grow, consider addinglimitandoffsetparameters for consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml` around lines 593 - 600, The /workflow-engines operation currently returns an unbounded array of WorkflowEngine items; add pagination by introducing query parameters `limit` (integer) and `offset` (integer) to the operation and change the 200 response schema from an array of `WorkflowEngine` to a paginated object (e.g., `{ total: integer, items: array of WorkflowEngine }` or a new `WorkflowEngineList` component) so callers receive `items` plus a `total`/`count`; update the OpenAPI components with the new `WorkflowEngineList` schema and reference it from the response for the `/workflow-engines` endpoint.
462-483: Consider using reusable parameters for consistency.The workflow instances endpoints define
limit,offset,filter, andinstance_idparameters inline, while other endpoints use$refto reusable parameters (e.g.,limitQueryParam,offsetQueryParam). Consider extractinginstance_idto a reusableinstanceIdPathParamincomponents/parametersfor consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml` around lines 462 - 483, Inline query/path parameters (limit, offset, filter, instance_id) are used in the workflow instances paths instead of reusing existing parameter definitions; extract the instance_id path parameter into a reusable components parameter (suggested name: instanceIdPathParam) under components/parameters and replace the inline instance_id usage with a $ref to that parameter; also align the limit and offset to use the existing limitQueryParam and offsetQueryParam (and consider adding a reusable filterQueryParam if desired) so the workflow endpoints reference limitQueryParam, offsetQueryParam, and instanceIdPathParam instead of defining them inline.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@en/asgardeo/docs/apis/restapis/workflow.yaml`:
- Line 468: Update the OpenAPI operation summary that currently reads "Get
workflow instances for a tenant" to use Asgardeo terminology by replacing
"tenant" with "organization" (e.g., change the summary in workflow.yaml from
"Get workflow instances for a tenant" to "Get workflow instances for an
organization") so the contract remains organization-scoped and consistent with
Asgardeo terms.
- Around line 383-387: The documented scope for the "Delete a specific workflow
association" operation is incorrect: it currently lists
internal_workflow_association_view (read scope) which will cause authorization
failures for deletions; update the description block for the delete operation to
require the correct delete scope (e.g., internal_workflow_association_delete)
wherever internal_workflow_association_view is referenced in that operation's
description or security requirements so the spec advertises the proper
permission for the delete endpoint.
- Around line 87-105: The examples violate the schema: OptionDetails.values is
string[] and the Operation enum doesn't include UPDATE_ROLE; update all sample
occurrences (e.g., the step options block using OptionDetails.values and the
association example referencing operation) to match the contract by converting
numeric scalars to quoted strings (e.g., "123", "124", "234", "235") and replace
any invalid operation tokens (like UPDATE_ROLE) with a valid Operation enum
value defined in the spec, and apply the same fixes to the other example blocks
the reviewer noted so examples are consistent with OptionDetails.values and
Operation.
In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml`:
- Around line 369-372: The DELETE operation's scope is incorrect: change the
scope string in the delete workflow association operation from
"internal_workflow_association_view" to the appropriate delete scope (consistent
with other deletes, e.g., use "internal_workflow_association_delete" or the
existing "internal_workflow_delete" used by deleteWorkflowById) so the operation
requires a _delete scope instead of the _view scope; update the scope entry for
the DELETE operation in the workflow association operation definition
accordingly.
- Around line 433-438: The 401/403/409 response entries in workflow.yaml
incorrectly use description: with reference strings; change each to use a $ref
mapping instead (e.g., replace the "401"/"403"/"409" response blocks that
currently have description:
"#/components/responses/Unauthorized|Forbidden|Conflict" with a $ref:
"#/components/responses/Unauthorized|Forbidden|Conflict" entry) so the responses
reference the components properly for OpenAPI rendering; update the blocks for
"401", "403", and "409" accordingly.
- Around line 956-961: The YAML currently defines requestParameters and
properties as siblings; fix by nesting properties under requestParameters so the
schema reads requestParameters -> type -> properties -> items -> $ref; update
the indentation for the block containing properties, type, items and the "$ref:
'#/components/schemas/Property'" so they are children of requestParameters (or
replace properties with additionalProperties referencing the same $ref if
dynamic key-value pairs are intended).
In `@en/identity-server/next/docs/apis/restapis/workflow.yaml`:
- Around line 92-110: The examples under template (notificationsForApprovers,
steps, etc.) contradict the schema: OptionDetails.values is defined as string[]
but the sample uses numeric scalars (e.g., 123, 124, 234, 235), and the
association examples reference an operation named UPDATE_ROLE which is not in
the Operation enum; fix by making the examples conform to the contract—either
change those numeric literals to quoted strings (e.g., "123") to match
OptionDetails.values or update the schema/type of OptionDetails.values to accept
numbers, and replace any invalid operation names (e.g., UPDATE_ROLE) in the
examples with one of the declared Operation values (or add UPDATE_ROLE to the
Operation enum if intended); update all occurrences mentioned (the current block
plus the ranges called out: 182-198, 220-236, 294-298) so examples and schema
are consistent.
- Around line 388-392: The OpenAPI doc for the association DELETE operation
currently lists the wrong scope ("internal_workflow_association_view"); update
the description in workflow.yaml for the delete endpoint to require the delete
scope instead—replace `internal_workflow_association_view` with the correct
deletion scope (e.g., `internal_workflow_association_delete`) so the documented
<b>Scope required:</b> matches authorization logic for association deletion.
---
Nitpick comments:
In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml`:
- Line 5: Update the YAML title value that currently reads "WSO2 Identity Server
- Workflow Rest API" to use the correct acronym capitalization "REST" so it
becomes "WSO2 Identity Server - Workflow REST API"; locate and edit the title
key in workflow.yaml (the line with title: WSO2 Identity Server - Workflow Rest
API) to replace "Rest" with "REST".
- Around line 593-600: The /workflow-engines operation currently returns an
unbounded array of WorkflowEngine items; add pagination by introducing query
parameters `limit` (integer) and `offset` (integer) to the operation and change
the 200 response schema from an array of `WorkflowEngine` to a paginated object
(e.g., `{ total: integer, items: array of WorkflowEngine }` or a new
`WorkflowEngineList` component) so callers receive `items` plus a
`total`/`count`; update the OpenAPI components with the new `WorkflowEngineList`
schema and reference it from the response for the `/workflow-engines` endpoint.
- Around line 462-483: Inline query/path parameters (limit, offset, filter,
instance_id) are used in the workflow instances paths instead of reusing
existing parameter definitions; extract the instance_id path parameter into a
reusable components parameter (suggested name: instanceIdPathParam) under
components/parameters and replace the inline instance_id usage with a $ref to
that parameter; also align the limit and offset to use the existing
limitQueryParam and offsetQueryParam (and consider adding a reusable
filterQueryParam if desired) so the workflow endpoints reference
limitQueryParam, offsetQueryParam, and instanceIdPathParam instead of defining
them inline.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 60245757-f6be-43fe-babf-d3d2d0f56565
📒 Files selected for processing (9)
en/asgardeo/docs/apis/restapis/workflow.yamlen/asgardeo/docs/apis/workflow-rest-api.mden/asgardeo/mkdocs.ymlen/identity-server/7.2.0/docs/apis/restapis/workflow.yamlen/identity-server/7.2.0/docs/apis/workflow-rest-api.mden/identity-server/7.2.0/mkdocs.ymlen/identity-server/next/docs/apis/restapis/workflow.yamlen/identity-server/next/docs/apis/workflow-rest-api.mden/identity-server/next/mkdocs.yml
| notificationsForInitiator: | ||
| channels: ["email", "sms"] | ||
| events: ["onApproval", "onRejection"] | ||
| template: | ||
| name: MultiStepApprovalTemplate | ||
| notificationsForApprovers: | ||
| channels: ["email", "sms"] | ||
| events: ["onAssignment", "onRelease"] | ||
| steps: | ||
| - step: 1 | ||
| options: | ||
| - entity: roles | ||
| values: | ||
| - 123 | ||
| - 124 | ||
| - entity: users | ||
| values: | ||
| - 234 | ||
| - 235 |
There was a problem hiding this comment.
Keep the examples consistent with the contract.
OptionDetails.values is defined as string[], but these examples use numeric scalars, and the association example uses UPDATE_ROLE, which is not listed in Operation. Either the schema or the samples need to change, otherwise the spec is self-contradictory and the rendered examples will mislead callers.
Also applies to: 177-193, 215-231, 289-293
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/asgardeo/docs/apis/restapis/workflow.yaml` around lines 87 - 105, The
examples violate the schema: OptionDetails.values is string[] and the Operation
enum doesn't include UPDATE_ROLE; update all sample occurrences (e.g., the step
options block using OptionDetails.values and the association example referencing
operation) to match the contract by converting numeric scalars to quoted strings
(e.g., "123", "124", "234", "235") and replace any invalid operation tokens
(like UPDATE_ROLE) with a valid Operation enum value defined in the spec, and
apply the same fixes to the other example blocks the reviewer noted so examples
are consistent with OptionDetails.values and Operation.
| description: | | ||
| Delete a specific workflow association identified by the association ID. | ||
|
|
||
| <b>Scope required:</b> ``internal_workflow_association_view`` | ||
|
|
There was a problem hiding this comment.
Fix the scope documented for association deletion.
This delete endpoint currently advertises internal_workflow_association_view. Readers following the spec will request the read scope and hit authorization failures when they try to delete an association.
📝 Suggested fix
- <b>Scope required:</b> ``internal_workflow_association_view``
+ <b>Scope required:</b> ``internal_workflow_association_delete``📝 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.
| description: | | |
| Delete a specific workflow association identified by the association ID. | |
| <b>Scope required:</b> ``internal_workflow_association_view`` | |
| description: | | |
| Delete a specific workflow association identified by the association ID. | |
| <b>Scope required:</b> ``internal_workflow_association_delete`` | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/asgardeo/docs/apis/restapis/workflow.yaml` around lines 383 - 387, The
documented scope for the "Delete a specific workflow association" operation is
incorrect: it currently lists internal_workflow_association_view (read scope)
which will cause authorization failures for deletions; update the description
block for the delete operation to require the correct delete scope (e.g.,
internal_workflow_association_delete) wherever
internal_workflow_association_view is referenced in that operation's description
or security requirements so the spec advertises the proper permission for the
delete endpoint.
| get: | ||
| tags: | ||
| - Workflow Instances Management | ||
| summary: Get workflow instances for a tenant |
There was a problem hiding this comment.
Use Asgardeo terminology in this summary.
tenant is an Identity Server term, but this contract is organization-scoped. Keeping the summary aligned with Asgardeo terminology avoids mixing the two models on the same page.
📝 Suggested fix
- summary: Get workflow instances for a tenant
+ summary: Get workflow instances for an organization📝 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.
| summary: Get workflow instances for a tenant | |
| summary: Get workflow instances for an organization |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/asgardeo/docs/apis/restapis/workflow.yaml` at line 468, Update the OpenAPI
operation summary that currently reads "Get workflow instances for a tenant" to
use Asgardeo terminology by replacing "tenant" with "organization" (e.g., change
the summary in workflow.yaml from "Get workflow instances for a tenant" to "Get
workflow instances for an organization") so the contract remains
organization-scoped and consistent with Asgardeo terms.
| description: | | ||
| Delete a specific workflow association identified by the association ID. | ||
|
|
||
| <b>Scope required:</b> ``internal_workflow_association_view`` |
There was a problem hiding this comment.
Incorrect scope for DELETE operation.
The delete operation specifies internal_workflow_association_view scope, but DELETE operations typically require a _delete scope. Compare with line 225 where deleteWorkflowById uses internal_workflow_delete.
Proposed fix
description: |
Delete a specific workflow association identified by the association ID.
- <b>Scope required:</b> ``internal_workflow_association_view``
+ <b>Scope required:</b> ``internal_workflow_association_delete``🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml` around lines 369 -
372, The DELETE operation's scope is incorrect: change the scope string in the
delete workflow association operation from "internal_workflow_association_view"
to the appropriate delete scope (consistent with other deletes, e.g., use
"internal_workflow_association_delete" or the existing
"internal_workflow_delete" used by deleteWorkflowById) so the operation requires
a _delete scope instead of the _view scope; update the scope entry for the
DELETE operation in the workflow association operation definition accordingly.
| "401": | ||
| description: "#/components/responses/Unauthorized" | ||
| "403": | ||
| description: "#/components/responses/Forbidden" | ||
| "409": | ||
| description: "#/components/responses/Conflict" |
There was a problem hiding this comment.
Incorrect response references: use $ref instead of description with reference paths.
The 401, 403, and 409 responses incorrectly use description: with reference strings instead of proper $ref: syntax. These responses will not render correctly in the API documentation.
Proposed fix
"401":
- description: "#/components/responses/Unauthorized"
+ $ref: "#/components/responses/Unauthorized"
"403":
- description: "#/components/responses/Forbidden"
+ $ref: "#/components/responses/Forbidden"
"409":
- description: "#/components/responses/Conflict"
- content:
- application/json:
- schema:
- $ref: "#/components/schemas/Error"
+ $ref: "#/components/responses/Conflict"📝 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.
| "401": | |
| description: "#/components/responses/Unauthorized" | |
| "403": | |
| description: "#/components/responses/Forbidden" | |
| "409": | |
| description: "#/components/responses/Conflict" | |
| "401": | |
| $ref: "#/components/responses/Unauthorized" | |
| "403": | |
| $ref: "#/components/responses/Forbidden" | |
| "409": | |
| $ref: "#/components/responses/Conflict" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml` around lines 433 -
438, The 401/403/409 response entries in workflow.yaml incorrectly use
description: with reference strings; change each to use a $ref mapping instead
(e.g., replace the "401"/"403"/"409" response blocks that currently have
description: "#/components/responses/Unauthorized|Forbidden|Conflict" with a
$ref: "#/components/responses/Unauthorized|Forbidden|Conflict" entry) so the
responses reference the components properly for OpenAPI rendering; update the
blocks for "401", "403", and "409" accordingly.
| requestParameters: | ||
| type: object | ||
| properties: | ||
| type: array | ||
| items: | ||
| $ref: "#/components/schemas/Property" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if other workflow-related schemas in the codebase have similar patterns
rg -n "requestParameters|properties:" --type yaml -A2 -B2 en/identity-server/7.2.0/docs/apis/restapis/Repository: wso2/docs-is
Length of output: 50369
🏁 Script executed:
sed -n '939,961p' en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml | cat -ARepository: wso2/docs-is
Length of output: 719
🏁 Script executed:
rg -n "requestParameters:" en/identity-server/7.2.0/docs/apis/restapis/ -A 3 -B 1Repository: wso2/docs-is
Length of output: 511
🏁 Script executed:
rg -n "type: object" en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml -A 2 | grep -A 2 "requestParameters\|requestBody" | head -20Repository: wso2/docs-is
Length of output: 38
🏁 Script executed:
cat -n en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml | sed -n '950,965p'Repository: wso2/docs-is
Length of output: 537
🏁 Script executed:
# Check other object definitions in workflow.yaml to see the proper pattern
rg -n "type: object" en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml -A 5 | head -40Repository: wso2/docs-is
Length of output: 978
🏁 Script executed:
# Compare with a proper nested object structure - find examples of objects with nested properties
rg -n "type: object" en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml -A 10 | grep -B 2 -A 8 "properties:" | head -60Repository: wso2/docs-is
Length of output: 1643
🏁 Script executed:
# Let me check if there's a Property schema that should be items under requestParameters
sed -n '963,975p' en/identity-server/7.2.0/docs/apis/restapis/workflow.yamlRepository: wso2/docs-is
Length of output: 289
🏁 Script executed:
# Check if there are similar patterns in verification-code-management.yaml that was flagged in the initial results
sed -n '128,138p' en/identity-server/7.2.0/docs/apis/restapis/verification-code-management.yamlRepository: wso2/docs-is
Length of output: 295
🏁 Script executed:
# Check the exact indentation pattern for how objects with properties are properly nested
sed -n '615,630p' en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml | cat -ARepository: wso2/docs-is
Length of output: 592
🏁 Script executed:
# Now let's look at the full WorkflowInstanceResponse to understand intent
sed -n '939,962p' en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml | cat -ARepository: wso2/docs-is
Length of output: 721
🏁 Script executed:
# Verify the semantic intent - if requestParameters is type: object, what should its contents be?
# Check if there are any other requestParameters definitions in the codebase
rg -n "requestParameters" en/identity-server/7.2.0/docs/apis/restapis/ -B 2 -A 5Repository: wso2/docs-is
Length of output: 780
Fix indentation: properties array should be nested under requestParameters object.
The properties field at line 958 is currently at the same indentation level as requestParameters (line 956), making them sibling properties. However, logically the array of Property objects should be contained within requestParameters.
Correct the indentation so properties is nested one level deeper under requestParameters:
Expected structure
requestParameters:
type: object
properties:
type: array
items:
$ref: "#/components/schemas/Property"Alternatively, use additionalProperties if requestParameters accepts dynamic key-value pairs:
requestParameters:
type: object
additionalProperties:
$ref: "#/components/schemas/Property"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/identity-server/7.2.0/docs/apis/restapis/workflow.yaml` around lines 956 -
961, The YAML currently defines requestParameters and properties as siblings;
fix by nesting properties under requestParameters so the schema reads
requestParameters -> type -> properties -> items -> $ref; update the indentation
for the block containing properties, type, items and the "$ref:
'#/components/schemas/Property'" so they are children of requestParameters (or
replace properties with additionalProperties referencing the same $ref if
dynamic key-value pairs are intended).
| notificationsForInitiator: | ||
| channels: ["email", "sms"] | ||
| events: ["onApproval", "onRejection"] | ||
| template: | ||
| name: MultiStepApprovalTemplate | ||
| notificationsForApprovers: | ||
| channels: ["email", "sms"] | ||
| events: ["onAssignment", "onRelease"] | ||
| steps: | ||
| - step: 1 | ||
| options: | ||
| - entity: roles | ||
| values: | ||
| - 123 | ||
| - 124 | ||
| - entity: users | ||
| values: | ||
| - 234 | ||
| - 235 |
There was a problem hiding this comment.
Keep the examples consistent with the contract.
OptionDetails.values is defined as string[], but these examples use numeric scalars, and the association example uses UPDATE_ROLE, which is not listed in Operation. Either the schema or the samples need to change, otherwise the spec is self-contradictory and the rendered examples will mislead callers.
Also applies to: 182-198, 220-236, 294-298
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/identity-server/next/docs/apis/restapis/workflow.yaml` around lines 92 -
110, The examples under template (notificationsForApprovers, steps, etc.)
contradict the schema: OptionDetails.values is defined as string[] but the
sample uses numeric scalars (e.g., 123, 124, 234, 235), and the association
examples reference an operation named UPDATE_ROLE which is not in the Operation
enum; fix by making the examples conform to the contract—either change those
numeric literals to quoted strings (e.g., "123") to match OptionDetails.values
or update the schema/type of OptionDetails.values to accept numbers, and replace
any invalid operation names (e.g., UPDATE_ROLE) in the examples with one of the
declared Operation values (or add UPDATE_ROLE to the Operation enum if
intended); update all occurrences mentioned (the current block plus the ranges
called out: 182-198, 220-236, 294-298) so examples and schema are consistent.
| description: | | ||
| Delete a specific workflow association identified by the association ID. | ||
|
|
||
| <b>Scope required:</b> ``internal_workflow_association_view`` | ||
|
|
There was a problem hiding this comment.
Fix the scope documented for association deletion.
This delete endpoint currently advertises internal_workflow_association_view. Readers following the spec will request the read scope and hit authorization failures when they try to delete an association.
📝 Suggested fix
- <b>Scope required:</b> ``internal_workflow_association_view``
+ <b>Scope required:</b> ``internal_workflow_association_delete``📝 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.
| description: | | |
| Delete a specific workflow association identified by the association ID. | |
| <b>Scope required:</b> ``internal_workflow_association_view`` | |
| description: | | |
| Delete a specific workflow association identified by the association ID. | |
| <b>Scope required:</b> ``internal_workflow_association_delete`` | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@en/identity-server/next/docs/apis/restapis/workflow.yaml` around lines 388 -
392, The OpenAPI doc for the association DELETE operation currently lists the
wrong scope ("internal_workflow_association_view"); update the description in
workflow.yaml for the delete endpoint to require the delete scope
instead—replace `internal_workflow_association_view` with the correct deletion
scope (e.g., `internal_workflow_association_delete`) so the documented <b>Scope
required:</b> matches authorization logic for association deletion.
3 participants
Purpose
Related Issues
Test environment
Security checks
Summary by CodeRabbit
New Features
Documentation