Icecat Release Notes 195: Streamlining Processes and Empowering Users

In Icecat Release Notes 195, we’re thrilled to introduce a range of enhancements designed to streamline processes, empower our users, and elevate the overall Icecat experience. From automating channel partner assignments to enhancing image deduplication and unlocking full product stories for our Open Icecat channel partners, this release is packed with exciting developments. For additional details, please refer to the previous Icecat Release Notes.

Automating Channel Partner Assignments: Enhancing Efficiency and Collaboration

In our latest sprint, we’ve taken a significant step towards streamlining the process of authorizing channel partners. The focus was on automating the authorization request and response workflow between channel partners and brand partners, ultimately facilitating smoother operations and fostering better collaboration within our system.

The Automation Workflow

The automation process revolves around the authorization request initiated by a channel partner and the subsequent response from the brand partner. We’ve divided the logic into three distinct cases to ensure flexibility and efficiency.

Case 1: Brand Partner Registered and Assigned

• When a channel partner sends an authorization request to a brand partner registered in Icecat and assigned to the brand, the workflow is straightforward.
• Upon receiving the brand partner’s response—whether it’s an acceptance or denial—the request is automatically processed.
• If accepted, the channel partner is promptly assigned. If denied, the request is rejected accordingly.

Case 2: Brand Partner Registered but Not Assigned

• In scenarios where the brand partner is registered but not yet assigned to the brand, the response is routed manually to the responsible vendor manager.
• The vendor manager assesses the situation and decides whether to assign the brand partner to the brand.
• If assigned, the subsequent response from the brand partner is automatically processed. If not, the request awaits manual processing by another brand partner.

Case 3: Brand Partner Not Registered

• When a channel partner sends an authorization request to a brand partner who is not registered in Icecat, the brand partner must first complete the registration process.
• Once registered, the response follows the workflow of either Case 1 or Case 2, depending on the brand partner’s assignment status.

Introducing the “Authorization Requests” Interface for Brand Users

To empower our brand partners with better management capabilities, we’ve introduced a new user interface in our Product Information Management (PIM) system, named “Authorization Requests.”

• Accessible through the “Partners” menu upon logging into PIM, this interface centralizes all authorization requests sent from channel partners to brand partners.
• The interface presents crucial information, including channel partner details, brand names, the content of the authorization request emails, and actionable buttons for acceptance or denial.
• Notably, brand partners assigned to the brand can process these requests, regardless of whether they were the intended recipients of the original authorization request email.

Keeping Everyone Informed

Communication is the key in our system. Hence, every time a channel partner is assigned or not assigned to a brand, they receive prompt notification emails, ensuring transparency and keeping all stakeholders in the loop.

Our latest enhancements mark a significant step towards efficiency, transparency, and collaboration within our system. By automating authorization processes and introducing user-friendly interfaces, we aim to empower our partners and streamline operations for mutual success.

For further details on the additional logic introduced in Sprint 192, including default brand user settings and automatic assignment prohibitions, we encourage you to review our release notes.

Enhancing Image Deduplication with Cropping Consideration

In our latest sprint, we’ve made significant strides in improving the logic behind image deduplication, particularly in the context of cropping. This enhancement aims to optimize the handling of similar images while taking into account any cropping modifications made by editors.

Understanding Image Deduplication Logic

Before diving into the specifics of our latest development, let’s review the underlying logic of image deduplication:

• Manual Addition: When similar images are added manually by an editor, deduplication does not occur. This decision is based on the assumption that the editor will manually remove any redundant images.
• Auto-Import: However, if images are added via auto-import through the PUT endpoint or Import tool, deduplication comes into play.
• Prioritizing Non-Private Images: In the deduplication process, priority is given to non-private images with the lowest order number. This ensures that the most relevant and accessible images are retained within the gallery.

Example Scenarios

Let’s illustrate how the enhanced deduplication logic operates through a couple of scenarios:

Example #1: Cropped and Uncropped Images

• Consider a gallery with two similar images, initially added manually by the editor. The first image has been cropped, while the second remains unchanged.
• When an image with the same original parameters is uploaded via auto-import, the cropped image takes precedence over the uncropped one because of the order number. As a result, the cropped image remains active, while the uncropped image is deactivated based on deduplication logic.

Example #2: Uncropped and Cropped Images

• In another scenario, suppose the first image is uncropped, while the second is manually cropped by the editor.
• When a new image with identical original parameters is imported, the first uncropped image retains its active status, while the second duplicate image is deactivated in line with the deduplication logic because of the order number.

Our efforts to enhance image deduplication with cropping consideration represent a significant step forward in optimizing the management of image galleries. By refining the deduplication process to account for cropping modifications, we ensure that only the most relevant and representative images are retained within galleries, leading to a more streamlined and efficient content management experience.

Unlocking Full Icecat Product Stories 2.0: Empowering Open Icecat Channel Partners

In our latest development initiative, we’ve introduced an enhancement aimed at providing Open Icecat channel partners access to Full Icecat product stories 2.0 that are marked with a special “PublicAccess” tag from the Live HTML service. Let’s delve into how this new feature works and its implications for our partners.

Understanding the Functionality

The core objective of this development was to enable Open Icecat channel partners to seamlessly access and utilize Full Icecat product stories 2.0, specifically those marked with the “PublicAccess” tag. This tag serves as a key indicator, signaling that the product story is available for public consumption.

Illustrative Examples

To better grasp the functionality of this feature, let’s explore a few scenarios:

Case #1: Accessing a Public Product Story

• Imagine a Full Icecat product with two product stories 2.0.
• One story is published for the English (UK) locale and has the “PublicAccess” parameter set to true.
• When an Open Icecat channel partner calls the product story for this product on the English (UK) locale, the product story is displayed seamlessly.

Case #2: Restricted Access

• Now, consider the scenario where the product story is published for the English (US) locale but lacks the “PublicAccess” parameter.
• In this case, when an Open Icecat channel partner attempts to access the product story for the English (US) locale, it is not available due to the absence of the “PublicAccess” tag.

Case #3: Backup Locale

• Lastly, suppose the Open Icecat channel partner calls the product story for the English (ZA) locale.
• In this scenario, if the product story for the English (ZA) locale is unavailable, the system defaults to the backup locale, which, in this case, is English (UK). Thus, the product story of the English (UK) locale is displayed as a backup.

The same intuitive behavior of product story accessibility can be observed on icecat.biz, ensuring consistency and ease of use across platforms for our partners.

This enhancement represents a significant step forward in empowering our Open Icecat channel partners with access to valuable Full Icecat product stories 2.0. By leveraging the “PublicAccess” tag, we’re able to ensure seamless accessibility to relevant product information, thereby facilitating informed decision-making and enhancing the overall user experience.

Other Improvements in Icecat Release Notes 195:

Front Office – Icecat.biz

• Product Page Behavior Analysis: We’ve conducted an in-depth analysis to determine how the product page should behave based on different brand and product permission and publication settings. This comprehensive examination has resulted in the creation of a corresponding document, ensuring clarity and consistency in product page behavior.
• REST API Development and Testing: As part of our commitment to providing robust and efficient functionality, we’ve developed and tested REST APIs for two tabs on the product page: “Recommended” and “Similar.” These APIs will enhance the performance and reliability of Icecat.biz, offering users seamless access to valuable product information.

Reporting Engine

• Streamlined User Interfaces: We’ve removed outdated user interfaces that were associated with the old reporting engine functionality. Now, only the new reporting engine is accessible via the PIM user interface, ensuring a more streamlined and efficient user experience.
• Enhanced Filter Functionality: On the “Create report” interface, we’ve introduced a new filter that allows users to obtain statistical data about product downloads specific to brands and information solely about assigned channel partners. This filter enhances data accessibility and facilitates more targeted reporting.

Data Health V2

• Service for Score Settings History: We’ve developed a new service that will be instrumental in tracking product score settings history, providing valuable insights into score calculation and management.
• Development of ScoreBuckets API Endpoints: In conjunction with the new service, we’ve developed endpoints in the ScoreBuckets API, laying the foundation for robust score calculation and analysis.

Migration to S3

• Seamless File Migration: Our ongoing migration from mounted storage to S3 storage continues, with several files successfully moved during this sprint. These include critical files such as Refs.xml, Brand logos, Coverage reports, Product_mapping.xml, and DellReportProcessor.
• Optimization of File System: In addition to migration efforts, we’ve optimized our file system by removing unnecessary files, further enhancing system performance and efficiency.

With these developments and enhancements, we’re committed to elevating the experience for our users. From improving product page behavior to streamlining reporting processes and optimizing our file storage infrastructure, we’re dedicated to delivering a platform that meets the evolving needs of our users.

Olena Vasylynenko