After migrating from our stand alone single instance splunk box to a clustered environment, including clustered search heads, we successfully migrated the items from our old "search" app to our new "search" app by renaming the old app "searchmigrationapp" and pushing it out to the search heads as per the instructions Migrate from a standalone search head to a search head cluster:
However this has left users unable to delete any reports or alerts contained within this "searchmigrationapp". The option just doesn't show up in their menus. Not even in the admin's menu. Sharing of the "searchmigrationapp" is also set to Global.
Any thoughts on how to fix this? Users would like to be able to delete these migrated reports.
Go into the app's metadata folder and make sure in either default.meta or local.meta it's not referencing the old apps name for permissions.
Also, make sure your configurations are in the local directory inside the app, not default. The page you linked to explains that users won't be able to delete items that are migrated in that fashion since they're in the default directory.
Anything deployed via the cluster deployer has all of its config files moved from 'local' scope to 'default' scope. As such, it cannot be deleted via UI within the cluster itself. If you want to delete anything from your 'searchmigrationapp', you must remove it from the copy contained on the cluster deployer (in
$SPLUNK_HOME/etc/shcluster/apps) and then execute a bundle push.
You should have contacted splunk support and they could have provided you with a migration script (migrate_users.py) that would allows users to delete their knowledge objects.
What should have happened is that you used the script to migrate in their existing objects. This script duplicates the creation of each object via rest calls. These rest calls goto the captain which means that all objects correctly exist within the splunk search head cluster.
As such you can perform all the normal actions against them (delete etc).
You can potentially you could ...
Delete the searchmigrationapp on the deployer. Push bundle. Restart.
Run the script against the searchmigrationapp and get all the objects pulled into the captain.
Depending on the app structure and ownership of objects some manual file rejigging may be required.
Once run you will have all objects back and have normal full control again.
Note: in 6.3 deploying user scoped configs (private) via the deployer keeps them in a state where users can delete them from within the cluster normally. I assume the issue here is with anything in the 'searchmigrationapp' scope, which would still be merged down to default on bundle push.