My Lists from legacy workspace

[Dennis Ford]

We have been on legacy workspaces for about a year and a half, so our users have created quite a few "My Lists" in the legacy workspace. It appears that these will not be available (migrate) into configurable workspaces and every user will have to manually recreate each "My List" they have configured.  Is that correct?  Is it possible to write a script to recreate them all?  Thanks!  

[Mark Manders]

I think you should approach it from the other side: start clean again. Make sure every user is looking at the same information by creating new, default 'My Lists'. Look at the current ones and check if it makes sense it's there or not. If so, create it on the new workspace, if not, they will need to create it again, but should have a good reason to do so. People with the same job, looking at different filters, is never a good thing.

If my answer helped you in any way, please then mark it as helpful.

Mark

[Brad Tilton · Accepted solution]

Hi Dennis,

I agree with Mark that this is probably a good opportunity to see if it's time to refresh your my lists. That being said, it should be simple enough to write a script that copies the agent workspace my lists [sys_aw_my_list] to configurable workspace my lists [sys_ux_my_list]. It looks like those forms are almost identical but you'd obviously want to test extensively.

You could also build out a record producer or button that lets individual users bring their old my lists into the new workspace or start from scratch.

[zrebak]

Hello Brad,

I tried following your suggestion and write a script, however sys_ux_my_list table resides in private scope "@servicenow/now-record-list-menu-connected".

As a result, I cannot add cross-scope policy to the application I cannot select from the dropdown.

This also breaks the possibility of exporting the sys_aw_my_list records and reimporting them via Excel spreadsheet.

And since there is no "User" reference field on any of these tables, I assume it's reading from sys_created_by when presenting the lists back to their owners, so there are three options of manual restoration (if it absolutely needs to happen):

1. As an admin, impersonate the user and recreate the lists in new Workspace, using previous table contents to match data

2. Check if users have necessary roles, impersonate them and recreate the lists directly on the table using sys_ux_my_list.do

3. Tell users to recreate the lists themselves

Why SN decided to make it so hard to migrate these is beyond me. The tables sys_ux_my_list and  sys_aw_my_list are downright identical, with exception of one label difference ("List name" versus "Title"), albeit field is named the same.

[zrebak]

Since I just got a notification for this thread, here is a workaround for the above issue:

1. Create fix script for the above in global scope
2. Export it as XML

3. Change the scope manually to the troublesome app

4. Reimport

5. Execute

6. ???

7. PROFIT