Let me comment/correct... > I have knowledge objects in my custom apps which are created & managed in /default > by manually uploading to splunkcloud and installing. this causes me a couple of problems : > > 1. even though they have write perms in default.meta for sc_admin only, > users with other roles can change the knowledge objects through the ui - > for example they can disable a savedsearch. > presumably this creates a new copy in /local INCORRECT. It does wrote to 'local' but it only creates a stanza header with the saved search name the disable setting like this: [SavedSearcNameHere] disabled=true > which means that my perms from default.meta no longer apply > because new perms are written in local.meta. > am i correct in my assessment, and if so what is the point of write perms? INCORRECT. The perms persist as-is, UNLESS some other deliberate action is mace to change them. > 2. once the user has created a /local copy of the savedsearch by changing or disabling it, > there is a lock or conflict situation.... the ui /local version always gets precedence, > and because there is also a version in /default i can no longer see a delete option for the ui version. > so i am stuck with the ui version forever. > in other words, the person with zero perms wins over the sc_admin. COMPLETELY INCORRECT. The problem that you are having is that the GUI does not allow anything to be deleted that is in "default". In your case, if you have a saved search called "SavedSearchFOO" defined in "default", the GUI *will* show you a "delete" option in the "edit" menu but if you click on it, you will get an error like "This saved search failed to handle removal request due to Object id=SavedSearchFOO cannot be deleted in config=savedsearches." > The only ways I have found to get out of this situation are > (a) ask splunk cloudops to delete the files from /local, which takes 3 days, or > (b) to rename all of the savedsearches in /default, upload and install the app, > manually delete the versions that the user created in the ui, > name the /default versions back again, and upload / install the app a 2nd time. That works. > Am i missing something in terms of a better way to rectify things > when this happens and why this might be the correct splunk behaviour? Some KOs handle this better in that if the original is in default and somebody edits it and the edit goes into local, a "delete" will delete the details in "local" and revert back to the original in "default" but this does not work for "savedsearches.conf". What I would do is make permissions so that NOBODY can edit the stuff. This will force users to CLONE it to change it and make it easier to realize that he should involve an admin to get it reviewed/approved and folded back into the original app/name/folder.
... View more