1081 views

Description

Duplicate inbox modules show up after creating a custom workspace. This can also cause performance issues which crash users sessions after a few minutes of using Agent Workspace.  Note that it is not the number of workspaces that cause the problem, it's time spent on the inbox page. The situations that are occurring is that there can be 2 inbox modules where the chat/workspace call starts out as a single call, then exponentially increases on each poll from 2, 4, 16, then 32, etc.  As it increases, performance impact occurs.

Steps to Reproduce

Affected versions are Orlando Patch 7 and above, or Paris Patch 1 and above

1. Go to Studio
2. Create a new application, then add a Workspace to that application using the Guided Application Creator.
3. Make sure in the Design step for the Workspace creation, choose/select the "Inbox" module
4. Open the custom workspace and view the inbox module.

Two inbox modules are showing up - this is not expected. The expected behavior is that only 1 inbox module should be displayed on the custom workspace. That Inbox module will display an inbox that is shared with Agent Workspace. It is expected that Agent Workspace's Inbox modules should be shared across workspaces (both custom workspaces and Agent Workspace).

Workaround

** NOTE:  NEW WORKSPACES THAT ARE CREATED AFTER THE WORKAROUND IS COMPLETED NEED TO HAVE THE WORKAROUND REAPPLIED, OTHERWISE IMPACT WILL REOCCUR **

  1. Once the custom workspace has been created using the Guided Application Creator (GAC), navigate to the sys_aw_master_config table. Open the workspace created using GAC.
  2. Scroll down to the related list section and click on the "Workspace Modules" tab. Open the "Inbox" module record. This should open the associated sys_aw_module record for our custom workspace's Inbox Module.
  3. If you are not in the scope of the record, switch into the application scope that the record was shipped in. Then, in the middle of the page you should see a section containing two tabs entitled "Module Detail View" and "Module Content View". We want to remove the values in both of those fields and save the records. Once you have done so, save the associated sys_aw_module record.
    1. The value of this field needs to also be blank.
  4. Now we need to delete the associated UX Content Extension records that were automatically created when we added the Content/Detail components to the Inbox module when the workspace was originally created. We want to remove these records so that the associated components are not rendered in the DOM tree when the custom workspace's inbox page is displayed. 
    1. Navigate to the sys_ux_custom_content_root_elem table (this is the UX Custom Content Extension table). Add another column to the list view for "Application". This will allow you to see which UX Custom Content Extensions apply to what workspaces.
    2. Press the "compass" icon to add a filter to each column in the table. Under the "Component" column, type "*inbox" and press enter. 
    3. You should see 2 records for your custom workspaces (and you may see inbox records for other workspaces). Delete the 2 inbox related records associated with your workspace. 
  5. Follow steps 1-4 for all custom workspaces which contain inbox modules, until you are left with only 2 inbox-related UX Custom Content Extension records, and those records should be linked to the Agent Workspace application. Additionally, ensure all other custom workspaces which contain an inbox module have empty content and detail components for the associated inbox modules.

  6. Navigate to your custom workspace, and verify that 1 inbox module is displayed. You can further look in the HTML (by inspecting the page in the browser) for the inbox page and search for "</sn-inbox>" if you copy the associated component's sys_id from the and run a query on the sys_ux_custom_content_root_elem table for that sys_id, you should be greeted with the associated agent workspace inbox record.



Related Problem: PRB1405674

Seen In

SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - Vendor Risk Management - Madrid 2019 Q1
SR - ITOM - Discovery and Service Mapping - v1.0.35
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Security Incident Response PA Content - New York 2019 Q3
SR - SIR - Security Incident Response UI Patch - London 2019 Q2 v.6.2.3
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - VR - Rapid7 - London 2019 Q2 v.6.2.1
SR - VR - Vulnerability Response - New York 2019 Q3

Intended Fix Version

Quebec

Fixed In

Orlando Patch 7 Hot Fix 5
Orlando Patch 9
Paris Patch 3

Safe Harbor Statement

This "Intended Fix Version" information is meant to outline ServiceNow's general product direction and should not be relied upon in making a purchasing decision. The information provided here is for information purposes only and may not be incorporated into any contract. It is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at ServiceNow's sole discretion.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-11-25 07:12:49
Published:2020-11-06
Pasted image (3).png[View]Screen Shot 2020-10-07 at 1.08.20 PM (1).png[View]Screen Shot 2020-10-07 at 1.14.08 PM.png[View]Screen Shot 2020-10-07 at 1.14.59 PM.png[View]Screen Shot 2020-10-07 at 1.31.25 PM.png[View]Screen Shot 2020-10-07 at 1.33.26 PM (1).png[View]Screen Shot 2020-10-07 at 1.33.26 PM.png[View]Screen Shot 2020-10-07 at 1.34.29 PM.png[View]