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

1-5: Consider adding as const for stricter type safety.

Adding as const preserves literal types instead of widening to string, which improves type inference when these values are used elsewhere (e.g., in discriminated unions or type guards). Also, the indentation is inconsistent (4 spaces for properties vs 2 spaces for closing brace).

♻️ Suggested improvement

-export const MODULE_NAMES = {
-    KB_TOPIC: 'knowledgeBaseTopic',
-    KB_CATEGORY: 'knowledgeBaseCategory',
-    KB_ARTICLE: 'knowledgeBaseArticle',
-  };
+export const MODULE_NAMES = {
+  KB_TOPIC: 'knowledgeBaseTopic',
+  KB_CATEGORY: 'knowledgeBaseCategory',
+  KB_ARTICLE: 'knowledgeBaseArticle',
+} as const;

backend/plugins/frontline_api/src/modules/knowledgebase/@types/category.ts (1)

5-12: Consider making title required.

All fields in ICategory are optional, which may allow creating categories without essential data. Typically, title would be a required field for a category entity.

Suggested change

 export interface ICategory {
-    title?: string;
+    title: string;
     description?: string;
     articleIds?: string[];
     icon?: string;
     parentCategoryId?: string;
     topicId?: string;
   }

backend/plugins/frontline_api/src/modules/knowledgebase/@types/topic.ts (1)

4-14: Duplicate code field and consider making title required.

1. The code field is already defined in ICommonFields (which ITopicDocument extends), creating redundancy.
2. Similar to ICategory, consider whether title should be required.

Suggested change

 export interface ITopic {
-    title?: string;
-    code?: string;
+    title: string;
     description?: string;
     brandId?: string;
     categoryIds?: string[];
     color?: string;
     backgroundImage?: string;
     languageCode?: string;
     notificationSegmentId?: string;
   }

backend/plugins/frontline_api/src/apollo/typeDefs.ts (1)

18-19: Minor: Trailing blank lines added.

These trailing blank lines don't affect functionality. Consider removing if not required by formatting rules.

backend/plugins/frontline_api/src/apollo/schema/schema.ts (1)

88-92: Missing semicolon at end of import statement.

The import statement is missing a trailing semicolon, which is inconsistent with other imports in this file.

🔧 Suggested fix

 import {
   queries as KnowledgeBaseQueries,
   mutations as KnowledgeBaseMutations,
   types as KnowledgeBaseTypes,
-} from '@/knowledgebase/graphql/schemas/knowledgeBaseTypeDefs'
+} from '@/knowledgebase/graphql/schemas/knowledgeBaseTypeDefs';

backend/plugins/frontline_api/src/apollo/resolvers/mutations.ts (1)

14-14: Missing semicolon at end of import statement.

Inconsistent with other imports in this file.

🔧 Suggested fix

-import { knowledgeBaseMutations } from '@/knowledgebase/graphql/resolvers/mutations/knowledgeBaseMutations'
+import { knowledgeBaseMutations } from '@/knowledgebase/graphql/resolvers/mutations/knowledgeBaseMutations';

backend/plugins/frontline_api/src/apollo/resolvers/queries.ts (1)

16-16: Missing semicolon at end of import statement.

Inconsistent with other imports in this file.

🔧 Suggested fix

-import { knowledgeBaseQueries } from '@/knowledgebase/graphql/resolvers/queries/knowledgeBaseQueries'
+import { knowledgeBaseQueries } from '@/knowledgebase/graphql/resolvers/queries/knowledgeBaseQueries';

backend/plugins/frontline_api/src/modules/knowledgebase/db/definitions/topic.ts (1)

35-36: Minor: Remove unnecessary blank lines.

There are extra blank lines that could be cleaned up for consistency.

🔧 Suggested fix

       notificationSegmentId: field({
         type: String,
         required: false,
       }),
-  
-      
-  
       ...commonFields,
     }),
   );

backend/plugins/frontline_api/src/modules/knowledgebase/db/definitions/article.ts (2)

1-4: Inconsistent import path aliases.

The file mixes ~/ (line 1) and @/ (line 2) path aliases. This inconsistency can cause confusion and maintenance issues. Standardize on one alias pattern.

Proposed fix

 import { field } from '~/modules/knowledgebase/db/utils';
