Discourse Policy

And here’s the fix for the green tick.

https://github.com/discourse/discourse/commit/4ad924bcf5acb6c99868887b2a402b7b5f289771

13 Likes

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.

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?

1 Like

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?

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?

1 Like

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.

1 Like

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.

1 Like

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.

7 Likes

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).

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:

4 Likes

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.

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.

5 Likes

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

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

3 Likes

This has been added now

Sam I’ve been giving this some thought. This is neat workaround for staff to enforce policy acceptance.

However it’s not exactly intuitive. It looks like a workaround and not the first thing you would think of when trying to implement a policy.

From a UI point rather than a meta commmand if this functionality was provided through the Admin panel (just like a new custom user field). You can define a new policy an set all the attributes like you’ve outlined and provide a drop down selection box where applicable like frequency etc. That would be very intuitive for staff to use.

And I love discourse because it’s intuitive :slight_smile:

1 Like

What you just described didn’t seem “intuitive” to me at all. Bit of :eye: of the beholder there.

Fair enough.

So who sets policy typically ? Staff exec, most likely Admin

So as Admin when I setup the forum where do I head to? Admin panel right?
Where do i configure the sign up policy? Admin panel.
Where do I set up custom fields for terms and conditions etc? Admin panel

Where do I configure site wide user settings? Admin panel

So logically when I want to set a “site wide” policy, where should I look?

While I basically agree with your argument, I also think that there are some other things to consider: the policy plugin is for any kind of policy, not just site wide policies. In fact, site wide policies are just a very specific use case. Its inherent logic is more about group policies, isn’t it?

Another point to consider is that (since it is based on polls) it is not really meant to strictly enforce policy in the sense of limiting access for those who don’t acceopt the policy.

Taking these into consideration helps at least to understand why the plugin is counter intuitive from the perspective of someone who wants to use it to enforce a site wide policy.

Have you looked at the the custom wizard plugin whether it might be suitable for your purpose?

5 Likes

I’m having issues with the policy plugin. Can someone confirm?

  1. [policy group=foo] (no reminder) => no accept button
  2. with policy_restrict_to_staff_posts set => no accept button? Should I be a member of group Staff, or the post have the “staff color”? AFAIK the former is true. But then the policy code does not seem to react when the reminder (optional) option is missing.

So far I tried [policy group=foo reminder=off] to work around this bug.

I think this is a great feature. Is it on your task list @sam?
A complement to this would be to be able to reject a policy, and be added to another group, e.g., for cookies, then you can skip some cookies on some group, or set cookies on another one.

2 Likes