4 results found

1. Better extensibility options for Search V2 Indexing

   We have a requirement on our project that requires us to change the behavior of the search indexing v2. In trying to do so, our development team ran into an issue where the class we needed to extend was not extensible (internal, sealed, or non overrideable methods).

   Basically what we are trying to do is remove the condition that excludes child products when fetching indexable products that is in line 896 of class Insite.Search.Shared.DocumentTypes.Product.Index.SearchV2.Models.Product (this is in version 5.2.2412.1705)

   What we would like to see changed is:

   1 - Make the SearchV2.Models.Product public instead of internal and remove the sealed keyword (and do the same for other classes in the SearchV2 and SearchV2.Models namespaces)

   2 - If possible, move the lines from 893 to 904 to a virtual method so we can override it - specifically this code:

   var indexableProducts = products
   .Except(inactiveStyleParents)
   .Where(p =>
   p.StyleParentId is null
   && (
   !p.IsDiscontinued
   || (productIdsWithQuantityOnHand.Contains(p.Id) && p.TrackInventory)
   )
   && p.IsActive
   && p.IndexStatus != 2
   )
   .ToArray();

   And it's not really just about this particular piece of code - in that class the entire ReadFromDatabase method has a lot of logic in it, is there any way to break some of that apart into virtual methods, or handler chains / pipelines and make it extensible?

   3 - Make the constructor of class Insite.Search.Shared.DocumentTypes.Product.Index.SearchIndexableProduct public instead of internal

   Without these extension points, we are currently forced to copy / paste a lot of classes from base code, and slightly modify a few of them, in order to achieve the desired functionality. Attached is a screenshot from our pull request showing all of the files we had to copy - the only ones we actually change are the ones highlighted in red.

   And again, this is not just about our specific requirement, but more of a request to open the entire Search V2 Indexing architecture to be more extensible. Right now it's pretty "locked down"

   We have a requirement on our project that requires us to change the behavior of the search indexing v2. In trying to do so, our development team ran into an issue where the class we needed to extend was not extensible (internal, sealed, or non overrideable methods).

   Basically what we are trying to do is remove the condition that excludes child products when fetching indexable products that is in line 896 of class Insite.Search.Shared.DocumentTypes.Product.Index.SearchV2.Models.Product (this is in version 5.2.2412.1705)

   What we would like to see changed is:

   1 - Make the SearchV2.Models.Product public instead of internal and remove the sealed… more

   •  

   7 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Inherit Product Assignments in Category Hierarchy for Rule Engine

   Current Behavior: In Optimizely, products are currently assigned only to the most specific (end-node) category within a 3-level taxonomy.
   For example, if the category tree is:

   Power Tools > Drills > Cordless Drills

   Then a product like a cordless drill is assigned only to the "Cordless Drills" category, and not to "Drills" or "Power Tools".

   Problem: This structure causes significant limitations when using the rule engine—specifically the “Product In Category” rule. Since products are not assigned to higher-level categories, those categories cannot be used effectively in rules.

   This creates a major pain point when building dynamic catalog restriction groups. Users are forced to assign rules at the lowest-level categories, resulting in excessive manual configuration and a time-consuming setup process.

   Proposed Enhancement: Enable category inheritance within the rule engine so that:

   If a product is assigned to a subcategory, it is implicitly considered part of all its parent categories.

   Rules applied to a higher-level category should automatically include products assigned to any of its descendant categories.

   Benefits:

   Significantly reduces the time and complexity required to build and maintain catalog rules.

   Makes the rule engine more intuitive and aligned with how category hierarchies are conceptually structured.

   Improves scalability and efficiency for merchandisers and admins managing large product catalogs.

   Current Behavior: In Optimizely, products are currently assigned only to the most specific (end-node) category within a 3-level taxonomy.
   For example, if the category tree is:

   Power Tools > Drills > Cordless Drills

   Then a product like a cordless drill is assigned only to the "Cordless Drills" category, and not to "Drills" or "Power Tools".

   Problem: This structure causes significant limitations when using the rule engine—specifically the “Product In Category” rule. Since products are not assigned to higher-level categories, those categories cannot be used effectively in rules.

   This creates a major pain point when building dynamic catalog restriction groups. Users… more

   5 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Spire CMS - Identifying widgets missing content in current language

   In the Classic CMS, we were able to see a warning or indication style on widgets that did not have content in the current language. However, in Spire CMS, this visual indicator does not seem to be available.

   We would like a way to clearly identify in Spire CMS which widgets have been localized to the current language and which have not, similar to the warning indication available in Classic CMS.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Add the ability to grant impersonate permissions to custom roles

   I want to be able to create a custom role for the admin console users that while given limited permissions through the Application Dictionnary would also be granted the ability to impersonate website users. Currently, the impersonate feature is limited to 4 roles: ISCSystem, ISCImplementer, ISCAdmin, ISCUser. Being able to customize the CanCurrentUserImpersonateAnotherUser method used by the AccountController would give more flexibility.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating