# 投票门控？
**URL:** https://meta.discourse.org/t/poll-gating/258802
**Category:** Support
**Created:** [2023年三月20日 20:09 UTC](https://meta.discourse.org/t/poll-gating/258802 "2023-03-20T20:09:27Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Icedcool](https://meta.discourse.org/u/Icedcool)
#### Post date: [2023年三月20日 20:09 UTC](https://meta.discourse.org/t/poll-gating/258802/1 "2023-03-20T20:09:28Z")
您好，Discourse 社区！
我是一个托管 Discourse 的用户，我们希望根据用户角色或标签来限制投票（理想情况下是 Discord 提供的角色）。
是否有插件或方法可以实现此功能？
感谢所有帮助，
Iced
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2023年三月20日 20:31 UTC](https://meta.discourse.org/t/poll-gating/258802/2 "2023-03-20T20:31:54Z")
我们的投票功能已内置此功能。您可以使用构建器限制谁可以投票，如下所示：
---
### Author:  [@Icedcool](https://meta.discourse.org/u/Icedcool)
#### Post date: [2023年三月20日 21:08 UTC](https://meta.discourse.org/t/poll-gating/258802/3 "2023-03-20T21:08:47Z")
太好了！
使用 Discord 登录功能，可以导入 Discord 中的角色吗？
再次感谢，
Iced
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2023年三月20日 21:17 UTC](https://meta.discourse.org/t/poll-gating/258802/4 "2023-03-20T21:17:08Z")
> [@Icedcool](#):
>
> 使用 Discord 登录功能，可以从 Discord 导入角色吗？
Discord 登录代码尚不处理角色到 Discourse 群组的映射。这是一个我们欢迎代码贡献来处理的功能，因为 Google 身份验证中已存在类似的模式。
---
### Author:  [@Icedcool](https://meta.discourse.org/u/Icedcool)
#### Post date: [2023年三月21日 22:00 UTC](https://meta.discourse.org/t/poll-gating/258802/5 "2023-03-21T22:00:26Z")
好的。
您能否参考现有的 Google 身份验证模式？
我的一些开发人员可能对此感兴趣并愿意贡献。
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2023年三月21日 22:22 UTC](https://meta.discourse.org/t/poll-gating/258802/6 "2023-03-21T22:22:33Z")
>
>
> Update on #12446.
>
> @davidtaylorhq A draft for an update on the associated grou…p membership work. It's been rebased, brought in line with the latest changes and updated in the ways explained below. Let me know if you're onboard with the approach so far. I'll finish it off next weekend.
>
> \### Authentication and group retrieval
>
> I've removed the secondary auth stuff, added a google-hd-specific boolean setting, and moved the group retrieval into a new google oauth2 omniauth strategy. I've made a new folder and added a spec for the strategy (something new in the codebase) as I thought it deserved a spec (which is also included). If we add in secondary auth to this strategy that too will need a spec. Some of the existing discourse omniauth strategies, e.g. Discord, may benefit from being seperated out and tested too.
>
> \### Group Provision and UI
>
> As suggested, I've added a \`\`provides\_groups?\`\` to the \`\`Auth::Authenticator\`\`. Using this approach led to a new groups guardian method to use at the various group CRUD points. Speaking of which, I've added in support for group\_associated\_group creation in group creation (i.e. \`\`/g/custom/new\`\`). Supporting it in both \`\`new\`\` and \`\`manage\`\` (update) also led to adding a new site attribute \`\`can\_associate\_groups\`\`. I attempted to make this more group-route specific, however this leads to various clumsy workarounds to determine whether an admin can associate groups in \`\`/g/custom/new\`\`. The site attribute approach proved the simplest and most performant (i.e. fewer ajax calls).
>
> \### Data model
>
> I've made one change to the data model so far, namely to use \`\`after\_commit\`\` hooks rather than \`\`after\_create\`\`/\`\`after\_destroy\`\` as using those hooks leads to duplicate record creation in \`\`Admin::GroupsController\`\` \`\`create\`\`. I've yet to deal with the edge case you pointed out, i.e. multiple UserAssociatedGroups which link to the same group.