Skip to content

chore: API Endpoint support for setting action type - #39983

Merged
dionisio-bot[bot] merged 11 commits into
developfrom
chore/setting-action-endpoint
Apr 1, 2026
Merged

chore: API Endpoint support for setting action type#39983
dionisio-bot[bot] merged 11 commits into
developfrom
chore/setting-action-endpoint

Conversation

@KevLehman

@KevLehman KevLehman commented Mar 30, 2026

Copy link
Copy Markdown
Member

Proposed changes (including videos or screenshots)

Issue(s)

https://rocketchat.atlassian.net/browse/CORE-2028

Steps to test or reproduce

Further comments

Summary by CodeRabbit

  • New Features
    • Action settings now support API endpoints in addition to server methods.
    • Admin panel action buttons display feedback indicating when actions are unavailable until changes are saved.
    • Enhanced error handling with user-friendly toast messages for successful and failed action executions.

@dionisio-bot

dionisio-bot Bot commented Mar 30, 2026

Copy link
Copy Markdown
Contributor

Looks like this PR is ready to merge! 🎉
If you have any trouble, please check the PR guidelines

@changeset-bot

changeset-bot Bot commented Mar 30, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: e06da95

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai

coderabbitai Bot commented Mar 30, 2026

Copy link
Copy Markdown
Contributor

Walkthrough

The PR introduces support for action-type settings that can be executed via either Rocket.Chat server methods or HTTP endpoints. The backend now excludes endpoint-based actions from direct method execution, while new client components provide separate handling paths for method vs. endpoint-based actions through conditional routing.

Changes

Cohort / File(s) Summary
Type Definitions & API
packages/core-typings/src/ISetting.ts, apps/meteor/app/api/server/v1/settings.ts
Extended SettingValue union and ISettingAction.value to support endpoint-based actions ({ method, path }). Added isActionSettingWithEndpoint type guard. Backend now excludes endpoint actions from direct Meteor.callAsync execution when bodyParams.execute is true.
Base Action Input Component
apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx
New reusable component for rendering action buttons with conditional disabling based on sectionChanged state, async action execution, and toast notifications on success/error. Includes hint text indicating unavailability until saving.
Action Setting Router & Implementations
apps/meteor/client/views/admin/settings/Setting/inputs/ActionSettingInput.tsx, apps/meteor/client/views/admin/settings/Setting/inputs/MethodActionInput.tsx, apps/meteor/client/views/admin/settings/Setting/inputs/EndpointActionInput.tsx
Refactored ActionSettingInput to conditionally route between MethodActionInput (for server method actions) and EndpointActionInput (for HTTP endpoint actions) based on isActionSettingWithEndpoint check. Both route implementations delegate button rendering to ActionInputBase.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested labels

type: feature

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'chore: API Endpoint support for setting action type' is directly related to the main change, which refactors action settings to support endpoint-based actions in addition to method-based actions.
Linked Issues check ✅ Passed The PR implements infrastructure for action settings with endpoint support, addressing the CORE-2028 requirement for a Virtru connectivity test button by enabling endpoint-based action settings and routing.
Out of Scope Changes check ✅ Passed All changes are within scope: core typings extended to support endpoint-based actions, API handling updated, and client components refactored to route between method and endpoint actions per CORE-2028 requirements.

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


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

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

@codecov

codecov Bot commented Mar 30, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 65.51724% with 30 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.52%. Comparing base (4235cd9) to head (e06da95).
⚠️ Report is 7 commits behind head on develop.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop   #39983      +/-   ##
===========================================
- Coverage    70.57%   70.52%   -0.06%     
===========================================
  Files         3263     3270       +7     
  Lines       116660   116773     +113     
  Branches     21067    21095      +28     
===========================================
+ Hits         82336    82353      +17     
- Misses       32271    32360      +89     
- Partials      2053     2060       +7     
Flag Coverage Δ
e2e 60.49% <47.36%> (-0.01%) ⬇️
e2e-api 48.08% <ø> (-1.10%) ⬇️
unit 70.95% <55.17%> (-0.05%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@aleksandernsilva
aleksandernsilva force-pushed the chore/setting-action-endpoint branch from 66ae30d to ec206f6 Compare March 31, 2026 14:47
@rc-layne

rc-layne Bot commented Mar 31, 2026

Copy link
Copy Markdown

Layne — scan passed

No security issues found on latest push.

Comment thread apps/meteor/app/api/server/v1/settings.ts Outdated
Comment thread apps/meteor/app/api/server/v1/settings.ts Outdated
Comment thread apps/meteor/app/api/server/v1/settings.ts Outdated
@KevLehman KevLehman added this to the 8.4.0 milestone Mar 31, 2026
@KevLehman
KevLehman marked this pull request as ready for review March 31, 2026 21:11
@KevLehman
KevLehman requested review from a team as code owners March 31, 2026 21:11
@coderabbitai coderabbitai Bot added the type: feature Pull requests that introduces new feature label Mar 31, 2026

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

No issues found across 6 files

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx (1)

24-26: Error handling may not properly display all error types.

The error caught in the catch block is typed as unknown, but it's passed directly to dispatchToastMessage. If the error is not a string or an Error object with a message property, the toast may not display a meaningful message to the user.

🔧 Consider normalizing the error message
 		} catch (error) {
-			dispatchToastMessage({ type: 'error', message: error });
+			dispatchToastMessage({
+				type: 'error',
+				message: error instanceof Error ? error.message : String(error),
+			});
 		}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx`
around lines 24 - 26, The catch block in ActionInputBase.tsx currently passes
the caught unknown error directly to dispatchToastMessage, which may not render
meaningful text for non-string errors; update the catch to normalize the error
before calling dispatchToastMessage (in the catch in the function containing
dispatchToastMessage): if error is an instance of Error use error.message,
otherwise coerce to a readable string (e.g., String(error) or JSON.stringify
when appropriate), and pass that normalized string as the message to
dispatchToastMessage so the toast always shows a clear message.
packages/core-typings/src/ISetting.ts (1)

11-11: Consider unifying SettingValueAction and SettingActionEndpoint types.

Two similar types exist:

  • SettingValueAction (line 11): { method: string; path: string } - loose typing
  • SettingActionEndpoint (line 127): { method: 'GET' | 'POST' | 'PUT' | 'DELETE'; path: string } - strict HTTP methods

SettingValueAction is in the SettingValue union (used broadly), while SettingActionEndpoint is used specifically in ISettingAction.value. This could lead to inconsistent validation—an action setting could technically have a method value that passes the SettingValue check but isn't a valid HTTP method.

🔧 Consider using the stricter type consistently
-export type SettingValueAction = { method: string; path: string };
+export type SettingValueAction = { method: 'GET' | 'POST' | 'PUT' | 'DELETE'; path: string };

Or remove SettingValueAction from the SettingValue union if action settings should only use ISettingAction.value with its own type constraints.

Also applies to: 127-127

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/core-typings/src/ISetting.ts` at line 11, The two action types are
inconsistent: SettingValueAction is loose while SettingActionEndpoint is strict;
update the types so action values use one consistent definition—either replace
SettingValueAction in the SettingValue union with the stricter
SettingActionEndpoint type, or unify both by redefining SettingValueAction to
match SettingActionEndpoint (method: 'GET'|'POST'|'PUT'|'DELETE'; path: string);
ensure ISettingAction.value references the unified type so action settings
cannot carry invalid HTTP methods (adjust any references to SettingValue,
SettingValueAction, SettingActionEndpoint, and ISettingAction.value
accordingly).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/meteor/app/api/server/v1/settings.ts`:
- Around line 351-359: The current branch that checks isSettingAction(setting)
&& isSettingsUpdatePropsActions(bodyParams) && bodyParams.execute &&
!isActionSettingWithEndpoint(setting.value) calls
Meteor.callAsync(setting.value) and returns API.v1.success(), but
endpoint-shaped actions (isActionSettingWithEndpoint(setting.value) === true)
fall through and return API.v1.failure(); update the logic so that when
bodyParams.execute is true and the setting is an endpoint-shaped action you
explicitly return API.v1.success() (either by adding an else branch that returns
API.v1.success() when isActionSettingWithEndpoint(setting.value) is true, or by
changing the condition to handle endpoint-shaped actions separately), leaving
the Meteor.callAsync call only for non-endpoint actions; ensure references:
isSettingAction, isSettingsUpdatePropsActions, bodyParams.execute,
isActionSettingWithEndpoint, Meteor.callAsync, and API.v1.success are used to
locate and implement the fix.

In
`@apps/meteor/client/views/admin/settings/Setting/inputs/EndpointActionInput.tsx`:
- Around line 14-17: EndpointActionInput currently bypasses typing by calling
useEndpoint(endpoint.method, endpoint.path) and invoking it with an unsafe cast
({} as never), which both sends an incorrect empty body and hides the mismatch
between useEndpoint's return type and ActionInputBase's expected Promise<{
message: TranslationKey; params?: string[] }>. Fix by changing
EndpointActionInput to accept or build the correct request body based on
endpoint parameter metadata instead of using {} as never, wrap the raw
useEndpoint call in a typed adapter that maps the actual
Serialized<OperationResult<...>> response into the { message, params? } shape
expected by ActionInputBase (e.g., create a callEndpointWrapper function used in
onAction that transforms types and payload), and/or add a dedicated
action-endpoint response type in `@rocket.chat/rest-typings` so useEndpoint’s
return aligns with ActionInputBase.

---

Nitpick comments:
In `@apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx`:
- Around line 24-26: The catch block in ActionInputBase.tsx currently passes the
caught unknown error directly to dispatchToastMessage, which may not render
meaningful text for non-string errors; update the catch to normalize the error
before calling dispatchToastMessage (in the catch in the function containing
dispatchToastMessage): if error is an instance of Error use error.message,
otherwise coerce to a readable string (e.g., String(error) or JSON.stringify
when appropriate), and pass that normalized string as the message to
dispatchToastMessage so the toast always shows a clear message.

In `@packages/core-typings/src/ISetting.ts`:
- Line 11: The two action types are inconsistent: SettingValueAction is loose
while SettingActionEndpoint is strict; update the types so action values use one
consistent definition—either replace SettingValueAction in the SettingValue
union with the stricter SettingActionEndpoint type, or unify both by redefining
SettingValueAction to match SettingActionEndpoint (method:
'GET'|'POST'|'PUT'|'DELETE'; path: string); ensure ISettingAction.value
references the unified type so action settings cannot carry invalid HTTP methods
(adjust any references to SettingValue, SettingValueAction,
SettingActionEndpoint, and ISettingAction.value accordingly).
🪄 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: 49fb75b6-f0e5-4a9e-9c62-a8d8bbdf2412

📥 Commits

Reviewing files that changed from the base of the PR and between 4364222 and e06da95.

📒 Files selected for processing (6)
  • apps/meteor/app/api/server/v1/settings.ts
  • apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/ActionSettingInput.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/EndpointActionInput.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/MethodActionInput.tsx
  • packages/core-typings/src/ISetting.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
  • GitHub Check: 🔎 Code Check / TypeScript
  • GitHub Check: 🔎 Code Check / Code Lint
  • GitHub Check: 🔨 Test Unit / Unit Tests
  • GitHub Check: 🔨 Test Storybook / Test Storybook
  • GitHub Check: 📦 Meteor Build (coverage)
  • GitHub Check: cubic · AI code reviewer
  • GitHub Check: CodeQL-Build
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js}

📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)

**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation

Files:

  • apps/meteor/client/views/admin/settings/Setting/inputs/EndpointActionInput.tsx
  • apps/meteor/app/api/server/v1/settings.ts
  • apps/meteor/client/views/admin/settings/Setting/inputs/MethodActionInput.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/ActionSettingInput.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx
  • packages/core-typings/src/ISetting.ts
🧠 Learnings (16)
📓 Common learnings
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:18.785Z
Learning: In Rocket.Chat PR reviews, maintain strict scope boundaries—when a PR is focused on a specific endpoint (e.g., rooms.favorite), avoid reviewing or suggesting changes to other endpoints that were incidentally refactored (e.g., rooms.invite) unless explicitly requested by maintainers.
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.
📚 Learning: 2026-03-27T14:52:56.865Z
Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 39892
File: apps/meteor/client/views/room/contextualBar/Threads/Thread.tsx:150-155
Timestamp: 2026-03-27T14:52:56.865Z
Learning: In Rocket.Chat, there are two different `ModalBackdrop` components with different prop APIs. During review, confirm the import source: (1) `rocket.chat/fuselage` `ModalBackdrop` uses `ModalBackdropProps` based on `BoxProps` (so it supports `onClick` and other Box/DOM props) and does not have an `onDismiss` prop; (2) `rocket.chat/ui-client` `ModalBackdrop` uses a narrower props interface like `{ children?: ReactNode; onDismiss?: () => void }` and handles Escape keypress and outside mouse-up, and it does not forward arbitrary DOM props such as `onClick`. Flag mismatched props (e.g., `onDismiss` passed to the fuselage component or `onClick` passed to the ui-client component) and ensure the usage matches the correct component being imported.

Applied to files:

  • apps/meteor/client/views/admin/settings/Setting/inputs/EndpointActionInput.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/MethodActionInput.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/ActionSettingInput.tsx
  • apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx
📚 Learning: 2026-03-16T21:50:42.118Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:42.118Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs, removing endpoint types and validators from `rocket.chat/rest-typings` (e.g., `UserRegisterParamsPOST`, `/v1/users.register` entry) is the *required* migration pattern per RocketChat/Rocket.Chat-Open-API#150 Rule 7 ("No More rest-typings or Manual Typings"). The endpoint type is re-exposed via a module augmentation `.d.ts` file in the consuming package (e.g., `packages/web-ui-registration/src/users-register.d.ts`). This is NOT a breaking change — the correct changeset bump for `rocket.chat/rest-typings` in this scenario is `minor`, not `major`. Do not flag this as a breaking change during OpenAPI migration reviews.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
  • packages/core-typings/src/ISetting.ts
📚 Learning: 2026-03-15T14:31:28.969Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39647
File: apps/meteor/app/api/server/v1/users.ts:710-757
Timestamp: 2026-03-15T14:31:28.969Z
Learning: In RocketChat/Rocket.Chat, the `UserCreateParamsPOST` type in `apps/meteor/app/api/server/v1/users.ts` (migrated from `packages/rest-typings/src/v1/users/UserCreateParamsPOST.ts`) intentionally has `fields: string` (non-optional) and `settings?: IUserSettings` without a corresponding AJV schema entry. This is a pre-existing divergence carried over verbatim from the original rest-typings source (PR `#39647`). Do not flag this type/schema misalignment during the OpenAPI migration review — it is tracked as a separate follow-up fix.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-02-24T19:09:01.522Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:01.522Z
Learning: In Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1, avoid introducing logic changes. Only perform scope-tight changes that preserve behavior; style-only cleanups (e.g., removing inline comments) may be deferred to follow-ups to keep the migration PR focused.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2025-11-05T20:53:57.761Z
Learnt from: sampaiodiego
Repo: RocketChat/Rocket.Chat PR: 37357
File: apps/meteor/ee/server/startup/federation.ts:39-74
Timestamp: 2025-11-05T20:53:57.761Z
Learning: In Rocket.Chat (apps/meteor/app/settings/server/CachedSettings.ts), the settings.watchMultiple() method immediately invokes its callback with current values if all requested settings exist in the store, then continues watching for subsequent changes. It does not wait for a setting to change before the first invocation.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-03-14T14:58:58.834Z
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2025-09-19T15:15:04.642Z
Learnt from: rodrigok
Repo: RocketChat/Rocket.Chat PR: 36991
File: apps/meteor/server/services/federation/infrastructure/rocket-chat/adapters/Settings.ts:219-221
Timestamp: 2025-09-19T15:15:04.642Z
Learning: The Federation_Matrix_homeserver_domain setting in apps/meteor/server/services/federation/infrastructure/rocket-chat/adapters/Settings.ts is part of the old federation system and is being deprecated/removed, so configuration issues with this setting should not be flagged for improvement.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-02-25T20:10:16.987Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38913
File: packages/ddp-client/src/legacy/types/SDKLegacy.ts:34-34
Timestamp: 2026-02-25T20:10:16.987Z
Learning: In the RocketChat/Rocket.Chat monorepo, packages/ddp-client and apps/meteor do not use TypeScript project references. Module augmentations in apps/meteor (e.g., declare module 'rocket.chat/rest-typings') are not visible when compiling packages/ddp-client in isolation, which is why legacy SDK methods that depend on OperationResult types for OpenAPI-migrated endpoints must remain commented out.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-03-20T13:51:23.302Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts:179-181
Timestamp: 2026-03-20T13:51:23.302Z
Learning: In `apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts`, the truthiness guards `...(integration.avatar && { avatar })`, `...(integration.emoji && { emoji })`, `...(integration.alias && { alias })`, and `...(integration.script && { script })` in the `$set` payload of `updateIncomingIntegration` are intentional. Empty-string values for these fields should NOT overwrite the stored value — only truthy values are persisted. Do not flag these as bugs preventing explicit clears.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-03-12T10:26:26.697Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39340
File: apps/meteor/app/api/server/v1/im.ts:1349-1398
Timestamp: 2026-03-12T10:26:26.697Z
Learning: In `apps/meteor/app/api/server/v1/im.ts` (PR `#39340`), the `DmEndpoints` type intentionally includes temporary stub entries for `/v1/im.kick`, `/v1/dm.kick`, `/v1/im.leave`, and `/v1/dm.leave` (using `DmKickProps` and `DmLeaveProps`) even though no route handlers exist for them yet. These stubs were added to preserve type compatibility after removing the original `DmLeaveProps` and related files. They are planned for cleanup in a follow-up PR. Do not flag these as missing implementations when reviewing this file until the follow-up is merged.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-03-20T13:52:29.575Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/api/server/v1/stats.ts:98-117
Timestamp: 2026-03-20T13:52:29.575Z
Learning: In `apps/meteor/app/api/server/v1/stats.ts`, the `statistics.telemetry` POST endpoint intentionally has no `body` AJV schema in its route options. The proper request body shape (a `params` array of telemetry event objects) has not been formally defined yet, so body validation is deferred to a follow-up. Do not flag the missing body schema for this endpoint during OpenAPI migration reviews.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-02-23T17:53:06.802Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:06.802Z
Learning: During PR reviews that touch endpoint files under apps/meteor/app/api/server/v1, enforce strict scope: if a PR targets a specific endpoint (e.g., rooms.favorite), do not propose changes to unrelated endpoints (e.g., rooms.invite) unless maintainers explicitly request them. Focus feedback on the touched endpoint's behavior, API surface, and related tests; avoid broad cross-endpoint changes in the same PR unless requested.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
  • packages/core-typings/src/ISetting.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.

Applied to files:

  • apps/meteor/app/api/server/v1/settings.ts
  • packages/core-typings/src/ISetting.ts
📚 Learning: 2026-03-04T14:16:49.202Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 39304
File: packages/ui-contexts/src/ActionManagerContext.ts:26-26
Timestamp: 2026-03-04T14:16:49.202Z
Learning: In `packages/ui-contexts/src/ActionManagerContext.ts` (TypeScript, RocketChat/Rocket.Chat), the `disposeView` method in `IActionManager` uses an intentionally explicit union `UiKit.ModalView['id'] | UiKit.BannerView['viewId'] | UiKit.ContextualBarView['id']` to document which view types are accepted, even though all constituents resolve to the same primitive. The inline `// eslint-disable-next-line typescript-eslint/no-duplicate-type-constituents` comment is intentional and should not be flagged or removed.

Applied to files:

  • apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx
🔇 Additional comments (5)
apps/meteor/client/views/admin/settings/Setting/inputs/ActionInputBase.tsx (1)

29-40: LGTM!

The component structure is clean. The button disabling logic and conditional hint rendering are correctly implemented.

apps/meteor/app/api/server/v1/settings.ts (1)

9-9: LGTM!

Import correctly includes the new type guard alongside existing guards.

apps/meteor/client/views/admin/settings/Setting/inputs/ActionSettingInput.tsx (1)

17-23: LGTM!

Clean conditional rendering using the type guard. The type narrowing ensures value.method and value.path are available in the endpoint branch, while value is properly narrowed to keyof ServerMethods in the method branch.

packages/core-typings/src/ISetting.ts (1)

167-168: Type guard implementation is correct.

The guard properly checks for a non-null object with both method and path properties, correctly narrowing the type to SettingActionEndpoint.

apps/meteor/client/views/admin/settings/Setting/inputs/MethodActionInput.tsx (1)

11-14: Type constraint missing: action methods should enforce return type { message: TranslationKey; params?: string[] }.

useMethod returns Promise<ServerMethodReturn<MethodName>>, which is whatever the server method declares. Currently, there's no type-level enforcement that action-type server methods return { message: TranslationKey; params?: string[] }.

Existing methods like OEmbedCacheCleanup and sendSMTPTestEmail do follow this pattern, but new action methods added to ServerMethods could return mismatched shapes (e.g., void, { data: ... }) without triggering a compile error. This creates a silent contract violation risk where the toast handler in ActionInputBase would access undefined properties.

Consider adding a branded type or separate interface for action methods to enforce the contract at the type level.

Comment thread apps/meteor/app/api/server/v1/settings.ts
@dionisio-bot
dionisio-bot Bot added this pull request to the merge queue Mar 31, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Mar 31, 2026
@KevLehman KevLehman removed this from the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot removed the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@KevLehman KevLehman added this to the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot added the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@dionisio-bot
dionisio-bot Bot added this pull request to the merge queue Apr 1, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Apr 1, 2026
@KevLehman KevLehman removed this from the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot removed the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@KevLehman KevLehman added this to the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot added the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@dionisio-bot
dionisio-bot Bot added this pull request to the merge queue Apr 1, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Apr 1, 2026
@KevLehman KevLehman removed this from the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot removed the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@KevLehman KevLehman added this to the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot added the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@dionisio-bot
dionisio-bot Bot added this pull request to the merge queue Apr 1, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Apr 1, 2026
@KevLehman KevLehman removed this from the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot removed the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@KevLehman KevLehman added this to the 8.4.0 milestone Apr 1, 2026
@dionisio-bot dionisio-bot Bot added the stat: ready to merge PR tested and approved waiting for merge label Apr 1, 2026
@dionisio-bot
dionisio-bot Bot added this pull request to the merge queue Apr 1, 2026
Merged via the queue into develop with commit 02b35d5 Apr 1, 2026
45 checks passed
@dionisio-bot
dionisio-bot Bot deleted the chore/setting-action-endpoint branch April 1, 2026 06:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stat: QA assured Means it has been tested and approved by a company insider stat: ready to merge PR tested and approved waiting for merge type: feature Pull requests that introduces new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants