Discourse Policy


(Sam Saffron) #1

Discourse Policy

Location: GitHub - discourse/discourse-policy


What it does?

Discourse policy shares much of its DNA with polls, it has the goal of ensuring members of a group accept certain policies by clicking a button.

It has some specific features that set it apart from polls:

  1. It must apply to a group (the group must not exceed 200 users)

  2. It can optionally nag members of a group either weekly or daily to click accept on a policy

  3. The UX makes it very easy to see who accepted and who did not accept a policy.


Before clicking accept

After clicking “grey” person on top right

After clicking accept

Creating a policy

Discourse policy registers a custom [policy] BBCode element.

[policy group=founders reminder=daily]
I accept this policy will annoy me daily until I click accept

In this case the policy applies to the founders group and a reminder is sent daily to all users that did not accept the policy.

Site settings

policy_enabled : is the discourse policy plugin enabled on the site.

policy_max_group_size : only allow policies on groups smaller or equal to this size (default 200)

policy_restrict_to_staff_posts: policies may only appear on staff posts

BBCode attributes

The [policy] element can accept the following attributes.

  • group: the group name that policy will apply to required
  • version: the version number of the policy, bump number up to require all users re-accept the policy
  • reminder: remind users of the group to accept policy (weekly or daily), optional, default off
  • accept: text used for accept button, default is “Accept Policy”
  • revoke: text used for revoke button, default is “Revoke Policy”
  • renew: number of days after which a user needs to re-accept policy


  • Optional immediate reminder for new policies
  • Possibly allow certain groups to apply policies (expanding on staff)

Have-to-read topics? (or RSVP topics)
Custom Wizard Plugin
How to make users to explicitly agree to ToS
Creating a Task List plugin
(Christoph) #2

So how exactly does this work? When the plugin is activated I can include the following in any post?

And then the people in the selected group will get a popup whenever they are first seen every day? Or a PM? Or when they enter the topic?

Is it possible to customize the text on the accept button on a per policy basis?

In some use cases it would also be nice (for legal reasons) to have a record of when each user accepted/revoked the policy. Are those times already logged somewhere?

(Sam Saffron) #3

Yes as long as the post is owned by staff.

It is a standard notification, only appears on the website and mobile app. Looks exactly the same as topic reminders.

Now you can :slight_smile:

(updating the doco above)

This is already stored with the custom field so you should be able to dig it up via data explorer, it is not trivial to add this as a tooltip due to performance reasons, but I am considering it.


This is great. :innocent:

My two cents here: Translation to Spanish by SidVal · Pull Request #1 · discourse/discourse-policy · GitHub


Thank you. :coffee:

On Discourse and Discourse Policy is missing the green tick.

- git clone https://github.com/discourse/discourse-policy


- git clone https://github.com/discourse/discourse-policy.git

What is the right installation?

(Sam Saffron) #6

Ahh green tick will be there a bit later … we need to add it to our official plugin list. Your repo is fine either way.

(Joshua Rosenfeld) #7

And here’s the fix for the green tick.

(RBoy) #8

Is there a way to have the policy only apply to people who signed up before a specific date?
I’m taking a cue from GDPR, new users need to accept the policy before they sign up, existing users need to accept the policy. By combining sign-up date and version one can strive for compliance without burdening new users with a duplicate acceptance.

(RBoy) #9

Can we set this to 0 to indicate no limits? Essentially if we want the post to apply to users in group “everyone” then how do we handle this scenario?
What would happen if there are more users in the group than the limit specified here?

(Christoph) #10

What happens if I create a policy for a larger group without adjusting the setting to fit the group size? I assume the plugin simply won’t notify people. My point is: isn’t there a risk that people create policies for large groups without realizing that people are not being notified?

(RBoy) #11

Consequently what happens when more people join the group and the group size gets larger than the specified limit? Do new folks get the notifications?

(Sam Saffron) #12

There is a reason I picked the number 200, the UI / DB is simply not designed for “mass” policies yet.

In particular

  • We use post custom fields here which do not scale to 200 thousand rows per post, we would need a dedicated table

  • The UI displays all the users and clearly 200k users in one post is going to be a problem

  • The UI shows counts, so we would need to ship them by hand

Another giant issue is how do we deal with people who simply refuse to accept, keep nagging them forever?

I am open to redesigning internals here to support larger policies, but it is going to take a bit cause for starters we need a dedicated model here.

At the moment they will still get notifications till the post is rebaked.

(RBoy) #13

Can there be an option to block usage until they accept? i.e. only show that post until they accept and don’t allow them to browse until they accept or if they refuse?

Alternatively put an expiration on the number of times to be shown; it would correlate with the option on how often to show, e.g. reminder=daily times=0-xxx (0 mean forever)

Is there an option now to show users? Click to open a new page to view details and just show the summary/count instead.

(Sam Saffron) #14

everything is possible :slight_smile: almost…

I would not “block usage”, but I am toying with the idea of “gluing” this to groups, so once you accept certain policies you are automatically added to a group. That would provide a solution for this problem. Possibly use a different element altogether for it like:

[group_policy applies_to=trust_level_1 group=acceptors reminder=weekly max_reminders=10]

Then as people accept the policy they will automatically become members of the acceptors group and we get to simply reuse all the groups ui.

I do like the idea of have a max reminders here and group policy seems to solve the enormous policy problem.

(RBoy) #15

Not really clear on how this helps. What can we do with this group?

Why not? If there is a critical change to policy (for e.g. GDPR) and it requires users to explicitly accept or agree to the terms and if they don’t agree, the forum should be blocked from usage (they don’t comply with the revised requirements).

(Sam Saffron) #16

Well, with groups this is achievable anyway.

You grant access to “GDPR madness” group for people who accept the policy.

Then set it so only “GDPR madness” group has write access to your categories.

Problem solved :exploding_head:

(RBoy) #17

Correct but there’s no way to not “see”, i.e. prevent read access to categories which would make it GDPR non compliant since by browsing the forum, it is still collecting information about the user right?
I don’t want to make this discussion GDPR specific but trying to see how it can apply to a general “policy” level, GDPR is just a good example at the moment. The policy may be simple, until you’re a registered member we don’t want you to access the forum or until you agree to the updated policy you aren’t welcome to use the service.

(Sam Saffron) #18

hmmm yes there is… you set up a single category with a single topic which is the policy topic.

rest of the forum only people who “accept” the policy can access.

(RBoy) #19

:facepalm: now why didn’t I think of that, a bit of a twist but yes I see it now.

(Christoph) #20

Okay, so it’s even more than a default, it’s a “we strongly recommend not to use this on larger groups”, right? Maybe that should be mentioned in the OP?

I see that this has been inherited from polls, but is it necessary? I wouldn’t expect that kind of behaviour for this plugin. Maybe it can be an option show_users which is off by default?

Actually, the same applies to

But I think it could be a single option to turn on both: show_accepted maybe.

Which would then leave us with