docs(ai-docs): task refactor migration — task list & component layer (PR 4/4)#648
docs(ai-docs): task refactor migration — task list & component layer (PR 4/4)#648akulakum wants to merge 18 commits intowebex:nextfrom
Conversation
Add planning and reference documentation: - 011: Execution plan (10-milestone spec-first implementation plan) - 012: Task lifecycle flows (14 end-to-end scenarios, old vs new code paths) - 013: File inventory (25 files referencing old control names/types, cross-reference matrix) Made-with: Cursor
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 708abfdacc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ### M1: Types & Constants Alignment (1-2 days) | ||
|
|
||
| **Ref:** [009-types-and-constants-migration.md](./009-types-and-constants-migration.md) |
There was a problem hiding this comment.
This execution plan points to prerequisite docs such as 009-types-and-constants-migration.md, but those targets are not present under ai-docs/migration in this tree (only 011–013 exist), so the milestone references are not navigable. Because each milestone depends on those linked specs, these broken links make the plan hard to execute and easy to misinterpret until the missing docs are added or the links are corrected.
Useful? React with 👍 / 👎.
| | cc-components types | 1 (central type file) | 0 | | ||
| | cc-components utils | 2 | 3+ (unaffected) | | ||
| | cc-components components | 4 | 8+ (unaffected) | | ||
| | Store | 3 | 1 (`store.ts`) | |
There was a problem hiding this comment.
The document claims to be a definitive checklist of all old-control/state-flag references, but the Store summary omits store/src/store.types.ts, which still declares the legacy isDeclineButtonEnabled field used by IStore. If migration work follows this checklist as written, engineers can remove the runtime field from store.ts and miss the interface cleanup, leading to avoidable type breakage and an incomplete migration.
Useful? React with 👍 / 👎.
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d7d3d3264d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | # | File | Old References | Migration Doc | | ||
| |---|------|---------------|--------------| | ||
| | 1 | `task/src/Utils/task-util.ts` | `getControlsVisibility()` — the entire function (~650 lines). Computes all 22 controls + 7 state flags. Calls `getConsultStatus`, `findHoldStatus`, `getIsConferenceInProgress`, etc. | [Doc 002](./002-ui-controls-migration.md) | |
There was a problem hiding this comment.
This inventory is framed as the definitive migration checklist, but its per-file references point to docs like ./002-ui-controls-migration.md and ./010-component-layer-migration.md that do not exist in ai-docs/migration in this tree (only 011–013 are present), so readers cannot follow the linked implementation guidance. That makes the checklist non-actionable until these links are corrected or the missing docs are added.
Useful? React with 👍 / 👎.
| | cc-components types | 1 (central type file) | 0 | | ||
| | cc-components utils | 2 | 3+ (unaffected) | | ||
| | cc-components components | 4 | 8+ (unaffected) | | ||
| | Store | 3 | 1 (`store.ts`) | |
There was a problem hiding this comment.
The summary table classifies store.ts as an unaffected Store file, but later in the same document store/src/store.ts is explicitly listed as containing legacy migration targets (refreshTaskList(), isDeclineButtonEnabled). This contradiction in the top-level rollup can cause migration work to skip a file that the detailed plan says must be updated.
Useful? React with 👍 / 👎.
Move planning & reference migration docs to packages/contact-center/ai-docs/migration/. Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 021b370718
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## Purpose | ||
|
|
||
| This is the definitive inventory of **every file** in CC Widgets that references old task control names, state flags, or the `ControlVisibility` type. Use this as a checklist during migration to ensure nothing is missed. |
There was a problem hiding this comment.
This file declares itself the definitive list of every legacy-control reference, but it misses at least cc-components/src/components/task/IncomingTask/incoming-task.tsx and cc-components/src/components/task/TaskList/task-list.tsx, both of which still use legacy flags (isBrowser/isDeclineButtonEnabled) and pass them through migration-sensitive paths. I verified this with rg over packages/contact-center/cc-components/src/components/task, so following this checklist as written can leave required migrations incomplete.
Useful? React with 👍 / 👎.
| --- | ||
|
|
||
| _Created: 2026-03-09_ | ||
| _Parent: [001-migration-overview.md](./001-migration-overview.md)_ |
There was a problem hiding this comment.
The parent reference points to ./001-migration-overview.md, but that target is not present in packages/contact-center/ai-docs/migration in this revision, so readers cannot navigate to the upstream overview from this document. This breaks the intended migration-doc chain and makes the flow reference harder to use.
Useful? React with 👍 / 👎.
Not a task-refactor change — keep migration docs scoped to SDK state machine migration only. Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 05808a1f8f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | # | File | Old References | Migration Doc | | ||
| |---|------|---------------|--------------| | ||
| | 18 | `store/src/constants.ts` | `TASK_STATE_CONSULT`, `TASK_STATE_CONSULTING`, `CONSULT_STATE_INITIATED`, `CONSULT_STATE_COMPLETED`, etc. — used by `getConsultStatus()` | [Doc 009](./009-types-and-constants-migration.md) | | ||
| | 19 | `store/src/store.ts` | `refreshTaskList()` method, `isDeclineButtonEnabled` observable | [Doc 003](./003-store-event-wiring-migration.md) | |
There was a problem hiding this comment.
This inventory row says store/src/store.ts contains refreshTaskList(), but that method is implemented in store/src/storeEventsWrapper.ts (and store.ts only carries the isDeclineButtonEnabled field). Because this document is positioned as the migration checklist, this mislocation can send implementers to the wrong file and leave the actual event-wiring cleanup in storeEventsWrapper.ts incomplete.
Useful? React with 👍 / 👎.
…and component-layer Removed 011-execution-plan, 012-task-lifecycle-flows, 013-file-inventory. Added task-list-migration.md and component-layer-migration.md (moved from PR 3). Added ControlVisibility deletion details to component doc. Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a2d7be4a2d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return ( | ||
| <div className="call-control"> | ||
| {controls.hold.isVisible && ( | ||
| <Button onClick={() => onToggleHold(!controls.hold.isEnabled)} disabled={!controls.hold.isEnabled}> |
There was a problem hiding this comment.
The proposed migrated snippet calls onToggleHold(!controls.hold.isEnabled), but isEnabled is an actionability flag, not the current hold state; this can invert hold/resume behavior (e.g., enabled controls would always pass false) and directly conflicts with the later guidance in this same doc that isHeld must come from findHoldStatus(...). If implementers follow this example, they can ship incorrect hold handling in the migrated CallControl flow.
Useful? React with 👍 / 👎.
| | `task/src/helper.ts` (`useTaskList`) | Remove `isBrowser`, use per-task `uiControls` for accept/decline | | ||
| | `task/src/TaskList/index.tsx` | Remove `isBrowser` prop pass-through | | ||
| | `cc-components/.../TaskList/task-list.tsx` | Use `task.uiControls.accept/decline` per task | | ||
| | `cc-components/.../Task/task.utils.ts` | Update task data extraction if status source changes | |
There was a problem hiding this comment.
This migration checklist sends status-related updates to Task/task.utils.ts, but current TaskList status extraction is implemented in TaskList/task-list.utils.ts (task.data.interaction.state and displayState), and TaskList paths do not call getTaskStatus(). Following this plan will focus work on the wrong utility and can leave the real TaskList status logic unmigrated.
Useful? React with 👍 / 👎.
akulakum
changed the title
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a2d7be4a2d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return ( | ||
| <div className="call-control"> | ||
| {controls.hold.isVisible && ( | ||
| <Button onClick={() => onToggleHold(!controls.hold.isEnabled)} disabled={!controls.hold.isEnabled}> |
There was a problem hiding this comment.
This example drives onToggleHold from !controls.hold.isEnabled, but isEnabled represents whether the UI action is currently allowed, not whether the call is already held. If implementers follow this snippet, hold/resume behavior will flip incorrectly in states where hold is temporarily disabled (for example consult/transition states), which can produce the wrong action request; the toggle should be based on actual hold state derived from task data.
Useful? React with 👍 / 👎.
|
|
||
| --- | ||
|
|
||
| _Parent: [migration-overview.md](./migration-overview.md)_ |
There was a problem hiding this comment.
This footer points to ./migration-overview.md, but there is no migration-overview.md in packages/contact-center/ai-docs/migration (or elsewhere in packages/contact-center/ai-docs), so the navigation link is broken in rendered docs. Because this same parent link is used in both new migration docs, readers cannot reach the intended overview unless the target file is added or the link is corrected.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fe1dadaa66
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| buddyAgents: Agent[]; | ||
| consultAgentName: string; | ||
| // Actions | ||
| onToggleHold: () => void; |
There was a problem hiding this comment.
The proposed interface declares onToggleHold: () => void, but the same example later calls onToggleHold(!isHeld) and the current contract (toggleHold(hold: boolean) in cc-components/src/components/task/task.types.ts) is boolean-driven. If migration work follows this signature as written, implementers will either hit TypeScript errors or lose explicit hold/resume intent in the handler.
Useful? React with 👍 / 👎.
| | `cc-components/.../CallControlCustom/consult-transfer-popover.tsx` | Update `isConferenceInProgress` prop | **LOW** | | ||
| | `cc-components/.../IncomingTask/incoming-task.tsx` | Minor prop updates | **LOW** | | ||
| | `cc-components/.../TaskList/task-list.tsx` | Minor prop updates | **LOW** | | ||
| | `task/src/CallControlCAD/index.tsx` | Remove `deviceType`, `featureFlags`, `conferenceEnabled` (retain `agentId`) | **MEDIUM** | |
There was a problem hiding this comment.
This table row tells implementers to remove deviceType, featureFlags, and conferenceEnabled in CallControlCAD, but earlier in the same document the guidance says these values must be retained in useCallControl for feature-gate overlay logic. Leaving this contradiction can drive migrations to drop required inputs and regress control-visibility behavior.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 70b8a7d1a1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| controls, // TaskUIControls — all 17 controls from SDK | ||
| isHeld, // From parent: findHoldStatus(task, 'mainCall', agentId) | ||
| isMuted, isRecording, holdTime, | ||
| onToggleHold, onToggleMute, onEndCall, onEndConsult, |
There was a problem hiding this comment.
The same document defines the new prop as onEndConsultCall in CallControlComponentProps, but this migrated snippet destructures and invokes onEndConsult; following the example as written will wire a non-existent prop name and can lead to TypeScript errors or a dead End Consult button handler during migration.
Useful? React with 👍 / 👎.
| |------|--------| | ||
| | `task/src/helper.ts` (`useTaskList`) | Remove `isBrowser`, use per-task `uiControls` for accept/decline | | ||
| | `task/src/TaskList/index.tsx` | Remove `isBrowser` prop pass-through | | ||
| | `cc-components/.../TaskList/task-list.tsx` | Use `task.uiControls.accept/decline` per task | |
There was a problem hiding this comment.
This checklist points per-task accept/decline migration at TaskList/task-list.tsx, but in the current widget flow that component delegates button text/disable state to extractTaskListItemData(...) in TaskList/task-list.utils.ts, where isBrowser-based logic still drives accept/decline behavior; if engineers follow this file list, task.uiControls migration will be incomplete and legacy device-type gating will remain.
Useful? React with 👍 / 👎.
…o checklist (Codex PR 648)
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 67eea18031
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // NEW — import from SDK | ||
| import type { TaskUIControls } from '@webex/contact-center'; |
There was a problem hiding this comment.
This migration doc instructs cc-components code to import TaskUIControls directly from @webex/contact-center, but the repo’s architecture guidance in /workspace/widgets/AGENTS.md requires the dependency flow cc-components → store → SDK, and packages/contact-center/cc-components/package.json currently only depends on @webex/cc-store (not @webex/contact-center). Following this instruction will either break the layering rule or force a new direct SDK dependency in cc-components, so the type source should be routed via cc-store (or equivalent) instead of a direct SDK import.
Useful? React with 👍 / 👎.
| {controls.transfer.isVisible && ( | ||
| <Button disabled={!controls.transfer.isEnabled}>Transfer</Button> | ||
| )} | ||
| {controls.consult.isVisible && ( | ||
| <Button disabled={!controls.consult.isEnabled}>Consult</Button> |
There was a problem hiding this comment.
In the “new approach” CallControl example, both Transfer and Consult buttons are rendered with visibility/enablement checks but no onClick callback, so implementers following this migration snippet can ship buttons that appear active yet do nothing when clicked. Since this section is presented as the full before/after migration target, it should show handler wiring for these controls to avoid regressions in core call actions.
Useful? React with 👍 / 👎.
…andlers (Codex PR 648)
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c5a4d2ab2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| <Button onClick={onTransferCall} disabled={!controls.transfer.isEnabled}>Transfer</Button> | ||
| )} | ||
| {controls.consult.isVisible && ( | ||
| <Button onClick={onConsultCall} disabled={!controls.consult.isEnabled}>Consult</Button> |
There was a problem hiding this comment.
This migrated example wires onTransferCall and onConsultCall directly to button onClick, but earlier in the same document those callbacks are defined as payload-driven handlers ((payload: ...) => void). Following this as written will either create TypeScript signature mismatches or invoke handlers without the destination payload needed for transfer/consult operations, making the migration guidance internally inconsistent for implementers.
Useful? React with 👍 / 👎.
…ndler signatures (Codex PR 648)
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fbaff4765b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| // NEW — import via store to preserve layering (cc-components → store → SDK). Store re-exports TaskUIControls from SDK. | ||
| import type { TaskUIControls } from '@webex/cc-store'; |
There was a problem hiding this comment.
This guide tells implementers to import type { TaskUIControls } from '@webex/cc-store', but @webex/cc-store does not currently export that symbol (store/src/index.ts only re-exports ./store.types and ./task-utils, and store/src/store.types.ts has no TaskUIControls export). Following the migration steps as written will fail with a TypeScript “no exported member” error, so the doc should either add a prerequisite re-export step in cc-store or point to the actual available type source.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d147f474d4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {controls.wrapup.isVisible && ( | ||
| <Button disabled={!controls.wrapup.isEnabled}>Wrap Up</Button> | ||
| )} |
There was a problem hiding this comment.
The “After” CallControl example renders the Wrap Up button without an onClick, even though the proposed interface defines onWrapupCall. If implementers follow this snippet as the migration target, they can ship a visible/enabled Wrap Up control that does nothing at runtime, regressing a core call-completion action.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3375c74f52
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // NEW: derive from controls.endConsult.isVisible && !controls.mergeToConference.isEnabled | ||
| ``` |
There was a problem hiding this comment.
This migration step derives consultInitiated from controls.endConsult.isVisible && !controls.mergeToConference.isEnabled, but this file already notes that endConsult.isVisible spans both initiated and accepted consult states; using it to drive getConsultStatusText() can therefore misclassify consult phase and show incorrect status/timer text when merge enablement changes for unrelated reasons (for example feature gating or temporary action disablement).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 085d8153c6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| onTransferCall: (payload: TransferPayLoad) => void; // Invoked from transfer popover on submit | ||
| onConsultCall: (payload: ConsultPayload) => void; // Invoked from consult popover on submit |
There was a problem hiding this comment.
The proposed CallControlComponentProps introduces onTransferCall(payload: TransferPayLoad) and onConsultCall(payload: ConsultPayload), but neither payload type exists anywhere in this repo (rg finds no definitions), so implementers following this snippet will hit immediate TypeScript errors unless they invent types ad hoc. Because this section is presented as the migration contract, it should either reference existing exported types or explicitly add where these payload types are defined.
Useful? React with 👍 / 👎.
|
@codex review |
|
Codex Review: Didn't find any major issues. Hooray! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9243b41987
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | `cc-components/.../CallControlCustom/consult-transfer-popover.tsx` | Update `isConferenceInProgress` prop | **LOW** | | ||
| | `cc-components/.../IncomingTask/incoming-task.tsx` | Minor prop updates | **LOW** | | ||
| | `cc-components/.../TaskList/task-list.tsx` | Minor prop updates | **LOW** | | ||
| | `task/src/CallControlCAD/index.tsx` | **Retain** `deviceType`, `featureFlags`, `conferenceEnabled` for `applyFeatureGates` overlay; retain `agentId` | **MEDIUM** | |
There was a problem hiding this comment.
The migration checklist only names task/src/CallControlCAD/index.tsx, but the actual legacy control-shape usage is in cc-components/src/components/task/CallControlCAD/call-control-cad.tsx (for example it reads controlVisibility.isConferenceInProgress, isHeld, isConsultReceived, recordingIndicator, and isConsultInitiatedOrAccepted). If implementers follow this file list as-is while replacing ControlVisibility with TaskUIControls, they can miss this component and leave stale props/state-flag references that break the migration at compile time or runtime.
Useful? React with 👍 / 👎.
…list Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 425255fde6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ```typescript | ||
| // Old: isConferenceInProgress (boolean prop) | ||
| // New: derive from controls | ||
| const isConferenceInProgress = controls.exitConference.isVisible; |
There was a problem hiding this comment.
This migration mapping equates conference state with controls.exitConference.isVisible, but visibility is an action flag and is not a reliable source of truth for call state. In the current task logic (task/src/Utils/task-util.ts#getExitConferenceButtonVisibility), isVisible is forced false when consult is active even if isConferenceInProgress is true, so following this guidance can misclassify an active conference as inactive and break downstream rendering/filtering decisions.
Useful? React with 👍 / 👎.
| isRecording: boolean; | ||
| holdTime: number; | ||
| secondsUntilAutoWrapup: number; | ||
| buddyAgents: Agent[]; |
There was a problem hiding this comment.
The proposed interface switches buddyAgents to Agent[], but this repo’s task component contracts use BuddyDetails[] and there is no exported Agent type from @webex/cc-store in the current codepath. If implementers copy this contract as written, they will hit TypeScript errors or introduce ad hoc local types, which makes the migration contract non-actionable.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a97cdacebe
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {controls.exitConference?.isVisible && !controls.wrapup.isVisible && ( | ||
| // ... | ||
| )} | ||
| {isHeld && !controls.consult?.isVisible && ( |
There was a problem hiding this comment.
This "After" snippet replaces !isConsultReceived && !consultCallHeld with !controls.consult?.isVisible, but consult.isVisible is an action-availability flag rather than a consult-state flag. In current task logic, consult visibility is true for normal telephony calls where consult is merely available, so following this migration example can suppress the on-hold chip for valid held calls that are not in consult-received/consult-held states.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 791b189ea7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const TaskListComponent = ({ taskList, onAccept, onDecline, onSelect }) => { | ||
| return taskList.map((task) => { |
There was a problem hiding this comment.
This example calls taskList.map(...), but the same document states store.taskList remains a Record<string, ITask> (not an array). If implementers follow this snippet while keeping the documented data shape, they will hit taskList.map is not a function at runtime; the example should convert with Object.values(taskList) (or equivalent) before iterating.
Useful? React with 👍 / 👎.
| - If `getTaskStatus()` is used for display, consider using SDK task state info | ||
| - Accept/decline button visibility per task: use `task.uiControls?.accept` and `task.uiControls?.decline` (each has `isVisible`, `isEnabled`) | ||
| - Task selection logic unchanged | ||
| - Optional: if the list must react to control updates without task replacement, subscribe to `'task:ui-controls-updated'` per task (event name; enum `TASK_UI_CONTROLS_UPDATED` may not exist in store yet — use literal) |
There was a problem hiding this comment.
The migration note recommends subscribing to 'task:ui-controls-updated', but the current store wrapper only accepts TASK_EVENTS values (setTaskCallback(event: TASK_EVENTS, ...)), and that enum does not include this event. Following this instruction as written in this repo leads to an unregistrable listener path unless the docs first require adding the enum/wrapper support (or explicitly show a direct SDK task.on(...) alternative).
Useful? React with 👍 / 👎.
| ### Files NOT Impacted (Confirmed) | ||
|
|
||
| | File | Reason | | ||
| |------|--------| |
There was a problem hiding this comment.
applyFeatureGates does not exist in SDK or widgets repo.
Searched both the SDK task-refactor branch and the entire widgets codebase — no function named applyFeatureGates exists anywhere.
The widgets layer currently uses featureFlags and conferenceEnabled directly inside task-util.ts:getControlsVisibility() (lines 421-525), not via a named applyFeatureGates function.
Since the new SDK state machine (uiControlsComputer.ts) handles feature-flag-like gating internally (e.g. config.isEndTaskEnabled, config.isEndConsultEnabled, config.isRecordingEnabled), this guidance should clarify:
- Which feature flags are now handled by SDK config vs. still needed in widgets
- Remove the
applyFeatureGatesreference — it will confuse implementers looking for a function that doesn't exist
| | `muteUnmuteConsult` | — | **Remove** (use `mute`) | | ||
| | `isConferenceInProgress` | — | **Remove** (derive from task/participant state, not controls.exitConference.isVisible) | | ||
| | `isConsultInitiated` | — | **Remove** (derive from controls or task state) | | ||
| | `isConsultInitiatedAndAccepted` | — | **Remove** | |
There was a problem hiding this comment.
Clarify conference vs mergeToConference relationship.
The SDK has both conference and mergeToConference as separate controls. Looking at uiControlsComputer.ts:
conference: visible during consulting when initiator, agent joined, and not max participants. Used for the "Conference" / "Merge" button on the main/consult leg.mergeToConference: mirrorsconference— same conditions, same visibility.
The doc maps mergeConference → mergeToConference (correct), but the table at line 72 doesn't mention that the SDK also has a separate conference control with overlapping semantics. An implementer might not know which to use.
Consider adding a note explaining the dual-control design (e.g., conference for initiating a conference from consult, mergeToConference as a semantic alias for merge action).
2 participants
COMPLETES #https://jira-eng-sjc12.cisco.com/jira/browse/CAI-7714
This pull request addresses
This is PR 4 of 4 in the task refactor migration documentation series. It covers the task list widget and component layer (
cc-components) migration — the presentational React components that receive control visibility as props.by making the following changes
Added 2 migration documents under
packages/contact-center/ai-docs/migration/:task-list-migration.md: Updates per-task accept/decline rendering to use
task.uiControlsinstead of deriving fromdeviceType:isBrowserprop pass-throughcomponent-layer-migration.md: Covers
cc-componentspresentational changes:ControlVisibilityinterface deletion and replacement withTaskUIControlsbuildCallControlButtons(): 20+ old control references mapped to new namescreateConsultButtons(): consult button builder migrationcall-control.tsxandcall-control-consult.tsx: props interface changesCallControlCAD: removesdeviceType,featureFlags,conferenceEnabled(retainsagentId)isHeldderivation fromfindHoldStatus(task, 'mainCall', agentId)(not fromcontrols.hold)Removed 3 planning/reference documents (superseded by consolidated overview in PR 1):
011-execution-plan.md012-task-lifecycle-flows-old-vs-new.md013-file-inventory-old-control-references.mdCC SDK Task-Refactor Branch Reference
Change Type
Related PRs
The following scenarios were tested
The GAI Coding Policy And Copyright Annotation Best Practices
Checklist before merging