Recent Content
Atomic framework does not support Coveo JSUI-specific events.
Previously, Coveo's JSUI library provided the flexibility to customize the search behavior based on business requirements by using event handlers like buildingQuery, deferredQuerySuccess, doneBuildingQuery, and duringQuery. Now Coveo has an updated Atomic framework, which is easier and more flexible to build the search interface, but at the same time, it's not providing the same features as JSUI to handle the events to customize the search behavior. Any suggestions or workarounds to achieve how we are using the deferredQuerySuccess to modify the field values before the search initialization.Default Tab feature not available in Coveo Atomic Framework.
Default tab feature is not available in Coveo atomic framework. While going through the Coveo documentation, I came across an article which talks about the custom component available through the CDN link. With the help of CDN, we can use custom tab components. By using this Tab component CDN, we have the following limitations. 1- We can't customize the tab component to meet the additional business requirements, as it's already built and hosted. 2- Lot's of additional conditioning features was available in JSUI framework Tab components, which are not supported in this Atomic custom Tab Component. Any suggestions or workaround to resolve the above use cases.Not able to assign a separate field to atomic-result-link component
Hi Team, In the Coveo JSUI framework, we have the capability to customize the default behavior of result links by assigning specific data fields using the attribute data-field="@uri" to the class CoveoResultLink. This allows us to map the desired input to the specified field, thus enabling customization of result links according to our requirements. But how can we use the same in atomic-result-link. Do you have any suggestions or workarounds to address the use cases mentioned above?Leveraging Coveo Atomic Framework for Request and Response Manipulation
PreProcessRequestMiddleware: The PreProcessRequestMiddleware provides direct access to requests before responses are received and pages are loaded. This allows for various manipulations, such as modifying request parameters or intercepting actions before execution. For instance, you can log query information for debugging purposes and perform conditional actions based on the query content. Example: preprocessRequest: (request, clientOrigin, metadata) => { const body = JSON.parse(request.body); request.body = JSON.stringify(body); // Reassign the modified body back to request // Execute the first search after preprocessing searchInterface.executeFirstSearch(); return request; // Return the modified request } preprocessSearchResponseMiddleware: The preprocessSearchResponseMiddleware operates after pages have loaded, providing access to search responses. Here, you can manipulate aspects such as total count and relevant data to meet specific requirements. This middleware allows for additional processing of search responses if necessary. Example: preprocessSearchResponseMiddleware: (response) => { // Additional processing of search response if needed return response; // Return the modified response } searchInterface.executeFirstSearch(); }(); Reference Link: https://docs.coveo.com/en/atomic/latest/usage/atomic-modify-requests-responses/#modify-responses By leveraging these middleware options, developers can effectively customize search experiences within the Coveo Atomic framework to align with unique business needs and user expectations.Switching Between List and Grid View in Coveo Atomic Search
This article describes how to create a custom component to switch between list and grid view for your Coveo Atomic search results. Coveo doesn't offer a built-in toggle component to switch between list and grid layouts. However, you can achieve this functionality using JavaScript (JS) and Cascading Style Sheets (CSS). Here's a step-by-step guide:Define Result Templates: Create two separate result list templates, one for grid view and another for list view. Assign Class Names: Assign appropriate class names to your <atomic-result-list> components. For example, use "list-view" for the list view template and "grid-view" for the grid view template. Create a Custom Button Component: Develop a custom component that displays buttons for switching between list and grid views. Implement Button Functionality: Use the onclick attribute for each button to trigger a JavaScript function when clicked. Inside the function, target the relevant <atomic-result-list> element using document.querySelector with the class name you assigned earlier (e.g., list_view = document.querySelector(".list-view")). Show/Hide Views with CSS: When the "List" button is clicked, set the display style of the list_view element to "block" (visible) and grid_view element to "none" (hidden) using: JavaScript list_view.style.display = "block"; grid_view.style.display = "none"; Implement similar logic for the grid button, showing the grid view and hiding the list view. Set Default View: Include logic to display the desired default view (list or grid) on initial page load. Benefits: Users can switch between list and grid layouts based on their preference. Improved user experience by providing more control over the search results display.Challenges of Implementing Folding Structure within the Coveo Atomic Framework
When ever we are using Coveo atomic folding structure, following are the few challenges we faced 1. We've encountered an issue with the "show more" and "show less" buttons where clicking on "show more" causes the "show less" button to appear above the folding structure, which is not a good behavior for end user. 2. Another issue we've observed is with the displaying of the number of child results. when we are updating the component to display only to two child results. But, for some parent results we are seeing three items as an child. Any assistance on identifying solutions or resolutions to address this default behavior observed within the Coveo Atomic framework.Filter results on a specific date range with dates converted to Unix timestamps.
Unfortunately the Vertex Search filtering functionality is pretty limited at the moment. Here is the documentation for how to implement filtering using the API. You'll notice there is no built-in support for date filtering currently, but there is support for filtering on numerical fields. Workaround: One workaround I can think of right now is to ingest documents with their dates converted to Unix timestamps (integers). In the front-end of the application you could provide a normal date picker to provide a date range, and then in the backend convert this to unix time and perform numerical filtering. Example: "Jan 12 2023 to Jan 12 2024" would be equivalent to a unix time filter of between 1673481600 and 1705017600. In Vertex Search this would be applied as a filter in the syntax: date_field_name: IN (1673481600, 1705017600)Impersonating Tokens with Their Respective Service Accounts in GCP
What is Impersonation? Impersonation allows one service account to assume the identity of another, enabling it to perform actions on behalf of the impersonated account. This is particularly useful when you need to segregate duties and manage permissions more granularly. How to Print an Access Token Using Impersonation 1. Login to your google account using this command: google auth login 2. To generate an access token for a service account using impersonation, you can use the gcloud command-line tool(google cloud sdk shell). Here’s the command you need: gcloud auth print-access-token --impersonate-service-account=YOUR_SERVICE_ACCOUNT Replace YOUR_SERVICE_ACCOUNT with the email address of the service account you wish to impersonate. Prerequisites for Generating the Token Before you can generate the access token through impersonation, certain prerequisites must be met: 1. Principals and Roles To enable impersonation, you need to assign specific roles to the service account. Here’s a step-by-step guide: Enable the Service Account Token Creator Role: At the owner level, you must assign the Service Account Token Creator role to the service account that will perform the impersonation. This role allows the service account to generate access tokens. You can do this through the GCP Console or using the gcloud command-line tool. Using GCP Console: Navigate to the IAM & Admin section. Select the appropriate service account. Assign the Service Account Token Creator role. Here is the documentation for better understanding : Use service account impersonation Conclusion By following these steps, you can generate access tokens for specific service accounts using impersonation. Properly configuring roles and permissions ensures that only authorized accounts can perform actions, maintaining the integrity and security of your cloud resources.
