I wanted to disable all AI integration on my site, and I am really pleased that it is a single setting. An answer to what the OP is looking for might be the equivalent of discourse_ai_enabled but on a per-user basis. That way, AI is not exactly on/off for the whole site. Even AI features that are on at a site level could be suppressed on a per-user basis. The logic of discourse_ai_enabled is then site-wide == true and per-user == true.
While it is generally true that they think about adding new customization settings to avoid unnecessary complexity, AI is the feature with the largest number of configurable settings. In the short span of time AI has even been a thing, it seems to have become the most customisable feature in Discourse.[1]
Here’s a quick and dirty analysis. I am relatively new here, so I show my work in case I’ve made a mistake.
su discourse -c 'bundle exec rails runner "SiteSetting.defaults.all.keys.sort.each { |k| puts k }"' > keys.txt
wc -l keys.txt
1663 keys.txt
cut -d _ -f 1 keys.txt | sort | uniq -c | sort -rn > counts.txt
If this is the right way to count them, there are 1663 possible site settings. Of those, 104 begin with ai_ and 3 AI settings don’t (composer_ai_helper_allowed_groups, discourse_ai_enabled, and post_ai_helper_allowed_groups) . So, by my reckoning, AI is the largest group of custom settings by a long shot (107/1663 or 6.4% of all site settings). Here’s the top 10:
- 107 ai
- 84 discourse
- 83 chat
- 71 max
- 65 enable
- 48 default
- 30 dfp
- 28 oauth2
- 28 amazon
- 28 allow
On the one hand, per-user suppression of AI features is just 1 more out of 1663. On the other hand, it might be hard to check it on a per-user basis when lots of code paths check it on a site-wide basis. That’s a tradeoff I’m not qualified to speculate on.
It’s also a fairly well-defined and self-contained feature, and relatively young, so its naming consistently with
ai_makes its settings easier to count than other components. That’s why I say it’s quick and dirty analysis. ↩︎