Support for centrally managed / enterprise configuration

[tubegamevideo-coder]

Your idea

Use case
We're deploying ThunderAI across ~17 seats in our company (Thunderbird), using it mainly
for translation, summarization and drafting email replies.

Problem
All configuration (custom prompts, AI backend/API key, automatic features like tagging)
currently lives per-profile, so any change has to be applied manually on every single
machine. This doesn't scale well as we add more seats or update our setup - it would be
great to have some way to manage and update the configuration centrally instead of
touching each installation individually.

Not sure what the best approach would be on your end, but wanted to flag this as a real
pain point for team/company deployments. Happy to share more detail about our setup if
that's useful. Thanks for the great add-on!

Value

No response

Additional information

No response

[micz]

Hello, thanks for the detailed report.
This is a great feature to be implemented and it's much easier to design well with an actual deployment to look at rather than an hypothetical one.

Thunderbird does have a native mechanism that could fit: enterprise policies.
The 3rdparty → Extensions policy key lets administrators push settings to a specific add-on, which the extension can then read via browser.storage.managed. No extra infrastructure needed beyond whatever you already use to distribute configuration.
That's the direction I'm most inclined to explore.

Before I commit to a design, a few questions:

1. How do you currently manage those machines? If you already have a way to push files to the Thunderbird install directory, the policy route is basically free for you.
2. Which settings do you actually need to manage centrally? A concrete list would help a lot. Specifically: the connection settings and/or which provider/API are you using? The custom prompts? Anything else, like the automatic tagging or the integrated features? And for each of these, does it genuinely need to be enforced, or just pre-filled with a sensible starting value that users can still change? There's a real difference between "everyone must use this endpoint" and "save people the setup work".
3. How are you handling the API key today? One shared key on every machine, or one per user? Note that policy files sit in the install directory in plain text.

Happy to keep iterating here or via email using m@micz.it if you prefer.

[tubegamevideo-coder]

Hi,

Thanks for taking this seriously - happy to work through the specifics with you.

1. We don't have any existing fleet-management tooling (no GPO/Intune/RMM/login scripts) -
   this would be our first. That said, since policies.json is a single static file living in
   the Thunderbird install directory, setting up something minimal for that (a scheduled
   script, or even a manual one-time copy across the 17 machines to start with) is a much
   smaller problem than what we were looking at before. So it's not literally free for us,
   but it's a small, one-off thing to solve on our side.

2. What we'd want managed centrally: the API provider/endpoint and key, the model, our
   custom instructions/prompts, and token limits. Our first instinct on enforced vs. default:

   • Enforce: connection settings (provider/endpoint + key) and token limits - these have
     real cost/compliance implications for us.
   • Default, user-editable: model choice and custom prompts - people doing different kinds
     of work (translation vs. summarization vs. replies) will likely want to tweak these.
     Not a hard requirement though - if a different split makes the design cleaner on your
     end, we're flexible.

3. Right now everyone shares one API key, which is exactly what makes your plain-text
   warning relevant to us. Rather than pushing that raw provider key out via policy, we're
   planning to route requests through an internal gateway/proxy and put only a lower-privilege,
   easily-rotated token in the policy file - the real provider key never leaves our proxy.
   Since ThunderAI already supports an OpenAI-compatible backend, I'd expect this to just work
   as a "connection endpoint" on your side, but wanted to flag it in case it affects the design
   of the managed schema (e.g. if "provider" ends up being a fixed enum vs. an arbitrary
   endpoint URL).

Happy to keep going here, whichever's easier for you.

Thanks again!

[micz]

This is what I think we could do.

Everything will live under ThunderAI add-on ID in policies.json. The keys will have the same names ThunderAI uses internally, so anything you can set in the options page can eventually be set here:

{
  "policies": {
    "3rdparty": {
      "Extensions": {
        "thunderai@micz.it": {
          "_schema_version": 1,
          "_org_name": "Acme Inc.",

          "connection_type": "openai_comp_api",
          "openai_comp_host": "https://gateway.internal.acme.example/v1",
          "openai_comp_api_key": "sk-proxy-xxxxxxxxxxxx",
          "openai_comp_use_v1": true,
          "openai_comp_chat_name": "Acme AI",

          "openai_comp_model": "gpt-4o",
          "openai_comp_model:locked": false,

          "default_chatgpt_lang": "en",
          "default_chatgpt_lang:locked": false,

          "_org_prompts": [
            {
              "id": "acme_reply_formal",
              "name": "Acme — Formal reply",
              "text": "Reply to this email in a formal tone, using our house style...",
              "type": "1",
              "action": "1",
              "need_selected": "0",
              "need_signature": "1",
              "need_custom_text": "0",
              "define_response_lang": "1",
              "show_in": "both"
            }
          ]
        }
      }
    }
  }
}

Locked or editable Every key you put in the policy will be enforced by default: the option will appear in ThunderAI's settings with the value you set, greyed out, labelled as managed by your organization. The user will see it but not change it.

To make a key a mere starting value instead, you'll need to add a sibling key with :locked set to false, as with openai_comp_model and default_chatgpt_lang above. The user will get your value pre-filled but will be able to edit it freely.

That maps directly onto the split you described: endpoint and key enforced, model and language left open. And if you later change your mind about where that line sits, it's a one-line edit in the policy file with no add-on update needed.

A note on the token limit: at the moment there is no token limit system in ThunderAI, if needed please open a new issue asking for it.

Organization prompts will go in _org_prompts. They will show up as a separate, read-only set alongside personal prompts, always in sync with the policy, with a duplicate button for anyone who wants their own editable variant. Each one will need a stable id that you assign and don't change. You will also be able to set "api_type" per prompt if you want, say, translation to run against a cheaper local model while replies go to your gateway. It will be the same for the automatic features via translate_connection_type, add_tags_connection_type and so on.

One important limitation to plan around: policies are only read when Thunderbird starts. There's no live reload, so any change, including rotating that token, takes effect only after each user restarts Thunderbird.

Does this idea cover what you need, or is there anything in your current setup that's missing from it?

[tubegamevideo-coder]

Hi,

This looks like it covers what we need, and the per-feature routing on _org_prompts
(api_type, translate_connection_type etc.) is actually more than we asked for - genuinely
useful for us, since we'd like translation to run against a cheaper model while replies
go through our main gateway connection.

Two follow-ups:

• Token limits: not really a priority for us, actually - email-based usage isn't likely to
  burn through tokens the way other use cases might, and if it ever does become a concern,
  we can handle quota/rate-limiting on our own gateway instead. So no need to treat this as
  a blocker for the policy design on your end.

• No live reload: that's completely fine for us. Updates landing whenever a machine reboots
  or Thunderbird restarts works well - nothing here is time-critical for us.

Really appreciate how much thought you've put into this - between the detailed questions
and this design, it's been way more responsive and helpful than we expected going in.
Thanks so much for taking the time.

Best,
Pal Nemeth

[micz]

Thank you for your feedback.
I'll start working on this after the 5.0.0 release, so please expect a few weeks for the first test version.
I'll update this issue.