Restrict access for specific user

AI 生成的摘要

The discussion revolves around restricting access for a specific user, a “product feedback bot,” to only post in a specific category. Bas wants to prevent the bot from accessing other categories, even if the API key is visible to a trusted user.

Zogstrip suggests locking the user to Trust Level 0 (TL0), which would prevent some privileges. However, this wouldn’t prevent the bot from posting in other categories, such as “Uncategorised.”

As an alternative, zogstrip proposes creating a group for the bot and setting it as read-only to all categories except the one where the bot is allowed to post.

However, after testing, zogstrip finds that permissions are additive, meaning the bot would still be able to post in categories with more permissive settings. This means that the desired use case is not currently supported.

Is it possible to restrict access of a specific user?

My use case is that I want to create a “product feedback bot”-user, that will post in a specific category once people fill in a form embedded in our product.
The API key of this bot would most likely be visible to a determined (trusted) product user. I’d like to restrict the use to posting in a specific category.

Is there a way to strip them of any trust level? I can then grant them posting rights to a specific category

You can lock the user to TL0.

That makes sense, at least prevents some of the privileges, but then they can still post in e.g. Uncategorised.
I want this 1 user, to only be able to post in this 1 category, but I feel this usecase isn’t supported yet.

You will have to put the user in a group and add that group as read only to every category but the one they’re allowed to post into.

Ah, they use the most restrictive of the permissions granted? I thought they’d be additive.

So a category with Create / Reply / See doe “everyone” and See for e.g. “bot-group” wouldn’t allow the bot to post?
That could work!

That’s a good point. I’m not actually 100% sure.

EDIT: just tested, and they’re indeed additive. So I’m afraid your use case isn’t supported at this time.