Add more prompt template variable for USER_ROLE #1831

New Issue

GiteaMirror · 2025-11-11T14:54:19-06:00

GiteaMirror commented

2025-11-11 14:54:19 -06:00

Originally created by @rndmcnlly on GitHub (Aug 20, 2024).

Is your feature request related to a problem? Please describe.
I want to make my assistants sensitive to the user's role (e.g. whether they are an admin) without writing Python code.

Describe the solution you'd like
Support {{USER_ROLE}} as a prompt template variable, parallel to how {{USER_NAME}}

Describe alternatives you've considered
I know how to write a custom Filter to do this replacement myself, but it feels like it should be built into OWUI because the concept of roles is build into OWUI.

Additional context
It might be tempting for people writing system prompts to use the new {{USER_ROLE}} variable as a kind of LLM-powered access control mechanism (where the assistant can make subjective judgements that consider the user's role along with other information in making choices). This is probably a pretty dangerous thing to do. However, there are save and benign uses too. One might be an instruction like...

Warning or prompt-debugging information for admins: "If the user has role admin, warn them that they are logged in as an administrator, so any testing they do might not be representative of the normal user experience."
Offering normal users a simplified experience: "The following activities are available: A, B, C (admin only), D, and E. Don't mention admin-only items unless we know the user has hole admin." Strict access controls should be guarding any powerful admin-only tools, but a quick sentence like this can make features discoverable only to admins. Anyone can attempt to run activity "C" by name if they knew the name, and it will fail the strict check later if they are not allowed.

Related prompt template variables that might be useful (and also fit the pattern of being OWUI builtins):

USER_EMAIL
USER_LANGUAGE (the one used for localization in the front end)
USER_MODALITY (or something that might help the assistant know if the user is using the OWUI voice calling mode; might be used to for conditional instructions to keep responses short or to expect certain voice transcription errors or to use certain replacements when trying to speak responses, e.g. "During a voice call, OWUI should be written as "o-w-u-i" so that it will be spoken correctly via TTS.")

Originally created by @rndmcnlly on GitHub (Aug 20, 2024). **Is your feature request related to a problem? Please describe.** I want to make my assistants sensitive to the user's role (e.g. whether they are an admin) without writing Python code. **Describe the solution you'd like** Support `{{USER_ROLE}}` as a prompt template variable, parallel to how `{{USER_NAME}}` **Describe alternatives you've considered** I know how to write a custom Filter to do this replacement myself, but it feels like it should be built into OWUI because the concept of roles is build into OWUI. **Additional context** It might be tempting for people writing system prompts to use the new `{{USER_ROLE}}` variable as a kind of LLM-powered access control mechanism (where the assistant can make subjective judgements that consider the user's role along with other information in making choices). This is probably a pretty dangerous thing to do. However, there are save and benign uses too. One might be an instruction like... - Warning or prompt-debugging information for admins: "If the user has role `admin`, warn them that they are logged in as an administrator, so any testing they do might not be representative of the normal user experience." - Offering normal users a simplified experience: "The following activities are available: A, B, C (admin only), D, and E. Don't mention admin-only items unless we know the user has hole `admin`." Strict access controls should be guarding any powerful admin-only tools, but a quick sentence like this can make features _discoverable_ only to admins. Anyone can attempt to run activity "C" by name if they knew the name, and it will fail the strict check later if they are not allowed. Related prompt template variables that might be useful (and also fit the pattern of being OWUI builtins): - USER_EMAIL - USER_LANGUAGE (the one used for localization in the front end) - USER_MODALITY (or something that might help the assistant know if the user is using the OWUI voice calling mode; might be used to for conditional instructions to keep responses short or to expect certain voice transcription errors or to use certain replacements when trying to speak responses, e.g. "During a voice call, OWUI should be written as "o-w-u-i" so that it will be spoken correctly via TTS.")

GiteaMirror closed this issue

2025-11-11 14:54:20 -06:00

GiteaMirror referenced this issue

2026-04-19 19:34:04 -05:00

[GH-ISSUE #1831] BUG No completion from Ollama-served model proxied behind LiteLLM #12647

GiteaMirror referenced this issue

2026-04-25 02:54:21 -05:00

[GH-ISSUE #1831] BUG No completion from Ollama-served model proxied behind LiteLLM #28175

GiteaMirror referenced this issue

2026-05-05 12:17:18 -05:00

[GH-ISSUE #1831] BUG No completion from Ollama-served model proxied behind LiteLLM #51313

Sign in to join this conversation.