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?
There is a reason I picked the number 200, the UI / DB is simply not designed for “mass” policies yet.
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.
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.
everything is possible 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.
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.
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.
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:
Which would then leave us with
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
What you just described didn’t seem “intuitive” to me at all. Bit of of the beholder there.
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?
I’m having issues with the policy plugin. Can someone confirm?
[policy group=foo](no reminder) => no accept button
policy_restrict_to_staff_postsset => 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.
What if a user mutes the topic in which the policy resides? Will they still get notifications?
Yes I think so, recommend you double check
I confirmed that if a user mutes the topic, they do still get notifications.