Cookiebot
Features

Group rules and /newrules

core · M1

DoneM1gatewaycore
Triggers/rules/regras/newrules/novasregras
v1 scenarios
4
Ported
9
Green
14
Failing
—
behaviour contractv1 source: GroupShield.py:49-63

What it does

Anyone in a group can send /rules and get the group's rules back, as a reply, in the group's language. If no rules are set, the bot says so and points at /newrules.

Setting them is a two-step conversation, not an argument: /newrules posts a fixed prompt, and whoever replies to that prompt has their reply text stored as the new rules. Only an admin's reply is accepted — including an anonymous admin, whose message arrives from GroupAnonymousBot rather than from a user.

Behaviour that must not change

  • Every alias. /rules, /regras, /reglas and /newrules, /novasregras, /nuevasreglas. A group that has taught its members the Portuguese spelling must not discover it stopped working.
  • /newrules is not admin-gated. v1 shows the prompt to anybody; the admin check happens on the reply. Rejecting the command itself would look tidier and would be a behaviour change.
  • The rejection wording. You are not a group admin! — hardcoded and, unlike almost every other string, not localised in v1. Not the /config rejection, which is a different message with a tutorial video attached.
  • Rendering the stored body. Literal \n escapes are unescaped, user tags are substituted with the requester's name, and the catalog's questions footer is appended unless the body already ends in @MekhyW. A body that renders empty sends nothing at all — which is a different outcome from the "no rules set" message.
  • The empty state is the catalog string, ported byte-for-byte from v1's locale files — not the paraphrase the upstream QA scenario quotes.

Two QA-spec mismatches were found while writing the contract, and v1's real behaviour won both (per the rulebook: v1 wins for observable behaviour, QA wins for intent). The scenario wording is kept verbatim anyway, with the step definitions asserting what the bot really does — see the contract for the full reasoning.

How to verify it

Scenarios: qa/features/core_rules.feature, bound by qa/test_core_rules.py. Unit coverage in packages/cb-gateway/tests/test_rules.py; persistence in qa/integration/test_group_rules.py.

By hand, in the sandbox:

  1. cb.py sandbox-up, then open the client and pick the default seed.
  2. Send /rules in the group — expect the empty-state message.
  3. Send /newrules, then reply to the prompt as the plain member — expect You are not a group admin!.
  4. Reply again as the anonymous admin (the gold-ringed chip) — expect Updated rules message! ✅, and /regras to answer with the new body.

On this page