Swaggify Workflow API, part 2 #29828
Labels
LTS: Needs Backport
Ticket that will be added to LTS
Merged
QA : Approved
QA : Passed Internal
Release : 24.10.08
Bug Fixing
Team : Scout
Type : Task
Comments
94 tasks
3 tasks
github-project-automation
bot
moved this from In Review
to Internal QA
in dotCMS - Product Planning
3 tasks
github-project-automation
bot
moved this from Internal QA
to Current Sprint Backlog
in dotCMS - Product Planning
nollymar
moved this from Current Sprint Backlog
to Internal QA
in dotCMS - Product Planning
IQA FAILEDTested on Great job on this! 👏 I've identified a few minor inconsistencies and formatting issues, which are outlined in detail in this document |
3 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 7, 2024
This PR addresses various small and sundry changes raised in the IQA pass, visible [here](https://docs.google.com/document/d/1Q4iSSVtbPVMGjGrKP8MyJ8g2X1Dl0rWZAopKK7Lcq78/edit). Point by point below: ### Proposed Changes * Fixed spacing on `DELETE /workflow/actionlets/{actionletId}` return statement. * Fixed rendering of link on `PUT /workflow/actions/{actionId}` description * Fixed "a.k.a." consistency throughout (plus em-dashes) * Adjusted `WorkflowActionForm` to add Swagger's `@Hidden` annotation, thereby removing deprecated or erroneous properties from display in `POST /api/v1/workflow/actions` and `PUT /workflow/actions/{actionId}` * Adjusted `ResponseEntityWorkflowActionView` class to prototype with WorkflowAction instead of WorkflowActionView class, removing unnecessary `actionInputs` from example. * Found the source of missing `actionlet.nextStep` property, but it's a very deep-set issue that involves a mix of code from 2012 and various actionlet subclasses that add `getNextStep{ return null }` methods. Might eventually make for an interesting project to determine whether these methods are necessary, but for now it was safer to just add a manual example response string. * **No action needed** on nextStepCurrentStep property; it was present in the response description, but it was farther down in the object than it appears in the typical response. * Fixed table formatting by adding newlines to request body description in `POST /workflow/schemes` and `PUT /workflow/schemes/{schemeId}` * Fixed table formatting by REMOVING newlines in `POST /workflow/steps` and `PUT /workflow/steps/{stepId}` ### Checklist - [ ] Tests - [ ] Translations - [ ] Security Implications Contemplated (add notes if applicable)
github-project-automation
bot
moved this from Next 1-3 Sprints
to Internal QA
in dotCMS - Product Planning
github-project-automation
bot
moved this from Internal QA
to Current Sprint Backlog
in dotCMS - Product Planning
valentinogiardino
moved this from Current Sprint Backlog
to Internal QA
in dotCMS - Product Planning
IQA PASSEDTested on |
valentinogiardino
moved this from Internal QA
to QA - Backlog
in dotCMS - Product Planning
|
Fixed, improvements looks better now |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Parent Issue
#28600
Task
The long-awaited second round of Workflow API doc. Unfortunately, there are still five endpoints that need a little work:
firemultipartones still need their multipart form bodies documented, and I'm still trying to understand how that goes:On the latter two, I'm able to make successful calls via curl, but when I paste the same data body into the Playground, I get a 406 response. I'm wondering if maybe it has to do with this bit of code present on both of them:
Either way, I have a lot more material ready to go, and I'll be attaching the PR to illustrate this shortly.
Proposed Objective
Documentation
Proposed Priority
Priority 3 - Average
Acceptance Criteria
No response
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
No response
Assumptions & Initiation Needs
No response
Quality Assurance Notes & Workarounds
No response
Sub-Tasks & Estimates
No response
The text was updated successfully, but these errors were encountered: