• X
• Mastodon
• LinkedIn
• Facebook

frontend/plugins/frontline_ui/src/modules/inbox/conversation-messages/components/MessageItem.tsx (1)

182-186: Consider adding image sizing attributes for consistency.

While the responsive constraints are appropriate for a modal image, the coding guidelines recommend including explicit width, height, or sizes attributes for all images.

For dynamic viewport-based sizing, consider:

         <img
           src={readImage(attachment.url)}
           alt={attachment.name}
+          sizes="90vw"
           className="max-w-[90vw] max-h-[90vh] rounded-lg object-contain"
         />

Note: loading="lazy" is intentionally omitted for modal images as they should load immediately when triggered.

As per coding guidelines.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: erxes/erxes PR: 0
File: .cursorrules:0-0
Timestamp: 2025-10-07T04:35:24.836Z
Learning: Applies to **/*.tsx : Implement responsive, mobile-first design with Tailwind CSS

apps/frontline-widgets/src/messengerBundle.js (1)

30-31: Add a safe fallback when primary.DEFAULT is undefined

The launcher style now derives colors from uiOptions.primary:

let { primary: d, logo: h } = c;
const p = d?.DEFAULT;
const L = d?.foreground;
...
background-color: ${p};
color: ${L || "#673fbd"};

If primary.DEFAULT is not set, background-color: ${p} becomes invalid and the launcher background may fall back to transparent. Consider defaulting p similarly to how you default L, for example:

- const p = d?.DEFAULT;
+ const p = d?.DEFAULT || "#673fbd"; // or whatever your existing primary default is

This keeps behavior predictable for integrations that haven’t configured a custom primary yet, while still honoring the new primary shape.

Also applies to: 148-152

apps/frontline-widgets/src/app/messenger/components/conversation.tsx (2)

175-177: Extract duplicate isImageAttachment helper function.

The isImageAttachment function is duplicated in both OperatorMessage (lines 175-177) and CustomerMessage (lines 290-292) with identical implementations. Extract this to a module-level helper to improve maintainability.

Apply this diff to extract the helper:

+const isImageAttachment = (url: string): boolean => {
+  return /\.(jpg|jpeg|png|gif|webp|svg)$/i.test(url);
+};
+
 export function EmptyChat() {

Then remove the local declarations from both components:

 export function OperatorMessage({
   ...
 }) {
-  const isImageAttachment = (url: string) => {
-    return /\.(jpg|jpeg|png|gif|webp|svg)$/i.test(url);
-  };
-
   return (

 export const CustomerMessage = ({
   ...
 }) => {
-  const isImageAttachment = (url: string) => {
-    return /\.(jpg|jpeg|png|gif|webp|svg)$/i.test(url);
-  };
-
   return (

Also applies to: 290-292

---

364-364: Refactor long inline className for maintainability.

The Tooltip.Content className is very long and could be extracted to improve readability and maintainability.

Consider extracting the classes to a constant:

const TOOLTIP_CONTENT_CLASSES = "z-50 overflow-hidden rounded-md bg-foreground px-3 py-1.5 text-xs text-background animate-in fade-in-0 zoom-in-95 data-[state=closed]:animate-out data-[state=closed]:fade-out-0 data-[state=closed]:zoom-out-95 data-[side=bottom]:slide-in-from-top-2 data-[side=left]:slide-in-from-right-2 data-[side=right]:slide-in-from-left-2 data-[side=top]:slide-in-from-bottom-2";

Then use it:

-      <Tooltip.Content className="z-50 overflow-hidden rounded-md bg-foreground px-3 py-1.5 text-xs text-background animate-in fade-in-0 zoom-in-95 data-[state=closed]:animate-out data-[state=closed]:fade-out-0 data-[state=closed]:zoom-out-95 data-[side=bottom]:slide-in-from-top-2 data-[side=left]:slide-in-from-right-2 data-[side=right]:slide-in-from-left-2 data-[side=top]:slide-in-from-bottom-2">
+      <Tooltip.Content className={TOOLTIP_CONTENT_CLASSES}>

apps/frontline-widgets/src/index.ts (2)

256-256: Replace hardcoded fallback color with a constant.

The fallback color '#673fbd' is hardcoded. This should reference a constant from your color definitions for consistency and maintainability.

Based on the related code snippet showing DEFAULT_COLORS in frontend/plugins/frontline_ui/src/modules/integrations/erxes-messenger/constants/emStatesDefaultValues.ts, consider importing and using that constant:

+import { DEFAULT_COLORS } from './path/to/emStatesDefaultValues';
+
 const handleMessageEvent = async (event: MessageEvent) => {
   ...
   (launcherBtn as HTMLElement).style.cssText = `
     ...
-    color: ${foreground || '#673fbd'};
+    color: ${foreground || DEFAULT_COLORS.FOREGROUND};
     ...
   `;

---

258-258: Extract duplicate background size calculation.

The background size logic hasCustomLogo ? '32px' : '18px' is duplicated on lines 258 and 300. Extract this to a helper function or constant to improve maintainability.

Apply this diff to extract the logic:

+const getBackgroundSize = (hasCustomLogo: boolean): string => {
+  return hasCustomLogo ? '32px' : '18px';
+};
+
 const handleMessageEvent = async (event: MessageEvent) => {
   ...
   (launcherBtn as HTMLElement).style.cssText = `
     ...
-    background-size: ${hasCustomLogo ? '32px' : '18px'};
+    background-size: ${getBackgroundSize(hasCustomLogo)};
     ...
   `;
 });

 window.addEventListener('message', async (event) => {
   ...
   (launcher as HTMLElement).style.backgroundSize = hasCustomLogo
-    ? '32px'
-    : '18px';
+    ? getBackgroundSize(hasCustomLogo)
+    : getBackgroundSize(false);

Or simply:

   (launcher as HTMLElement).style.backgroundSize = getBackgroundSize(hasCustomLogo);

Also applies to: 300-300

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/frontline-widgets/src/app/messenger/ticket/types.ts (1)

6-6: Optional: Standardize comment syntax.

The comment syntax //** is non-standard. Consider using // for inline comments.

Apply this diff to standardize the comments:

-  //**customer fields */
+  // customer fields

-  //**company fields */
+  // company fields

Also applies to: 11-11

apps/frontline-widgets/rspack.config.ts (1)

71-77: Verify the CSS rule detection logic.

The toString().includes('css') check could match unintended rules like SCSS, LESS, or any rule containing 'css' in its pattern. Consider a more precise check:

  const cssRuleIndex = config.module.rules.findIndex(
    (rule) =>
      rule &&
      typeof rule === 'object' &&
      rule.test &&
-     rule.test.toString().includes('css'),
+     rule.test instanceof RegExp && rule.test.test('style.css'),
  );

This tests against an actual CSS filename rather than doing string matching on the regex pattern.

apps/frontline-widgets/src/app/messenger/hooks/useConversations.tsx (1)

7-7: Guard localStorage access to keep the hook SSR/test friendly

getLocalStorageItem('customerId') is called unconditionally in the hook body; since it directly uses localStorage, this will throw in SSR or non‑browser test environments where window isn’t available. Consider guarding the read (e.g., checking typeof window !== 'undefined') or moving it into an effect/memo that only runs client‑side.

Also applies to: 18-19, 24-28

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/contact-type/SelectContactType.tsx (1)

7-44: Align value typing and branching with potential future ContactType values

A few small robustness points here:

• SelectContactTypeValue/SelectContactFormItem declare value: ContactType, but the if (!value) branch suggests you expect an “unset” state. Typing these props as ContactType | undefined (and handling undefined explicitly) would avoid casts/unsafe usage from callers.
• The switch (value) in SelectContactTypeValue only covers CUSTOMER and COMPANY with no default. If ContactType is extended later, this component will render nothing for new variants. Either add a default that falls back to the placeholder or make the switch exhaustive.
• In handleValueChange, the else branch resets 'customer' for all non‑CUSTOMER values. If you later introduce additional contact types, it’s safer to branch explicitly on COMPANY vs other future variants so you don’t accidentally reset the wrong field.

These are not blockers but will make the component more future‑proof.

Also applies to: 82-113, 115-119

apps/frontline-widgets/src/lib/formatOnlineHours.ts (1)

19-41: Validate parsed times so bad inputs don’t format as NaN.NaN pm

parseTime only throws when no : is present. If the numeric parts are invalid (e.g., malformed hour/minute), parseInt returns NaN, but the code still flows through to formatTimeTo12Hour, producing strings like NaN.NaN pm instead of hitting the fallback.

You can harden this by validating the parsed numbers:

function parseTime(timeString: string): { hour: number; minute: number } {
  const normalized = timeString.toLowerCase().trim();
  const colonIndex = normalized.indexOf(':');

  if (colonIndex === -1) {
    throw new Error(`Invalid time format: ${timeString}`);
  }

  let hour = parseInt(normalized.substring(0, colonIndex), 10);
  const minute = parseInt(normalized.substring(colonIndex + 1, colonIndex + 3), 10);

+ if (Number.isNaN(hour) || Number.isNaN(minute)) {
+   throw new Error(`Invalid time format: ${timeString}`);
+ }

  const isPM = normalized.includes('pm');
  const isAM = normalized.includes('am');
  ...
}

That way invalid inputs cleanly fall through to the safer fallback string in the catch.

Also applies to: 46-54, 60-109

apps/frontline-widgets/src/app/messenger/ticket/components/ticket.tsx (1)

8-15: Consider making the default case explicit.

The switch statement handles 'submit' explicitly but relies on the default case for 'submissions'. For better code clarity and maintainability, consider adding an explicit case for 'submissions'.

Apply this diff:

  const renderPage = () => {
    switch (page) {
      case 'submit':
        return <TicketForm setPage={setPage} />;
+     case 'submissions':
+       return <TicketSubmissions setPage={setPage} />;
      default:
-       return <TicketSubmissions setPage={setPage} />;
+       return null;
    }
  };

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/PipelineConfigs.tsx (1)

5-10: Refactor: Combine multiple useParams calls.

Two separate useParams calls can be combined into a single call for better performance and cleaner code.

Apply this diff:

- const { id } = useParams<{
-   id: string;
- }>();
- const { pipelineId } = useParams<{
-   pipelineId: string;
- }>();
+ const { id, pipelineId } = useParams<{
+   id: string;
+   pipelineId: string;
+ }>();

backend/plugins/frontline_api/src/modules/inbox/utils.ts (1)

136-144: Consider avoiding mutation of the item parameter.

The function uses Object.assign(document, doc), which mutates item if provided. This side effect could be unexpected for callers.

Apply this diff to make the function pure:

 export const fillSearchTextItem = (
   doc: ITicketWidget,
   item?: ITicketWidget,
 ) => {
-  const document = item || { name: '', description: '' };
-  Object.assign(document, doc);
+  const document = { ...(item || { name: '', description: '' }), ...doc };

   return validSearchText([document.name || '', document.description || '']);
 };

apps/frontline-widgets/src/app/messenger/components/chat-input.tsx (1)

9-9: Consider using a type alias instead of an empty interface.

The empty interface is functionally equivalent to its supertype. While it provides a named extension point, a type alias would be more explicit.

-interface ChatInputProps extends React.InputHTMLAttributes<HTMLInputElement> {}
+type ChatInputProps = React.InputHTMLAttributes<HTMLInputElement>;

frontend/plugins/frontline_ui/src/modules/integrations/erxes-messenger/states/EMSetupSetAtom.ts (1)

45-48: Simplify channelId derivation & double‑check empty‑string fallback

You can avoid allocating an intermediate array when picking the first channel ID, and make the intent a bit clearer:

-      const channelId =
-        payload?.channel?._id ||
-        payload?.channels?.map((channel) => channel._id)?.[0] ||
-        '';
+      const channelId =
+        payload?.channel?._id || payload?.channels?.[0]?._id || '';

Also, confirm that your downstream GraphQL / models treat '' the same way as “no channel” — if they expect null/undefined instead, consider aligning the default here.

Also applies to: 50-55

frontend/plugins/frontline_ui/src/modules/channels/components/settings/Settings.tsx (1)

13-14: Tickets configs route wiring looks consistent; consider fixing “Pipieline” typo

The new FrontlinePaths.TicketsConfigs route and PipielineConfigListPage element are wired the same way as the other settings routes, so behavior-wise this looks good.

Minor nit: PipielineConfigListPage (and the file name) seem to have a “Pipeline” typo. If it’s still easy to change, consider renaming to PipelineConfigListPage across the module tree for readability.

Also applies to: 77-80

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/graphql/queries/getTicketConfigBetPipelineId..ts (1)

1-37: Query is fine; file/symbol naming looks off

The GET_TICKET_CONFIG_BY_PIPELINE_ID query fields are consistent with the ticket config schema and complement the detail query nicely.

Nitpicks:

• The filename getTicketConfigBetPipelineId..ts has both a “Bet” typo and a double dot, which can be confusing and error‑prone in imports.
• The constant name uses BY_PIPELINE_ID while the file uses “Bet”.

If possible, consider renaming the file and normalizing the naming to getTicketConfigByPipelineId.ts / GET_TICKET_CONFIG_BY_PIPELINE_ID throughout.

backend/plugins/frontline_api/src/modules/inbox/graphql/resolvers/mutations/integrations.ts (1)

295-300: New primary field wiring looks correct; consider merge‑vs‑replace behavior

Switching to

const uiOptions = { logo: fields.logo, primary: fields.primary };

is consistent with the new { primary: { DEFAULT, foreground } } shape used on the frontend.

One thing to consider: this unconditionally overwrites both logo and primary. If the client sometimes omits fields.primary or fields.logo, this will store undefined and effectively clear existing values. If you want “partial update” semantics instead, you could merge with the existing integration.uiOptions instead of replacing it wholesale.

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/CreateConfig.tsx (2)

21-62: Strengthen async error handling in onSubmit

Right now:

• confirm(...).then(() => saveTicketsConfig(...)) is wrapped in a try/catch, but any rejection from confirm or errors inside the .then chain won’t be caught there; only a synchronous throw from confirm itself would be.
• In the catch, error.message assumes error is an Error, which may not hold if the codebase uses useUnknownInCatchVariables or if something throws a non‑Error value.

You can make this more robust by keeping the existing onError handler for the mutation and only hardening the catch block:

-      } catch (error) {
-        console.error(error);
-        toast({
-          title: 'Error',
-          description: error.message,
-          variant: 'destructive',
-        });
-      }
+      } catch (error) {
+        console.error(error);
+        const message =
+          error instanceof Error ? error.message : 'Something went wrong';
+        toast({
+          title: 'Error',
+          description: message,
+          variant: 'destructive',
+        });
+      }

Additionally, consider whether you want to explicitly handle cancellation from confirm (e.g., by await‑ing it and returning early on rejection) and include setOpen / confirmationValue in the dependency array to keep exhaustive-deps happy.

---

64-67: Optional UX tweaks: focus timing and reset on cancel

Two small UX nits you might want to consider:

• methods.setFocus('name') runs on mount, regardless of whether the sheet is open. If the sheet can start closed, you may prefer to gate this on open so focus moves when the user opens the create dialog.
• The Cancel button closes the sheet but leaves any partially entered values in the form. If you want a truly “fresh” create each time (which your success path already enforces via reset()), you might also call reset() on cancel.

Both are non‑blocking, just potential polish improvements.

Also applies to: 84-89

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/hooks/usePipelineConfigForm.ts (1)

7-26: Minor cleanup: call useParams once instead of twice

Functionally this works, but you don’t need two separate useParams calls:

-  const { id } = useParams<{ id: string }>();
-  const { pipelineId } = useParams<{ pipelineId: string }>();
+  const { id, pipelineId } = useParams<{ id: string; pipelineId: string }>();

It’s a small thing, but it reduces hooks noise and makes it clearer that both params come from the same route.

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/hooks/useGetTicketConfigByPipelineId.ts (1)

22-25: Consider returning the error state.

The hook currently only returns ticketConfig and loading, but not the error state from the query. Returning the error would allow consuming components to handle query failures.

Apply this diff to expose the error state:

-  const { data, loading } = useQuery<ITicketConfigResponse>(
+  const { data, loading, error } = useQuery<ITicketConfigResponse>(
     GET_TICKET_CONFIG_BY_PIPELINE_ID,
     {
       variables: { pipelineId },
       ...options,
       skip: !pipelineId,
     },
   );
   return {
     ticketConfig: data?.ticketConfig,
     loading,
+    error,
   };

backend/plugins/frontline_api/src/modules/inbox/graphql/resolvers/queries/widget.ts (1)

271-289: Remove or use the unused type parameter.

The type parameter is declared in the function signature but never used in the resolver implementation. If it's intended for future use or filtering logic, consider adding a TODO comment. Otherwise, remove it to avoid confusion.

If the parameter is not needed, apply this diff:

   async widgetsTicketCustomerDetail(
     _root,
-    args: { customerId?: string; type?: string },
+    args: { customerId?: string },
     { subdomain }: IContext,
   ) {

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/hooks/useGetTicketConfigDetail.ts (1)

1-20: Consider exposing error from useGetTicketConfigDetail

The hook currently hides GraphQL errors, which can make consumers fall back to undefined data without any signal. Returning error as well would give callers the option to render an error state.

-  const { data, loading } = useQuery<ITicketConfigDetailResponse>(
+  const { data, loading, error } = useQuery<ITicketConfigDetailResponse>(
     GET_CONFIG_DETAIL,
     options,
   );
   return {
     ticketConfigDetail: data?.ticketConfigDetail,
-    loading,
+    loading,
+    error,
   };

apps/frontline-widgets/src/app/messenger/states/index.ts (1)

5-7: Avoid drifting default primary colors between admin and widget

uiOptionsAtom hard‑codes '#000' / '#fff' for primary.DEFAULT and primary.foreground, while the admin side uses DEFAULT_COLORS. If these ever change, the two surfaces could get out of sync. When feasible, consider sharing a single source of truth for these defaults (or at least co-locating the constants in a shared package).

Also applies to: 23-29, 31-32

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/ConfigDetails.tsx (1)

38-78: Refactor onSubmit to handle async errors correctly

Wrapping confirm(...).then(...) in a try/catch will not catch async rejections from confirm or the mutation; only synchronous errors before the Promise is created are caught. To avoid potential unhandled rejections and make error handling clearer, it’s safer to use async/await (or explicitly handle .catch on the Promise):

-  const onSubmit: SubmitHandler<TPipelineConfig> = useCallback(
-    (data) => {
-      try {
-        confirm({
-          message: 'Are you sure you want to save the tickets config?',
-          options: {
-            confirmationValue,
-          },
-        }).then(() => {
-          saveTicketsConfig({
-            variables: {
-              input: data,
-            },
-            onCompleted: () => {
-              toast({
-                title: 'Success',
-                description: 'Tickets config saved successfully',
-                variant: 'success',
-              });
-              handleClose();
-            },
-            onError: (error) => {
-              toast({
-                title: 'Error',
-                description: error.message,
-                variant: 'destructive',
-              });
-            },
-          });
-        });
-      } catch (error) {
-        toast({
-          title: 'Error',
-          description:
-            error instanceof Error ? error.message : 'An error occurred',
-          variant: 'destructive',
-        });
-      }
-    },
-    [saveTicketsConfig, confirm, handleClose],
-  );
+  const onSubmit: SubmitHandler<TPipelineConfig> = useCallback(
+    async (data) => {
+      try {
+        await confirm({
+          message: 'Are you sure you want to save the tickets config?',
+          options: { confirmationValue },
+        });
+
+        await saveTicketsConfig({
+          variables: { input: data },
+          onCompleted: () => {
+            toast({
+              title: 'Success',
+              description: 'Tickets config saved successfully',
+              variant: 'success',
+            });
+            handleClose();
+          },
+          onError: (error) => {
+            toast({
+              title: 'Error',
+              description: error.message,
+              variant: 'destructive',
+            });
+          },
+        });
+      } catch (error) {
+        // Optionally ignore expected cancellation from confirm if it rejects on cancel
+        if (error instanceof Error) {
+          toast({
+            title: 'Error',
+            description: error.message,
+            variant: 'destructive',
+          });
+        }
+      }
+    },
+    [saveTicketsConfig, confirm, handleClose],
+  );

This makes it explicit which async paths are handled and prevents silent unhandled Promise rejections if confirm ever rejects.

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/CompanyFields.tsx (1)

18-107: Company field toggles are wired correctly; consider namespacing id attributes

Implementation and bindings look good. To avoid duplicate DOM IDs when used alongside other field groups (e.g., a CustomerFields component with similar switches), consider prefixing these id/htmlFor values (e.g., company-isShowName, company-isShowEmail, etc.) so labels always target the intended control.

backend/plugins/frontline_api/src/modules/inbox/graphql/schemas/integration.ts (1)

48-61: Align ticketConfigId GraphQL type with its intended usage

Integration.ticketConfigId is exposed as JSON, while integrationsSaveMessengerTicketData accepts a configId: String!. Since this field semantically represents a single config ID, consider changing ticketConfigId to String (or a dedicated ID scalar) instead of JSON to improve schema clarity and type-safety and keep it consistent with the mutation parameter.

Also applies to: 281-283

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/CustomerFields.tsx (1)

17-89: Switches should guard against undefined field.value

The structure looks good and is consistent with RHF usage, but checked={field.value as boolean} can still pass undefined at runtime if the form never sets an initial value for these fields. To avoid uncontrolled/controlled warnings and subtle bugs, it’s safer to coerce:

- checked={field.value as boolean}
+ checked={!!field.value}

You can apply the same pattern to all four switches.

backend/plugins/frontline_api/src/modules/ticket/graphql/schemas/ticketConfig.ts (1)

24-36: Align TicketConfig id field naming with the rest of the schema

TicketConfig exposes id: ID!, but the detail query takes _id: String!:

type TicketConfig {
  id: ID!
  ...
}

type Query {
  ticketConfigDetail(_id: String!): TicketConfig
}

Given most of the schema uses _id as the field name, please double‑check that:

• Resolvers correctly map the underlying Mongo _id to the GraphQL id field; or
• You rename the GraphQL field to _id for consistency:

- type TicketConfig {
-   id: ID!
+ type TicketConfig {
+   _id: ID!

Either way, ensuring a consistent id naming convention across types and queries will make the API easier to consume and avoid confusion.

Also applies to: 60-69, 72-81

backend/plugins/frontline_api/src/modules/inbox/graphql/schemas/widget.ts (1)

3-12: Consider tightening nullability of new ticket widget fields and arguments

The new schema pieces look coherent with the wider ticket config work:

• MessengerConnectResponse.ticketConfig: JSON for returning config to the widget.
• widgetsTicketCustomerDetail(customerId: String, type: String): Customer
• widgetsTicketCustomersEdit(...) and widgetTicketCreated(...) mutations.

A couple of small schema improvements to consider:

• If customerId is always required to resolve a single customer or edit one, prefer marking it non‑null:

- widgetsTicketCustomerDetail(customerId: String, type: String): Customer
+ widgetsTicketCustomerDetail(customerId: String!, type: String): Customer

- widgetsTicketCustomersEdit(customerId: String, firstName: String, lastName: String, emails: [String], phones: [String]): Customer
+ widgetsTicketCustomersEdit(customerId: String!, firstName: String, lastName: String, emails: [String!], phones: [String!]): Customer

• Similarly, if type is mandatory in any of these operations, make it String! to push validation into GraphQL instead of the resolver.

This will give clients earlier feedback on bad inputs and simplify resolver logic.

Also applies to: 48-59, 61-129

frontend/plugins/frontline_ui/src/modules/integrations/erxes-messenger/components/EMConfig.tsx (1)

45-52: Create/edit branching looks good; verify loading covers ticket config save

The new edit mode wiring (idToEdit + isEditMode and branching to editMessenger vs createMessenger) is clear and keeps the reset behavior consistent for both paths. One thing to double‑check against the hooks:

• In useCreateMessenger / useEditMessenger you also call saveTicketConfigMutation, but the returned loading currently only ORs together the base mutation + configs + appearance loading, not saveTicketConfigLoading (per the snippets).
• Here, const loading = createLoading || editLoading; means the Save button can re‑enable while the ticket config mutation is still in flight.

It may be worth including saveTicketConfigLoading inside those hooks’ aggregated loading, so EMConfig’s loading reflects the full operation lifecycle and avoids double submissions or premature navigation.

Also applies to: 61-74, 81-85

apps/frontline-widgets/src/app/messenger/components/conversation.tsx (2)

182-275: Consider replacing Button wrapper with a non-interactive container

OperatorMessage uses Button purely as a layout wrapper and tooltip trigger, while its children include interactive <a> elements for attachments. This yields invalid HTML (interactive inside interactive) and can cause quirky focus/hover behavior. Since there’s no onClick on the Button, you can safely switch it to a div (still wrapped by Tooltip.Trigger asChild) with the same classes.

---

199-212: Reduce duplication across message bubbles and tooltips

The content bubble styles and tooltip content classes are virtually identical between OperatorMessage and CustomerMessage, and isImageAttachment is redefined in both components. Extracting a small shared helper (for isImageAttachment) and a shared tooltipContentClassName constant (or wrapper component) would keep these layouts in sync and simplify future adjustments.

Also applies to: 292-295, 304-309, 366-368

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/ConfigList.tsx (1)

24-48: ConfigList flow and empty state handling look good

Loading, single-config display, and the “Add Configuration” fallback are wired cleanly. If you want to harden things further, you could guard onRemove against a missing id instead of passing '', but functionally this looks fine.

Also applies to: 72-143

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/hooks/useGetTicketConfigs.ts (1)

16-33: Hook behavior is correct; consider a couple of ergonomic tweaks

The effectiveChannelId resolution and skip handling look good. For easier consumers, you might:

• Default ticketConfigs to an empty array to avoid undefined checks:

  ticketConfigs: data?.ticketConfigs ?? [],

• Optionally type QueryHookOptions<IConfigResponse, { channelId: string }> so callers get proper autocomplete on variables.channelId.

Both are optional, but would make the hook a bit nicer to use.

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/ConfigsForm.tsx (1)

86-157: Coerce Switch values to boolean to avoid uncontrolled state edge cases

For the ticketBasicFields.* toggles, checked={field.value as boolean} will pass through undefined if the form isn’t initialized with explicit booleans, which can lead to React controlled/uncontrolled warnings or ambiguous UI.

You can harden this by coercing to a boolean:

- checked={field.value as boolean}
+ checked={!!field.value}

Apply similarly to all four switches.

apps/frontline-widgets/src/app/messenger/types/connection.ts (1)

92-126: Ticket config field types are reasonable; consider tightening contactType

The ticket config-related interfaces mirror the backend schema well (ticketBasicFields, company, customer, etc.). One small improvement: contactType is currently string even though the schema only allows 'customer' | 'company'. Narrowing this to a union would catch invalid values at compile time:

export interface ITicketConfig {
  ...
- contactType: string;
+ contactType: 'customer' | 'company';
  ...
}

Not blocking, but it would improve type safety.

apps/frontline-widgets/src/messengerBundle.js (2)

18-33: Launcher shadow change is fine; consider cleaning up commented filter later

Switching from filter: drop-shadow(...) to an explicit box-shadow on .erxes-launcher is straightforward and should be more predictable across browsers. Once you’re confident in the new look, you can drop the commented-out filter to reduce noise.

---

123-153: Add safe fallbacks when uiOptions.primary is missing

The launcher style now uses:

let { primary: d, logo: h } = c,
  r = h,
  p = d == null ? void 0 : d.DEFAULT,
  L = d == null ? void 0 : d.foreground;
...
o.style.cssText = `
  ...
  background-color: ${p};
  color: ${L || "#673fbd"};
  background-image: ${x};
  background-size: ${A ? "32px" : "18px"};
  ...
`;

If primary is undefined (e.g., older integrations that still have color/textColor only), p becomes undefined, resulting in background-color: undefined and relying entirely on browser defaults.

Consider adding explicit defaults:

const defaultBg = "#673fbd";
const defaultFg = "#ffffff";

let { primary: d, logo: h } = c,
  r = h,
  p = (d && d.DEFAULT) || defaultBg,
  L = (d && d.foreground) || defaultFg;

This keeps the launcher readable even when primary isn’t configured.

backend/plugins/frontline_api/src/modules/inbox/graphql/resolvers/mutations/widget.ts (1)

1036-1075: widgetTicketCreated logic is sound; consider minor cleanups

The mutation correctly:

• Validates statusId and derives pipeline from it.
• Normalizes customerIds by fetching existing customers and using only valid IDs.
• Uses fillSearchTextItem(doc) to build searchText.

A couple of small points you may want to revisit:

• The type field is destructured but never used. If Ticket documents need it, add it to the create payload; otherwise, consider dropping it from ITicketWidget and the client mutation inputs.
• Since pipelineId and channelId are derived from status, you might want to omit them from the input type entirely to avoid confusion (they’re currently in restFields but overridden in the payload).

These are non-blocking polish items.

frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/SelectTicketConfig.tsx (3)

46-57: Consider exposing query errors to consumers.

The context type includes an error field (line 10), but it's not being extracted from useGetTicketConfigs or passed to the context provider. If the query fails, consumers won't be able to display error states.

Apply this diff to expose the error:

- const { ticketConfigs, loading } = useGetTicketConfigs({
+ const { ticketConfigs, loading, error } = useGetTicketConfigs({
    variables: { channelId: effectiveChannelId as string },
    skip: !effectiveChannelId,
  });
  return (
    <SelectTicketConfigContext.Provider
      value={{
        value: value || '',
        onValueChange: handleValueChange,
        configs: ticketConfigs,
        loading,
+       error,
        channelId: effectiveChannelId,
      }}
    >

---

177-178: Consider extracting the channelId resolution logic.

The same useParams and channelId fallback logic appears here and in SelectTicketConfigProvider (lines 39-40). Since both SelectTicketConfigRoot and SelectTicketConfigFormItem wrap the Provider, this logic is duplicated.

Consider extracting to a custom hook:

const useEffectiveChannelId = (channelId?: string) => {
  const { id: routeChannelId } = useParams<{ id: string }>();
  return channelId || routeChannelId;
};

Then use it in both SelectTicketConfigProvider (removing lines 39-40) and here.

---

204-209: Object.assign pattern works but has type safety limitations.

The Object.assign pattern for compound components is functional but doesn't provide TypeScript type hints for the attached properties (Provider, Value, etc.). Consider an explicit type definition if consumers need autocomplete.

Example alternative:

interface SelectTicketConfigComponent {
  (props: Parameters<typeof SelectTicketConfigRoot>[0]): ReturnType<typeof SelectTicketConfigRoot>;
  Provider: typeof SelectTicketConfigProvider;
  Value: typeof SelectTicketConfigValue;
  Content: typeof SelectTicketConfigContent;
  FormItem: typeof SelectTicketConfigFormItem;
}

export const SelectTicketConfig = Object.assign(
  SelectTicketConfigRoot,
  {
    Provider: SelectTicketConfigProvider,
    Value: SelectTicketConfigValue,
    Content: SelectTicketConfigContent,
    FormItem: SelectTicketConfigFormItem,
  }
) as SelectTicketConfigComponent;

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro