Group rules and /newrules
core · M1
/rules/regras/newrules/novasregras- v1 scenarios
- 4
- Ported
- 9
- Green
- 14
- Failing
- —
GroupShield.py:49-63What 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,/reglasand/newrules,/novasregras,/nuevasreglas. A group that has taught its members the Portuguese spelling must not discover it stopped working. /newrulesis 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/configrejection, which is a different message with a tutorial video attached. - Rendering the stored body. Literal
\nescapes are unescaped, user tags are substituted with the requester's name, and the catalog'squestionsfooter 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:
cb.py sandbox-up, then open the client and pick the default seed.- Send
/rulesin the group — expect the empty-state message. - Send
/newrules, then reply to the prompt as the plain member — expectYou are not a group admin!. - Reply again as the anonymous admin (the gold-ringed chip) — expect
Updated rules message! ✅, and/regrasto answer with the new body.
Reload cached admins and settings
v2's caches invalidate themselves (D6), which is why nobody ported this - but the trigger is still advertised in the Cookiebot_functions.txt this repo ships verbatim, so typing it answered nothing. Does a real invalidation, not a stub: admins.refresh re-reads getChatAdministrators, which is the one thing no invalidation of ours could have known about. QA authored, not ported
Language selection
QA describes a web settings page; v1 only has the in-chat menu