Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorporate bulk permission change from this git repo #98

Open
bayeslearner opened this issue Feb 14, 2023 · 2 comments
Open

Incorporate bulk permission change from this git repo #98

bayeslearner opened this issue Feb 14, 2023 · 2 comments

Comments

@bayeslearner
Copy link
Contributor

Is your feature request related to a problem? Please describe.

I think this is a feature that ksconf should have, please take a look?

(https://github.com/harsmarvania57/splunk-ko-change/blob/master/ko_change.py)

Describe the solution you'd like

Incorporate one of the needed features for mass migration to cloud or another premise.

@lowell80
Copy link
Member

Were you involved in the creation of this script? Does it do what you need or are you looking for something similar in functionality? (I looked over it, but am not fully getting my head around what it's doing.)

I have a handful of scripts laying around that I'd like to someday incorporate into ksconf (for example, I have one called rest_chown that allows for bulk update ownership of existing knowledge objects; and rest_sed that allows bulk rewriting of savedsearch strings, for example). But sometimes these need significant effort to go from an ad-hoc use to a package and distribution-ready ksconf command; so it's a slow process. Often some kind of sponsorship or active need drives such progress.

I'm also happy to make links to related Splunk admin tools that solve issues in and around the stuff ksconf does.

@bayeslearner
Copy link
Contributor Author

Among many things, I'm using it to mass change ownership of KOs. No, I'm not involved in creation of this script.

It is useful for example for assigning orphaned KOs to an existing user. Another use case is when the users in the cloud have a different name identifier than what they have on-premise. For example a user XXX is now XXX@YYY.com. I need to map permissions correctly if I want to migrate their stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants