Currently, the Search API Server Task Manager assumes that it can add, update, and remove Indexes on its own (see \Drupal\search_api\Task\ServerTaskManager::getSupportedTypes()). But, it may not be possible (or cost-effective) to grant Search API permission to do all of those things on a Server.
For example, suppose an organization wants to connect Search API to an Index on a Server that they are already using for something else. They don't want to risk a Drupal mis-configuration breaking their existing Indexes, so they only grant the Drupal team credentials to update the index, i.e.: not add or remove the index.
While the backend-specific code can simply choose not to send certain commands (see the merge request in [#3522107], specifically the code paths where self_manage_indexes is disabled), the backend-specific code has no control over what Server Tasks that Search API queues up for that Server: if, for example, addIndex or removeIndex Server Tasks are added to that Server's queue, the index will be unusable until they complete successfully, which will never happen.
(note that [#3529273] has a patch to show the Server Tasks that are queued for a particular Search API Server)
/app/elasticsearch/content/search_indices/new_index/api, I called mine mparker17_test_index (if you choose a different name, only use underscores in the index name). Note the Elasticsearch Endpoint (which looks like a URL) from the Index's Overview page./app/management/security/api_keys/create, and note the key. Grant it the following permissions...{
"role-a": {
"cluster": [ "all" ],
"indices": [
{ "names": [ "mparker17_test_index" ], "privileges": [ "all" ], "allow_restricted_indices": false }
],
"applications": [],
"run_as": [],
"metadata": {},
"transient_metadata": { "enabled": true }
}
}
addIndex).Allow Servers to say which kinds of Server Tasks they support.
Don't queue Server Tasks that aren't supported by the server.
Active
1.0
General code
(Update issue summary, hopefully to get issue reference to work)
Turns out I had made an error in #3522107 which made me think i needed this feature; now that I've fixed the error, I don't think this will be necessary anymore. Thanks for your patience with me!