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).
** NOTE: NEW WORKSPACES THAT ARE CREATED AFTER THE WORKAROUND IS COMPLETED NEED TO HAVE THE WORKAROUND REAPPLIED, OTHERWISE IMPACT WILL REOCCUR **
- 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.
- 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.
- 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.
- The value of this field needs to also be blank.
- 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.
- 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.
- Press the "compass" icon to add a filter to each column in the table. Under the "Component" column, type "*inbox" and press enter.
- 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.
- 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.
- 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