Should "force" LLM to resolve app in data owner conversation

[asaf]

Sometimes LLM acts as it has all the application details thus not resolving the app ID.

[asaf]

I'm still struggling to make the dataowner approval grant the access according to the provisioning schema:

System schema (seems like it contains the relevant data including _projectid and _accesslevel):

requester: asaf@crossid.io.
previous conversation summary: The user needs access to the 'SEO Optimization Project' in Jira for audit purposes..
directory: projects
app_id: eq3dlPwhl4
app_name: projects
project_id: SEO-001
access_level: Audit and Compliance Access

approve_roles tool input:

{
  "conv_summary": "The user needs access to the SEO Optimization Project in Jira for audit purposes.",
  "requester_email": "asaf@crossid.io",
  "conversation_id": "HPKITHUczx",
  "user_email": "asaf@crossid.io",
  "workspace_id": "XVUmjHPRwL",
  "app_name": "projects",
  "directory": "projects",
  "access_id": "eq3dlPwhl4"
}

Provisioning schema:

{
  "project_id": {
    "description": "the project id"
  },
  "access_level": {
    "description": "the level of the access to grant"
  }
}

Output:

failed to provision role: {"status":"error","detail":{"issues":[{"code":"invalid_type","expected":"string","received":"undefined","path":["access_level"],"message":"Required"},{"code":"invalid_type","expected":"string","received":"undefined","path":["project_id"],"message":"Required"}],"name":"ZodError"}}

[ErezSha]

@asaf Did you try it with #146 ? It works really well for me.

[asaf]

@ErezSha yea, this comment is using PR #146 I find it odd because the summary contains everything right (_ projectid and _accesslevel are correct!)

[ErezSha]

@asaf I made more changes and it looks more consistent. For some reason, it can't parse the answer when it's not going through the function.