Struct EditUserAccountTool 

pub struct EditUserAccountTool;

Corrects a user’s email and/or its verification state, after the admin confirms.

Trait Implementations

impl ChatbotToolDeclaration for EditUserAccountTool

const NAME: &'static str = "edit_user_account"

The name the LLM calls this tool by. The registries dispatch on it and Self::get_tool_definition must advertise it, so the two cannot drift apart.

const CATEGORY: ToolCategory = ToolCategory::AdminSupportAccounts

Which configured category of tools this belongs to. A chatbot offers it only if its configuration lists this category; the caller must still be authorized for it.

fn offer_requirements( _user_context: &ChatbotTurnContext, ) -> Vec<ToolRequirement>

What the caller must be allowed to do against the turn itself for this tool to be offered to the LLM at all.

fn get_tool_definition() -> AzureLLMFunctionToolDefinition

The definition sent to the LLM as part of a chat request. Azure rejects it unless strict is true and the parameter schema forbids additional properties.

impl ConfirmableActionTool for EditUserAccountTool

type Arguments = EditUserAccountArguments

type Facts = ()

Extra facts Self::execute gathers while performing the mutation, used only to decide what Self::output_description_instructions should mention for this particular call. () for a tool with nothing worth gating on.

fn call_requirements( arguments: &Self::Arguments, _user_context: &ChatbotTurnContext, ) -> Vec<ToolRequirement>

What the caller must be allowed to do against what this call actually targets. Checked before the turn suspends on the call and again immediately before the mutation runs.

fn parse_arguments(arguments: &str) -> ChatbotResult<Self::Arguments>

async fn execute( conn: &mut PgConnection, _app_config: &ApplicationConfiguration, arguments: &Self::Arguments, _authorization: &ToolAuthorization<Self>, ) -> ChatbotResult<(ExecutedAction, Self::Facts)>

Performs the mutation. Must re-verify every model-supplied display field against the database (case-insensitively for emails) and refuse with a descriptive error rather than mutate on a mismatch, so a wrong or stale display can never mutate a row it doesn’t describe. authorization both proves the confirming admin was checked against this call’s own requirements and names them, so the mutation cannot run ahead of the check and the audit row cannot credit anyone else.

fn output_description_instructions( arguments: &Self::Arguments, _facts: Option<&Self::Facts>, app_config: &ApplicationConfiguration, ) -> Option<String>

Just-in-time instructions for the LLM on how to describe the outcome. facts is None on a declined answer (nothing executed) and Some after a successful Self::execute, so instructions can be conditioned on what this call actually did instead of always including everything that could ever be true. app_config is available on both branches (unlike facts) so a verification link can be offered even on a decline.

fn declined_output(_arguments: &Self::Arguments) -> String