Adding a Customer Forum: Who May Publish, and Who May Moderate?

A customer forum needs a publishing policy before it needs reputation badges. Decide who may read, whose posts appear immediately and who can hide or edit other people's contributions. These decisions affect the service you are committing to run, not just the appearance of a discussion page.

Choose the audience first

A public question board and a customer-only community are different products. Decide whether visitors can read without signing in, whether membership requires an approved relationship and whether separate groups should see separate discussions. An account alone does not necessarily prove that someone is a current customer.

The Odoo 19 forum documentation illustrates three audience settings: public, signed-in and a specified authorised group. These are product options, not a promise that a particular deployment already has the right access. Test direct links to discussions with each intended audience, including a signed-out browser.

Explain the audience near the composer. A customer should not discover after posting that a question containing order details is public. Provide an appropriate private support route rather than encouraging personal account information in shared threads.

Separate participation from moderation authority

Do you want new members' posts reviewed before other members see them? If so, name the person watching the queue and explain to the author that the post is waiting, not lost. Odoo documents a validation queue for questions and answers before they are displayed to non-moderators. That example supports the distinction between submitting and publishing; it does not establish your staffing or review deadline.

Reputation points need particular scrutiny. Odoo warns that sensitive capabilities, including editing or deleting all posts and moderation, can become available to anyone reaching the configured karma requirement. It also says karma is shared across forums and courses on one website.

For an Odoo project, review those interactions together rather than configuring the forum in isolation. For a custom community, decide whether reputation should unlock participation conveniences while moderation remains an explicitly assigned responsibility. Earning points is not, by itself, evidence that someone understands your moderation policy.

Define what a report actually does

Write separate outcomes for a member reporting a post, a moderator reviewing it and an authorised decision to hide or restore it. Do not tell the reporter that removal has happened when you have only received a report. Avoid implying that a hidden contribution has been permanently erased from every record.

Choose the reasons staff can give and what the author sees. If edits, closure or removal need a review route, make that responsibility clear. These are proposed operating rules, not legal advice or guarantees about every forum product. Have applicable content and privacy obligations reviewed separately.

Launch only with an operating owner

Bring a fictional new member, a regular contributor and a moderator to the acceptance demonstration. Submit a post requiring validation and inspect its visibility from each account. Open a direct link while signed out. Report an existing post and verify the agreed result, then exercise restoration or correction where supported.

Also demonstrate that a high participation score does not grant powers contrary to your chosen policy, including points earned elsewhere on the same site if relevant. Put the cases into acceptance criteria before commissioning the community. If nobody owns the review queue, begin with a simpler support channel rather than launching an unattended publishing promise.