-
Notifications
You must be signed in to change notification settings - Fork 79
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
[OpenAPI] Edit more security API summaries #3036
Conversation
Following you can find the validation results for the APIs you have changed.
You can validate these APIs yourself by using the |
Following you can find the validation results for the APIs you have changed.
You can validate these APIs yourself by using the |
Following you can find the validation results for the APIs you have changed.
You can validate these APIs yourself by using the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for fixing these. One suggestion around the Put Role spec.
* Create or update roles in the native realm. | ||
* Create or update roles. | ||
* The role management APIs are generally the preferred way to manage roles in the native realm, rather than using file-based role management. | ||
* The create or update roles API cannot update roles that are defined in roles files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we also add a note here that file-based role management is not available in Serverless? It's a bit confusing otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! Added in 304227b
Following you can find the validation results for the APIs you have changed.
You can validate these APIs yourself by using the |
Following you can find the validation results for the APIs you have changed.
You can validate these APIs yourself by using the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.x 8.x
# Navigate to the new working tree
cd .worktrees/backport-8.x
# Create a new branch
git switch --create backport-3036-to-8.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 d170981470e89d2e51b289807a7028938e002a9e
# Push it to GitHub
git push --set-upstream origin backport-3036-to-8.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.16 8.16
# Navigate to the new working tree
cd .worktrees/backport-8.16
# Create a new branch
git switch --create backport-3036-to-8.16
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 d170981470e89d2e51b289807a7028938e002a9e
# Push it to GitHub
git push --set-upstream origin backport-3036-to-8.16
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.16 Then, create a pull request where the |
Relates to #2635, #3033, #3035
This PR adds/edits summaries for the remainder of the security APIs. The first phrase is used as the "operation summary" and should basically align with what existed in the table of contents in https://www.elastic.co/guide/en/elasticsearch/reference/master/security-api.html (omitting "API" from the end of the phrase, however). Any subsequent information gets published as the "operation description".