# 认领/预订/取消认领/取消预订功能（用于代金券等） **URL:** \ **Category:** Feature\ **Created:** [2020年七月30日 11:15 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284 "2020-07-30T11:15:48Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![exetico](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/exetico/32/119962_2.png) [@exetico](https://meta.discourse.org/u/exetico)\ **Post date:** [2020年七月30日 11:15 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/1 "2020-07-30T11:15:48Z")
你好 在我们的网站上，我们不时会分享很多优惠券。所有这些优惠券都是由一个用户分享给另一个用户的。不过，有点奇怪的是，每个用户都需要发送标准的“你好，想要优惠券请私信我”，因为（优惠券/代码）是唯一的（一次性代码，或者类似的情况）。 我很希望看到这样一个功能： - A 可以发布一个优惠券，如果未被其他用户领取，该优惠券将保持隐藏状态 - B 可以领取/预留该优惠券 - B 可以（在任何时候）选择取消领取/取消预留已领取的优惠券 - A、B 和 C 都可以看到谁领取了共享的优惠券 其中： **A** = 分享代码/优惠券的人 **B** = 领取/预留代码/优惠券的人 **C** = 帖子中的其他用户，他们发现了已被领取/预留的优惠券，但可能想询问 B 该优惠券是否真的被使用了。这甚至可以是一个工具提示之类的功能，这样用户就不必直接在帖子中沟通，而是通过私信进行交流。这也能让人们追踪是否有只阅读并抓取优惠券的“潜水者”——仅此而已。 市面上有这样的功能吗？如果没有，我真心认为这应该被实现，即使不作为标准功能，至少也应作为一个插件。 需要额外注意的事项： - 允许用户将优惠券标记为“无限次”，这样所有人都可以领取，并且领取者会列在优惠券旁边。只是为了追踪/查看谁实际使用了该代码，而不是在帖子中充斥各种“谢谢”回复。措辞也可以是“谢谢，让我看看优惠券”，如果该优惠券被标记为“无限次”。 ---
**Author:** ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)\ **Post date:** [2020年七月30日 11:44 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/2 "2020-07-30T11:44:57Z")
这相当小众，不如做成插件而不是核心功能？ 如果是这样，且你有预算，不妨在 #Marketplace 发布一下。 ---
**Author:** ![exetico](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/exetico/32/119962_2.png) [@exetico](https://meta.discourse.org/u/exetico)\ **Post date:** [2020年七月30日 11:52 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/3 "2020-07-30T11:52:06Z")
遗憾的是，这里没有预算。不过，我确实能看到一些公司将其用于其他用途——这是肯定的。我们的工作人员团队都是志愿者（而且社区本身并不是商业机构，也完全不涉及商业活动）。 你说得对，关于插件。我只是无法在插件分类版块发帖，而且看起来 #Customization > Plugin 版块仅限于插件（而不是请求），但看看“插件”角色 🙂 ---
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2020年七月30日 23:38 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/4 "2020-07-30T23:38:57Z")
我不太理解这个“代金券”场景，能否提供一些现实生活中的例子，说明为什么要这样做、它的用途、目标以及它能实现什么效果？ ---
**Author:** ![exetico](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/exetico/32/119962_2.png) [@exetico](https://meta.discourse.org/u/exetico)\ **Post date:** [2020年七月31日 09:15 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/5 "2020-07-31T09:15:54Z")
## 场景 1 1. A 拥有一个免费游戏的兑换码，想要捐赠给另一位用户。（我们有一个“免费数字物品”主题帖） 2. A 使用新功能分享该兑换码。 3. B 想要获得该兑换码，点击“领取/预留”按钮。此时兑换码已推送到 B 的图形界面（GUI），B 即可使用。 4. A、B 以及 C（主题帖中的其他用户）现在都能看到该兑换码已被领取，以及是谁领取的。 在此场景中，B 无需私信联系 A 索要兑换码，其他所有用户也能看到该兑换码已被 B 领取，因此无需再向 A 发送私信。 ## 场景 2（与场景 1 类似） 1. A 拥有一个用于购买垃圾食品的 15% 折扣码，并在“折扣码”主题帖中分享。该码是唯一的，仅限一次性使用。 2. B 正在订购披萨并领取该折扣码。该码现已推送到 B 的图形界面（GUI），B 即可使用。 3. A 现在可以看到是谁领取了该折扣码，而 C（主题帖中的其他用户）无需联系 A，因为该码已显示为已被 B 领取。 ## 场景 3 1. A 拥有一个可在结账时减免 10% 价格的代码（适用于某家随机商店）。他使用优惠券功能分享该代码，并将其标记为“非唯一/可多次使用”。 2. 其他用户可以点击“谢谢，获取兑换码”。该兑换码现在会显示出来（可能需要在 DOM 中隐藏，因为它不限制为一次性使用），用户可以在结账时使用。 3. A、B 和 C 能够看到是谁领取了该兑换码（或者仅显示领取数量，具体取决于解决方案的设计）。 在这三种场景中，私信功能可以留待以后使用。所有其他用户都能看到代码是否已被领取（以及是谁领取的）。在理想情况下，这些数据还可以以其他方式在社区中使用，例如：在某个页面或主题帖的第一条帖子中列出未领取的兑换码（但这已偏离了最初的设想）。另一个好的改进是添加过期日期，甚至标题或其他信息。 ---
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2020年八月1日 00:51 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/6 "2020-08-01T00:51:59Z")
这让我觉得它与邀请系统有些相似，但用途却大不相同。 ---
**Author:** ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)\ **Post date:** [2020年八月1日 01:04 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/7 "2020-08-01T01:04:38Z")
那么，上述情况中有什么能阻止 B 大量收集优惠券呢？在分发此类代码的社区中，滥用行为屡见不鲜，机器人和恶意行为者会抓取代码用于转售和重新分发。 人为因素通常能防止此类漏洞，这难道不会重新打开这扇门吗？ ---
**Author:** ![exetico](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/exetico/32/119962_2.png) [@exetico](https://meta.discourse.org/u/exetico)\ **Post date:** [2020年八月3日 09:52 UTC](https://meta.discourse.org/t/claim-reserve-unclaim-unreserve-feature-for-vouchers-and-so/159284/8 "2020-08-03T09:52:17Z")
你说得对，某种程度上是这样 🙂 > [@Stephen](#): > > 在上述情况下，是什么阻止 B 大量收集优惠券呢？在分发此类代码的社区中，滥用行为屡见不鲜，机器人和恶意用户会抓取代码用于转售或重新分发。 没错，对于机器人来说，收集优惠券会容易得多。但我们实际上也无法真正限制这类行为。我们网站上分享的大多数优惠券都集中在同一个主题中，如果有人想这么做，机器人很容易就能收集到它们。 不过，通过让所有人查看谁使用了代码，我们至少可以追踪到谁一直在领取优惠券。 目前这还不是一个大问题，但时不时会有人使用优惠券却不通知 A 和 C。有了新方案，就能清楚地知道优惠券是否已转交给他人。而且，持有优惠券的 A 也不再需要直接与 B 联系——这将由领取系统处理，因此其他用户将看不到该优惠券。