App has some pages unable to change model due to archive
Hi team,
I have made a copy of a model and app and am attempting to change the source model from within the app.
For some reason, every page is set to the same workspace and model, but 90% of the pages are saying the model is archived so I cannot update the source model. I have checked the original app and model and it has the same issue.
I have restored all backups related to the model and none of them corrected the issue.
The app pages also still work.
Here is what it looks like. you can see the workspace and model is the same across all pages.
Answers
-
Go to Show models and unarchive all the models you see in that list, once you do that, you will be able to see the models on those pages.
Those pages must be linked to a model, which is now archived. This section of Show models will show list of all models linked to any of the pages of the app.
Try this out!
0 -
Hi Dikshant,
under show models its also only showing the single model
0 -
Hi @MatthewWilcox, this could be the result of a few different things. Each of these involve changing the source model in the page settings section (the '…' button shown when you hover over a particular page).
To identify whether there is a "hidden" model associated with the page, navigate to Source Model tab in Page Settings. If you see the dialogue below, there's an underlying model still linked to the page (options 2 and 3). If you don't see this dialogue and "Enable multiple source models" is green, your issue is option 1 below.
- The Page Has "Enable Multiple Source Models" Turned On
- This is the most likely explanation. Even though there technically isn't an archived model tied to that page, you'll see this dialogue.
- Go to the page settings in the page section of the app, select Source Model, and disable the Multiple Source Models option.
- The Page is Associated with an Archived Model.
- What do you see in the rest of the "Manage Models" dialogue? If the page is tied to an archived model, you should see "Model Archived" under the Model Status column.
- If you unarchive the model, you can deselect the unneeded model, then unselect "Enable Multiple Source Models"
- After this you can re-archive the model.
- The Page is Associated with Deleted Model.
- What do you see in the rest of the "Manage Models" dialogue? If the page is tied to a deleted model, you should see nothing under the Model Status column.
- If you restore the model, you can deselect the unneeded model, then unselect "Enable Multiple Source Models"
- After this you can re-delete the model.
0 - The Page Has "Enable Multiple Source Models" Turned On
-
Why isn't it default behaviour to be able to change a page even if the model itself is archived? Is there a reason it's kept locked down?
1 -
Since we cannot assign an archive model to a page, there's no option to unassign the page from the model if it's archived. Try to unarchive the old model copies, that way you will be able to get the page assigned to different model. That's my theory to it!
Get some help from Anaplan Support if they can get the list of associated models from backend.
0 -
I just faced this issue, in a deployment where we have a huge amount of pages.
In my case I was moving one model from one workspace to another so I had to relink (through model import) so I had to re-link 100 entries to repoint all the relevant pages to the new model and I faced the error "Models of the selected pages were not changed" error. Doh!🤐
A consistent amount of pages are linked to several models (eg SIT and PROD, DEV, SIT and PROD, etc), as you would expect.
On top of that we create several copy models for tests, development, POCs, etc and we add these models to the relevant pages that are needed. However, we don't remove the connections before archiving or deleting a model.
The workaround I have just been given by the support is to unarchive all affected models and amend all pages accordingly (it might take me 10 days of manual effort!) .
The only workaround I found it's working at the moment is to amend every single affected page, adding the new model as source. This as well is taking effort.
The UX is certainly lacking of basic out of the box functionalities which allow to apply bulk changes for these type of frequent and common requirements and we should be able to delete those connections manually even if a model is archived/deleted.
We shouldn't need to invest time and create/use scripts or other workarounds?
0 -
@Alessio_Pagliano I'm currently in the process of migrating a dozen models from Workspace A to Workspace B. It's been miserable to have to manually by hand update hundreds of pages in various Apps, and also have to unarchive old models to be able to remap pages.
I agree with you about lack of basic functionality.1 -
Hi @StevenK yep, I agree there's some lacking of basic out of the box functionality : I will continue to insist.
Hopefully the bug we are experiencing has either been resolved or will be soon…I will provide an update on here as I am chasing the support up on this.
In terms of archiving/unarchiving due to that bug…I wish you posted it earlier as there's a workaround :-P Apparently if you copy the app the new app will not have that issue.
1 -
@Alessio_Pagliano I appreciate the heads up. Still have a few models to migrate today so will give that a shot.
0 -
@Alessio_Pagliano did you ever hear a resolution on this? This is an ongoing headache at multiple large clients we have for what should be basic functionality
0 -
Hi @brettnish ,
No I didn't….I always struggle a bit having bugs being formally akcnowledged, prioritised and dealt with differently then support tasks (where I get even less luck :P ).
I sent follow up requests through our CSBP and I'll post a formal update here, when available.
However, just yesterday I was forced to do what was necessary and the "repointing" through the manage models page did work smoothly. And that was without even trying the workaround.
So I'd check basically. I have the feeling the fix went in and it was not communicated (neither here/community nor to my bug #😒)
0 -
This is one of those issues where you do not know it is an issue until you experience it!
Following, thanks.
0
