frontend/plugins/content_ui/src/modules/cms/posts/DateCell.tsx (1)

4-6: Use an interface for component props instead of a type alias.

The readonly prop update is good, but this props shape should be declared as an interface to match the repo TS/TSX standard.

♻️ Proposed refactor

-type DateCellProps = {
+interface DateCellProps {
   readonly date: string;
-};
+}

As per coding guidelines, "**/*.{ts,tsx}: ... prefer interfaces over types".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/plugins/content_ui/src/modules/cms/posts/DateCell.tsx` around lines
4 - 6, The prop shape for the DateCell component is declared with a type alias;
update it to an interface to match repository TS/TSX standards by replacing the
`type DateCellProps = { readonly date: string; };` declaration with an
equivalent `interface DateCellProps { readonly date: string; }` and ensure any
usages of DateCellProps (e.g., in the DateCell component signature) remain
unchanged other than the new interface form.

frontend/core-ui/src/modules/products/components/ProductsFilter.tsx (1)

49-53: Minor inconsistency in readonly patterns.

The readonly modifier on props prevents reassignment but doesn't prevent mutation of object properties. Note that SelectCategoriesBadgeProps (line 19) uses Readonly<IProductCategory> which provides deeper immutability, while here you're using readonly category: IProductCategory.

For consistency, consider using Readonly<IProductCategory> here as well if deep immutability is desired:

 interface SelectCategoryProps {
-  readonly category: IProductCategory;
-  readonly selectedCategory?: IProductCategory;
+  readonly category: Readonly<IProductCategory>;
+  readonly selectedCategory?: Readonly<IProductCategory>;
   readonly onSelect: (categoryId: string) => void;
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/core-ui/src/modules/products/components/ProductsFilter.tsx` around
lines 49 - 53, SelectCategoryProps uses shallow readonly on props while
SelectCategoriesBadgeProps uses Readonly<IProductCategory>; update
SelectCategoryProps so category and selectedCategory use
Readonly<IProductCategory> (keep onSelect signature unchanged) to match deep
immutability pattern and maintain consistency with SelectCategoriesBadgeProps
and related components.

frontend/plugins/content_ui/src/modules/cms/shared/EmptyState.tsx (1)

12-20: Good addition of Readonly wrapper for props immutability.

The Readonly type wrapper correctly enforces immutability on the component props, which is a best practice for React components.

Consider extracting the props to a separate interface for better maintainability and alignment with the coding guidelines. As per coding guidelines, "Use functional components with TypeScript interfaces."

♻️ Optional refactor: Extract props to interface

+interface EmptyStateProps {
+  icon?: React.ElementType;
+  title: string;
+  description?: string;
+  actionLabel?: string;
+  onAction?: () => void;
+  className?: string;
+  children?: React.ReactNode;
+}
+
 export function EmptyState({
   icon: Icon,
   title,
   description,
   actionLabel,
   onAction,
   className,
   children,
-}: Readonly<{
-  icon?: React.ElementType;
-  title: string;
-  description?: string;
-  actionLabel?: string;
-  onAction?: () => void;
-  className?: string;
-  children?: React.ReactNode;
-}>) {
+}: Readonly<EmptyStateProps>) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/plugins/content_ui/src/modules/cms/shared/EmptyState.tsx` around
lines 12 - 20, Extract the inline Readonly prop type into a named interface
(e.g. interface EmptyStateProps) containing icon?: React.ElementType, title:
string, description?: string, actionLabel?: string, onAction?: () => void,
className?: string, children?: React.ReactNode, then update the EmptyState
component signature to accept Readonly<EmptyStateProps> (or use
React.FC<Readonly<EmptyStateProps>>) so the component uses the new
EmptyStateProps type instead of the inline type; ensure all references to the
props remain unchanged.

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

164-164: Replace any with Control<TPipelineConfig> for the control prop.

The SortableFieldCardProps interface uses control: any on line 164, losing type inference for Form.Field bindings and path validation. Since TPipelineConfig is already imported and used consistently throughout the component, typing control as Control<TPipelineConfig> enables proper type checking.

♻️ Proposed typing fix

-import { Path, UseFormReturn, useWatch } from 'react-hook-form';
+import { Control, Path, UseFormReturn, useWatch } from 'react-hook-form';
@@
 interface SortableFieldCardProps {
   readonly ticketField: { key: string; label: string; path: string };
-  readonly control: any;
+  readonly control: Control<TPipelineConfig>;
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@frontend/plugins/frontline_ui/src/modules/pipelines/components/configs/components/TicketBasicFields.tsx`
at line 164, The SortableFieldCardProps interface currently types the control
prop as any; change it to Control<TPipelineConfig> so Form.Field bindings and
path validation get proper types—update the control property in the
SortableFieldCardProps interface (referencing SortableFieldCardProps and the
control field) to use the Control generic with the existing TPipelineConfig
import and ensure any usages of control (e.g., in TicketBasicFields component)
still compile with the stricter type.

frontend/plugins/content_ui/src/modules/cms/categories/Categories.tsx (3)

59-59: Use handleAddCategory for consistent state management.

Lines 59 and 85 call setDrawerOpen(true) directly, bypassing the handleAddCategory logic that resets selectedCategory to undefined. This inconsistency could cause bugs where a previously selected category persists when trying to add a new one.

♻️ Proposed fix for consistent handler usage

At line 59:

-      <Button onClick={() => setDrawerOpen(true)}>
+      <Button onClick={handleAddCategory}>

At line 85:

                onAction={() => setDrawerOpen(true)}
+                onAction={handleAddCategory}

Also applies to: 85-85

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/plugins/content_ui/src/modules/cms/categories/Categories.tsx` at
line 59, The Button onClick handlers call setDrawerOpen(true) directly which
bypasses handleAddCategory's logic that clears selectedCategory; update both
Button onClick usages (the one at the top-level Button and the one at line 85)
to call handleAddCategory() instead of setDrawerOpen(true) so selectedCategory
is reset to undefined before opening the drawer and state remains consistent.

---

27-27: Remove unused useEffect.

This effect has an empty body and serves no purpose. It should be removed unless there's a specific reason to keep it (e.g., a planned implementation).

🧹 Proposed cleanup

-  useEffect(() => {}, [location]);
-

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/plugins/content_ui/src/modules/cms/categories/Categories.tsx` at
line 27, Remove the no-op effect in the Categories component: delete the empty
useEffect(() => {}, [location]) call in Categories.tsx (the useEffect import can
also be removed if unused elsewhere) so there is no unused hook referencing
location.

---

115-134: Remove commented-out code.

This large block of commented code should be removed. Version control preserves the history if this implementation needs to be referenced later.

🧹 Proposed cleanup

    </PageContainer>
-    // <div>
-    //   <CategoriesSidebar />
-    //   <CategoriesRecordTable
-    //     key={refetchTrigger}
-    //     clientPortalId={websiteId || ''}
-    //     onEdit={handleEditCategory}
-    //     onRemove={handleRemoveCategory}
-    //     onBulkDelete={handleBulkDelete}
-    //   />
-    //   <CmsCategoryDrawer
-    //     category={selectedCategory}
-    //     isOpen={drawerOpen}
-    //     onClose={() => {
-    //       setDrawerOpen(false);
-    //       setSelectedCategory(undefined);
-    //     }}
-    //     clientPortalId={websiteId || ''}
-    //     onRefetch={refetch}
-    //   />
-    // </div>
  );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/plugins/content_ui/src/modules/cms/categories/Categories.tsx` around
lines 115 - 134, Remove the large commented-out JSX block that contains
CategoriesSidebar, CategoriesRecordTable (with props key={refetchTrigger},
clientPortalId={websiteId || ''}, onEdit={handleEditCategory},
onRemove={handleRemoveCategory}, onBulkDelete={handleBulkDelete}) and
CmsCategoryDrawer (with props category={selectedCategory}, isOpen={drawerOpen},
clientPortalId={websiteId || ''}, onRefetch={refetch}); simply delete that
commented section so the file contains only active code (history is preserved in
VCS).

frontend/plugins/content_ui/src/modules/cms/shared/Cms.tsx (2)

14-17: Consider using absolute imports as per coding guidelines.

The local imports use relative paths (../ and ./), which goes against the project's coding guideline to always use absolute paths when importing.

As per coding guidelines: "Always use absolute paths when importing"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/plugins/content_ui/src/modules/cms/shared/Cms.tsx` around lines 14 -
17, The imports in Cms.tsx use relative paths; update them to use the project's
absolute import aliases instead (replace ../components/websites/WebsiteDrawer,
./CmsLayout, ./EmptyState, and ../graphql/queries with their configured absolute
module paths) so that WebsiteDrawer, CmsLayout, EmptyState, and CONTENT_CMS_LIST
are imported via the project's absolute import root/alias; ensure paths match
the tsconfig/webpack alias and run a quick build to verify no unresolved import
errors.

---

47-47: Consider using explicit types instead of any.

The editingWebsite state and handler parameters use any, which bypasses TypeScript's type safety. Consider using Website | null to leverage the existing Website interface.

🔧 Suggested type improvements

For line 47:

-  const [editingWebsite, setEditingWebsite] = useState<any>(null);
+  const [editingWebsite, setEditingWebsite] = useState<Website | null>(null);

For line 63:

-  const handleEditWebsite = (website: any) => {
+  const handleEditWebsite = (website: Website) => {

For line 68:

-  const handleWebsiteClick = (website: any) => {
+  const handleWebsiteClick = (website: Website) => {

Also applies to: 63-63, 68-68

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/plugins/content_ui/src/modules/cms/shared/Cms.tsx` at line 47,
Replace the use of the any type for the editingWebsite state and its related
handler parameters with the concrete Website type (or Website | null for state)
to restore type safety: change the state declaration editingWebsite /
setEditingWebsite to use Website | null instead of any, and update any functions
referenced in this file that accept or return editingWebsite (e.g., the handlers
where editingWebsite is passed/received on lines around the open/edit/save
handlers) to accept Website (or Website | null where appropriate) rather than
any; ensure imports/types reference the existing Website interface and adjust
null checks accordingly.

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

328-332: Try-catch is unnecessary - getPageAccessTokenFromMap cannot throw.

Looking at getPageAccessTokenFromMap (lines 304-309), it simply returns (pageTokens || {})[pageId] which cannot throw. The catch block is unreachable dead code. While the fix to use e.message instead of an empty error is an improvement in principle, consider removing the unnecessary try-catch:

♻️ Optional: Remove unnecessary try-catch

 export const getPostLink = async (
   pageId: string,
   pageTokens: { [key: string]: string },
   postId: string,
 ) => {
-  let pageAccessToken;
-
-  try {
-    pageAccessToken = getPageAccessTokenFromMap(pageId, pageTokens);
-  } catch (e) {
-    debugError(`Error occurred while getting page access token: ${e.message}`);
-    throw new Error(e.message);
-  }
+  const pageAccessToken = getPageAccessTokenFromMap(pageId, pageTokens);

   try {
     const response: any = await graphRequest.get(

Note: The same pattern exists in getFacebookUser, sendReply, getFacebookUserProfilePic, and other functions - consider cleaning them up as well.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@backend/plugins/frontline_api/src/modules/integrations/facebook/utils.ts`
around lines 328 - 332, The try-catch around calling getPageAccessTokenFromMap
is dead code because getPageAccessTokenFromMap simply returns (pageTokens ||
{})[pageId] and cannot throw; remove the try-catch block and directly assign
pageAccessToken = getPageAccessTokenFromMap(pageId, pageTokens), dropping the
debugError/throw path, and apply the same cleanup to similar patterns in
getFacebookUser, sendReply, getFacebookUserProfilePic (and other functions)
where a non-throwing helper is wrapped in an unnecessary try-catch.

backend/plugins/accounting_api/src/modules/accounting/db/models/AdjustInventories.ts (1)

5-17: Use configured path aliases instead of relative imports

Line 12 and Line 17 use relative imports in a .ts file, which breaks the repo alias convention and makes refactors harder.

♻️ Suggested change

 import {
   ADJ_INV_STATUSES,
   IAdjustInvDetail,
   IAdjustInvDetailDocument,
   IAdjustInvDetailParamsId,
   IAdjustInventory,
   IAdjustInventoryDocument,
-} from '../../@types/adjustInventory';
+} from '~/modules/accounting/@types/adjustInventory';
 import { JOURNALS, TR_SIDES } from '../../@types/constants';
 import {
   adjustInvDetailsSchema,
   adjustInventoriesSchema,
-} from '../definitions/adjustInventory';
+} from '~/modules/accounting/db/definitions/adjustInventory';

As per coding guidelines: **/*.ts: "Use path aliases for imports: ~/* for service root, @/* for modules directory, and erxes-api-shared/* for shared library in backend services".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@backend/plugins/accounting_api/src/modules/accounting/db/models/AdjustInventories.ts`
around lines 5 - 17, The imports for adjustInvDetailsSchema and
adjustInventoriesSchema use relative paths (lines that import from
'../definitions/adjustInventory') which violates the repo alias convention;
update those import statements to use the configured path alias for modules
(e.g. use `@/modules/`... or the project’s configured alias such as `@/`* or ~/* as
appropriate) so that the symbols adjustInvDetailsSchema and
adjustInventoriesSchema are imported via the alias rather than a relative
'../definitions/adjustInventory' path; keep the existing exported symbol names
and only change the module path.

frontend/plugins/content_ui/src/modules/cms/posts/components/add-post-form/hooks/usePostForm.tsx (1)

80-84: Consider extracting the slug utility to a shared module.

The generateSlug implementation is duplicated across usePostForm.tsx, useInlineCategory.ts, useInlineTag.ts, and usePostSubmission.tsx. Consolidating into a single shared utility would reduce maintenance burden and ensure consistent behavior.

The replaceAll usage itself is correct—both regex patterns include the required global flag.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@frontend/plugins/content_ui/src/modules/cms/posts/components/add-post-form/hooks/usePostForm.tsx`
around lines 80 - 84, Extract the duplicated generateSlug function into a single
shared utility (e.g., export a slugify/generateSlug function from a new module)
and replace the local implementations in usePostForm.tsx, useInlineCategory.ts,
useInlineTag.ts, and usePostSubmission.tsx with imports from that shared module;
ensure the exported function preserves the existing behavior and TypeScript
signature (text: string) => string, update all import sites to use the new
utility name (generateSlug or slugify) and remove the local definitions so all
modules use the centralized implementation.

frontend/core-ui/src/modules/client-portal/components/ClientPortalDetailManual.tsx (1)

12-12: Prefer a named props interface instead of inline object typing.

Please extract the inline prop shape into an interface (e.g., interface Props { clientPortal: IClientPortal }) and use Readonly<Props> for consistency with project conventions.

As per coding guidelines, "prefer interfaces over types" and "Use functional components with TypeScript interfaces."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@frontend/core-ui/src/modules/client-portal/components/ClientPortalDetailManual.tsx`
at line 12, The component ClientPortalDetailManual currently uses an inline prop
type Readonly<{ clientPortal: IClientPortal }>; extract that inline shape into a
named interface (e.g., interface Props { clientPortal: IClientPortal }) and
update the component signature to use Readonly<Props> (or Readonly<Props> with
the same destructuring pattern) so the component uses a named TypeScript
interface instead of the inline object type.

frontend/core-ui/src/modules/client-portal/components/ClientPortalDetailToken.tsx (1)

7-7: Use a named props interface for consistency.

Readonly is a good addition, but this should ideally be Readonly<Props> with a dedicated Props interface instead of inline object typing.

As per coding guidelines, "prefer interfaces over types" and "Use functional components with TypeScript interfaces."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@frontend/core-ui/src/modules/client-portal/components/ClientPortalDetailToken.tsx`
at line 7, Replace the inline parameter typing in the ClientPortalDetailToken
component with a named interface: create an interface Props { clientPortal?:
IClientPortal } (prefer interface over type), then update the component
signature to accept Readonly<Props> (or annotate the component as
React.FC<Props>) instead of Readonly<{ clientPortal?: IClientPortal }>; adjust
any imports/exports if needed so ClientPortalDetailToken, Props, and
IClientPortal remain correctly referenced.

backend/plugins/accounting_api/src/modules/accounting/db/models/Accounts.ts (2)

72-74: Use startsWith for the parent-account prefix check.

This is only a literal prefix test. Building a RegExp from parentAccount.code makes regex metacharacters in stored codes affect the match, while startsWith keeps the comparison exact and simpler.

🧹 Simpler prefix check

-        const re = new RegExp(`^${parentAccount.code}.*`);
-        if (!re.test(doc.code)) {
+        if (!doc.code.startsWith(parentAccount.code)) {
           throw new Error('Code is not validate of parent account');
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@backend/plugins/accounting_api/src/modules/accounting/db/models/Accounts.ts`
around lines 72 - 74, The code currently builds a RegExp from parentAccount.code
and tests doc.code with re, which can misinterpret regex metacharacters; replace
that logic by using a literal prefix check: remove the RegExp creation (variable
re) and instead check if doc.code.startsWith(parentAccount.code), throwing the
same Error('Code is not validate of parent account') when the startsWith check
fails so the behavior remains consistent but exact.

---

57-60: Code uses ES2021 API (replaceAll) against ES2017 target baseline.

While tsconfig.base.json declares "lib": ["es2021"] (allowing compile-time use of ES2021 APIs), the target: "es2017" in backend/plugins/accounting_api/tsconfig.json creates a mismatch. To align with the coding guideline (**/*.ts: target ES2017), either confirm the runtime supports ES2021, or use the ES2017-safe regex alternative:

♻️ ES2017-safe alternative

-      doc.code = doc.code
-        .replaceAll('*', '')
-        .replaceAll('_', '')
-        .replaceAll(' ', '');
+      doc.code = doc.code.replace(/[*_ ]/g, '');

Also applies to: 106-109

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@backend/plugins/accounting_api/src/modules/accounting/db/models/Accounts.ts`
around lines 57 - 60, The code in Accounts.ts uses the ES2021 String.replaceAll
API on doc.code which conflicts with the repo target of ES2017; replace the
chained replaceAll calls on doc.code with an ES2017-safe regex replace (e.g. use
String.prototype.replace with a global regex that matches '*', '_' and space
such as /[*_ ]/g and replace with ''), and apply the same change to the other
occurrence referenced around lines 106-109 so all replaceAll uses are converted
to replace(/[*_ ]/g, '').