-import { PUBLISH_STATUSES, commonFields } from '@/knowledgebase/db/definitions/constant'
+import { PUBLISH_STATUSES, commonFields } from '~/modules/knowledgebase/db/definitions/constant';
 import { Schema } from 'mongoose';
-import { attachmentSchema } from 'erxes-api-shared/core-modules';
+import { attachmentSchema } from 'erxes-api-shared/core-modules';

---

51-51: Minor formatting: missing space after colon.

-    publishedUserId:field({ type: String, optional: true, label: 'Published user'}),
+    publishedUserId: field({ type: String, optional: true, label: 'Published user' }),

backend/plugins/frontline_api/src/modules/knowledgebase/graphql/resolvers/customResolvers/article.ts (1)

1-2: Inconsistent import path aliases.

Same issue as other files - mixing @/ and ~/ aliases. Standardize for consistency.

-import { IArticleDocument } from '@/knowledgebase/@types/article';
-import { IContext } from '~/connectionResolvers'
+import { IArticleDocument } from '~/modules/knowledgebase/@types/article';
+import { IContext } from '~/connectionResolvers';

backend/plugins/frontline_api/src/modules/knowledgebase/graphql/resolvers/mutations/knowledgeBaseMutations.ts (3)

35-35: Stray semicolon on empty line.

This appears to be a leftover artifact.

-;

---

103-109: Consider extracting duplicated scheduled date validation.

The same validation logic for scheduled articles is repeated in both Add and Edit mutations.

Example extraction

function validateScheduledArticle(doc: IArticleCreate): void {
  if (doc.status === 'scheduled' && !doc.scheduledDate) {
    throw new Error('Scheduled Date must be supplied');
  }
  if (doc.status === 'scheduled' && doc.scheduledDate && doc.scheduledDate < new Date()) {
    throw new Error('Scheduled Date can not be in the past!');
  }
}

Then use validateScheduledArticle(doc) in both mutations.

Also applies to: 126-132

---

28-28: Unused fetch results - clarify intent with comments or remove.

Several mutations fetch entities (e.g., getTopic, getCategory, getArticle) but don't use the result. If this is for existence validation (throwing if not found), consider adding a brief comment to clarify intent, or use a dedicated exists check.

Also applies to: 45-45, 71-71, 86-86, 124-124, 149-149

backend/plugins/frontline_api/src/modules/knowledgebase/db/definitions/constant.ts (1)

12-19: Consider making createdBy and modifiedBy optional to prevent validation errors.

The field utility applies /\S+/ validation to non-optional String fields. While current code enforces userId through createDoc/updateDoc methods, making these fields optional adds defensive protection against bypassing those methods or future use of direct model creation.

backend/plugins/frontline_api/src/modules/knowledgebase/graphql/schemas/knowledgeBaseTypeDefs.ts (3)

35-36: Minor formatting inconsistency: missing spaces before colons.

For consistency with the rest of the schema, add spaces before the colons.

-    publishedUserId:String
-    publishedUser:User
+    publishedUserId: String
+    publishedUser: User

---

77-77: Minor formatting: missing space before colon.

-      countArticles:Int
+      countArticles: Int

---

151-156: Inconsistent spacing in query parameters.

For readability and consistency, add spaces after colons in parameter definitions.

-    knowledgeBaseCategories(page: Int, perPage: Int, ids:[String], topicIds: [String], codes: [String],icon:String): [KnowledgeBaseCategory]
+    knowledgeBaseCategories(page: Int, perPage: Int, ids: [String], topicIds: [String], codes: [String], icon: String): [KnowledgeBaseCategory]
...
-    knowledgeBaseArticles(searchValue: String, page: Int, perPage: Int, categoryIds: [String],articleIds:[String], codes: [String], topicIds: [String], sortField:String, sortDirection: Int, status: String): [KnowledgeBaseArticle]
+    knowledgeBaseArticles(searchValue: String, page: Int, perPage: Int, categoryIds: [String], articleIds: [String], codes: [String], topicIds: [String], sortField: String, sortDirection: Int, status: String): [KnowledgeBaseArticle]

backend/plugins/frontline_api/src/modules/knowledgebase/@types/article.ts (2)

5-8: Consider exporting IFormCodes interface.

This interface might be needed by other modules (e.g., for type-checking form code inputs in mutations). If it's only used internally, this is fine, but exporting it would improve reusability.

♻️ Proposed change

-interface IFormCodes {
+export interface IFormCodes {
     brandId: string;
     formId: string;
 }

---

30-32: Fix indentation for _id field.

The _id field has inconsistent indentation compared to the rest of the codebase.

♻️ Proposed fix

 export interface IArticleDocument extends ICommonFields, IArticle, Document {
-_id: string;
+  _id: string;
 }

backend/plugins/frontline_api/src/modules/knowledgebase/db/models/Topic.ts (2)

31-42: createDoc signature allows optional userId but throws if not provided.

The method signature declares userId as optional (userId?: string), but the implementation immediately throws if it's not supplied. Consider making userId required in the signature to provide better type safety and clearer API expectations.

♻️ Proposed change in interface

-    createDoc(docFields: ITopic, userId?: string): Promise<ITopicDocument>;
+    createDoc(docFields: ITopic, userId: string): Promise<ITopicDocument>;

And in the implementation:

-      public static createDoc(docFields: ITopic, userId?: string) {
-        if (!userId) {
-          throw new Error('userId must be supplied');
-        }
+      public static createDoc(docFields: ITopic, userId: string) {

---

44-51: Same issue: updateDoc allows optional userId but throws if not provided.

Apply the same fix as createDoc - make userId required in both the interface and implementation.

backend/plugins/frontline_api/src/modules/knowledgebase/db/models/Category.ts (1)

1-2: Consolidate imports from the same module.

♻️ Suggested refactor

-import { ICategoryDocument } from '../../@types/category';
-import { ICategory } from '../../@types/category';
+import { ICategory, ICategoryDocument } from '../../@types/category';

backend/plugins/frontline_api/src/modules/knowledgebase/db/models/Article.ts (2)

74-78: Redundant null check — getArticle already throws if not found.

The getArticle method throws an error when the article is not found, making the subsequent if(!article) check unreachable.

♻️ Proposed fix

       public static async updateDoc(
         _id: string,
         docFields: IArticleCreate,
         userId?: string
       ) {
         if (!userId) {
           throw new Error('userId must be supplied');
         }
         const article = await models.Article.getArticle(_id);
-
-        if(!article){
-          throw new Error('Article not found')
-        }
 
         const doc = {

---

110-118: Reaction count can go negative if decrementing below zero.

Consider adding a floor check to prevent negative counts.

♻️ Proposed fix

         const reactionCounts = article.reactionCounts || {};
 
-        reactionCounts[reactionChoice] =
-          (reactionCounts[reactionChoice] || 0) + (modifyType === 'inc' ? 1 : -1);
+        const currentCount = reactionCounts[reactionChoice] || 0;
+        reactionCounts[reactionChoice] = Math.max(0, currentCount + (modifyType === 'inc' ? 1 : -1));
 
         await models.Article.updateOne(

backend/plugins/frontline_api/src/modules/knowledgebase/graphql/resolvers/queries/knowledgeBaseQueries.ts (2)

14-18: Fragile string manipulation for field name mapping.

key.replace('s', '') relies on the assumption that removing the first 's' produces the correct field name. This works for the current keys but is unclear and error-prone for future additions.

♻️ Proposed fix — use explicit mapping

-const buildQuery = (args: any) => {
+const buildQuery = (args: any) => {
   const qry: any = {};
 
-  const keys = ['codes', 'categoryIds', 'articleIds', 'topicIds'];
+  const keyToField: Record<string, string> = {
+    codes: 'code',
+    categoryIds: 'categoryId',
+    articleIds: 'articleId',
+    topicIds: 'topicId',
+  };
 
-  keys.forEach((key) => {
+  Object.entries(keyToField).forEach(([key, field]) => {
     if (args[key] && args[key].length > 0) {
-      const field = key.replace('s', '');
       qry[field] = { $in: args[key] };
     }
   });

---

21-27: Unescaped regex input may cause unexpected matches or ReDoS.

User-supplied searchValue is interpolated directly into a regex pattern. Special regex characters (e.g., ., *, +) will be interpreted as regex operators rather than literals.

♻️ Proposed fix — escape special characters

+const escapeRegex = (str: string) => str.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+
 const buildQuery = (args: any) => {
   // ...
   if (args.searchValue && args.searchValue.trim()) {
+    const escaped = escapeRegex(args.searchValue.trim());
     qry.$or = [
-      { title: { $regex: `.*${args.searchValue.trim()}.*`, $options: 'i' } },
-      { content: { $regex: `.*${args.searchValue.trim()}.*`, $options: 'i' } },
-      { summary: { $regex: `.*${args.searchValue.trim()}.*`, $options: 'i' } },
+      { title: { $regex: escaped, $options: 'i' } },
+      { content: { $regex: escaped, $options: 'i' } },
+      { summary: { $regex: escaped, $options: 'i' } },
     ];
   }

Note: The .* wrappers are also unnecessary since regex already matches substrings by default.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

backend/plugins/frontline_api/src/modules/integrations/instagram/@types/conversationMessages.ts (1)

10-10: Consider replacing any with more specific types.

Using any for attachments and botData reduces type safety. Consider defining proper interfaces or at least using unknown or a more specific type like Record<string, unknown> to maintain type checking.

♻️ Suggested improvement

-    attachments?: any;
+    attachments?: IAttachment[];

-    botData?: any;
+    botData?: Record<string, unknown>;

You may want to define an IAttachment interface based on the expected attachment structure.

Also applies to: 18-18

backend/plugins/frontline_api/src/modules/integrations/instagram/@types/conversations.ts (1)

1-1: Remove unused Schema import.

Schema is imported but never used in this file.

Suggested fix

-import { Document, Schema } from 'mongoose';
+import { Document } from 'mongoose';

backend/plugins/frontline_api/src/modules/integrations/instagram/@types/logs.ts (1)

3-14: Consider replacing any with more specific types or unknown.

Using any for value and specialValue bypasses TypeScript's type checking. If the structure of these fields is truly unknown at compile time, prefer unknown to enforce explicit type narrowing before use. If there are known shapes, consider a union type or generic.

♻️ Suggested improvement

 export interface ILog {
     type: string;
-    value: any;
-    specialValue: any;
+    value: unknown;
+    specialValue: unknown;
     createdAt: Date;
   }
   
   export interface ILogInput {
     type: string;
-    value: any;
-    specialValue: any;
+    value: unknown;
+    specialValue: unknown;
   }

backend/plugins/frontline_api/src/modules/knowledgebase/db/definitions/article.ts (2)

39-39: Consider using Schema.Types.Mixed or a Map schema for reactionCounts.

Using { type: Object } bypasses Mongoose's schema validation. For dynamic key-value data like reaction counts, prefer:

♻️ Suggested refactor

-    reactionCounts: { type: Object }, 
+    reactionCounts: { type: Map, of: Number, default: new Map() },

---

45-45: Consider using attachmentSchema for pdfAttachment for consistency.

The pdfAttachment field uses { type: Object } which bypasses schema validation. Since attachmentSchema is already imported and used for image and attachments, using it here ensures consistent structure and validation.

♻️ Suggested refactor

-    pdfAttachment: { type: Object }, 
+    pdfAttachment: { type: attachmentSchema },

backend/plugins/frontline_api/src/modules/integrations/instagram/@types/comment_conversations_reply.ts (1)

15-15: Consider replacing any with a more specific type.

Using any bypasses type safety. If the attachment structure is known, define an interface. If it's truly dynamic, consider unknown or Record<string, unknown>[] as safer alternatives.

backend/plugins/frontline_api/src/modules/integrations/instagram/@types/utils.ts (1)

22-25: Add type annotation for schema parameter.

The schema parameter should be typed. Since this is a Mongoose schema utility, consider using the appropriate Mongoose type.

♻️ Suggested fix

+import { Schema } from 'mongoose';
+
-export const schemaWrapper = schema => {
+export const schemaWrapper = <T>(schema: Schema<T>): Schema<T> => {
   schema.add({ scopeBrandIds: [String] });
   return schema;
 };

backend/plugins/frontline_api/src/modules/integrations/instagram/@types/comment_conversations.ts (1)

17-21: isResolved should be typed as boolean.

The field name clearly indicates a boolean state (resolved vs unresolved). Using any loses type safety unnecessarily.

♻️ Suggested fix

 export interface ICommentConversationDocument
   extends ICommentConversation,
     Document {
-  isResolved: any;
+  isResolved: boolean;
 }

backend/plugins/frontline_api/src/modules/knowledgebase/graphql/resolvers/mutations/knowledgeBaseMutations.ts (5)

10-21: Unused subdomain parameter and fetch-only variables.

subdomain is destructured but unused in knowledgeBaseTopicsAdd and knowledgeBaseTopicsRemove. The topic variable on line 45 is also unused. Per coding guidelines, avoid unnecessary declarations.

♻️ Proposed fix

   async knowledgeBaseTopicsAdd(
     _root,
     { doc }: { doc: ITopic },
-    { user, models, subdomain }: IContext
+    { user, models }: IContext
   ) {

   async knowledgeBaseTopicsRemove(
     _root,
     { _id }: { _id: string },
-    { user, models, subdomain }: IContext
+    { models }: IContext
   ) {
-    const topic = await models.Topic.getTopic(_id);
+    await models.Topic.getTopic(_id);
     const removed = await models.Topic.removeDoc(_id);

Also applies to: 40-50

---

52-79: Unused subdomain and kbCategory variables in category mutations.

Same pattern as Topic mutations: subdomain is destructured but unused, and kbCategory on line 71 is fetched but only used for existence validation.

♻️ Proposed fix

   async knowledgeBaseCategoriesAdd(
     _root,
     { doc }: { doc: ICategoryCreate },
-    { user, models, subdomain }: IContext
+    { user, models }: IContext
   ) {

   async knowledgeBaseCategoriesEdit(
     _root,
     { _id, doc }: { _id: string; doc: ICategoryCreate },
-    { user, models, subdomain }: IContext
+    { user, models }: IContext
   ) {
-    const kbCategory = await models.Category.getCategory(_id);
+    await models.Category.getCategory(_id);
     const updated = await models.Category.updateDoc(

---

88-91: Simplify $in operator with single value.

Using $in with a single-element array is unnecessary. Use direct equality instead.

♻️ Proposed fix

     await models.Category.updateMany(
-      { parentCategoryId: { $in: [kbCategory._id] } },
+      { parentCategoryId: kbCategory._id },
       { $unset: { parentCategoryId: 1 } }
     );

---

103-109: Duplicate scheduled date validation logic.

The same validation for scheduled articles appears in both Add and Edit mutations. Extract to a helper function to follow DRY principle. Also, there's inconsistent formatting (if( vs if ().

♻️ Proposed refactor

Extract validation to a helper:

function validateScheduledArticle(doc: IArticleCreate): void {
  if (doc.status === 'scheduled' && !doc.scheduledDate) {
    throw new Error('Scheduled Date must be supplied');
  }
  
  if (doc.status === 'scheduled' && doc.scheduledDate && doc.scheduledDate < new Date()) {
    throw new Error('Scheduled Date can not be in the past!');
  }
}

Then use in both mutations:

   async knowledgeBaseArticlesAdd(
     _root,
     { doc }: { doc: IArticleCreate },
     { user, models }: IContext
   ) {
-    if (doc.status === 'scheduled' && !doc.scheduledDate) {
-      throw new Error('Scheduled Date must be supplied');
-    }
-  
-    if(doc.status === 'scheduled' && doc.scheduledDate && doc.scheduledDate < new Date()){
-      throw new Error('Scheduled Date can not be in the past !');
-    }
+    validateScheduledArticle(doc);

Also applies to: 126-132

---

98-117: Unused subdomain and fetch-only variables in article mutations.

Consistent with other mutations, subdomain is unused in Add/Edit/Remove. The kbArticle variable on line 149 is also unused.

♻️ Proposed fix for Remove mutation

   async knowledgeBaseArticlesRemove(
     _root,
     { _id }: { _id: string },
-    { user, models, subdomain }: IContext
+    { models }: IContext
   ) {
-    const kbArticle = await models.Article.getArticle(_id);
+    await models.Article.getArticle(_id);
     const removed = await models.Article.removeDoc(_id);
-
-
     return removed;
   },

Also applies to: 144-154

Configuration used: defaults

Review profile: CHILL

Plan: Pro