在整个应用中， v 友是怎样去禁用某个用户的

[xxbutoo]

一直好奇这么个逻辑
v 友们是怎么去 禁用某个用户的？
直接在表里面加个 status 标记吗

但是这样感觉需要整个团队去了解这个字段，不然有个新来的查询的时候忘记写 status 条件了 就会出现尴尬的情况

我觉得肯定有更好的方案 只是我没想到。

[felixcode]

有个 blocked 字段不就行了，True False

[also24]

禁用状态本来就是业务相关的，特别是此用户产生的内容能被其他用户查看的时候。

比如说，一个用户被禁用后：
用户自己是能登陆但不能操作，还是直接禁止登录，还是等同于删号不存在？
用户的个人信息页是一切如常，还是加封禁标记，还是屏蔽内容，或者等同于删号不存在？
用户已经发出的评论、内容等，是一切如常还是进入锁定状态，或者直接删除相应内容？
用户已经的评论被嵌套评论，内容被评论或点赞的记录，是否还有效，操作人那里是否还能看到记录？
用户已产生的订单是否还可以操作，如果有未完成的订单是否要自动取消？
用户的私信对象是否还能查看历史记录，是否还能回复私信？
用户是否存在剩余的虚拟资产，是否提供处置方式？

我觉得这个『禁用』，还是需要产品需求方先明确定义了，才能更好的设计如何实现。
而一旦将相应的业务需求明确定义了，应该也不会存在 status 忘查询的情况（除非需求方先忘了）。

[imn1]

鉴权是必须执行步骤，如果忘了写，就是工作失误了，除非他写的部分无须鉴权

不用考虑谁有没有写的问题，而是考虑有没有手册说清楚，以及有没有相关的工作要求
然后用什么，怎么用，要看业务逻辑

[xuanbg]

用户身份认证 /鉴权有统一的入口，不存在别人不了解造成失误的情况。

[heyjei]

接口封装好后给别人调用啊。

[340244120w]

状态，创建日期，修改日期是除了 id，用户名，密码之外行业默认的必备字段了。

所以，有的人不知道这种常识，要改变的是他而不是系统🦆

[YouLMAO]

V
站被封是随机重置密码


所以



只要用 Gmail 再来重置密码，立刻复活







不要作恶，小心出门被车撞死

[xxbutoo]

@xuanbg 比如用户 id 2 的 status = 1 的表示禁用

然而有个业务类似这样 $user->where('id', 2) ->find() 吧数据查出来了

[CEBBCAT]

@YouLMAO 兄弟你想想这个叫“被封”吗？

[YouLMAO]

@CEBBCAT IP 会被封的，需要换个机场，重置密码

[xuanbg]

@xxbutoo 提供用户查询接口啊，怎么能应用自己查数据库呢？都 2021 年了，该把微服务搞起来了呀。不行就直接用我的吧……自己去我的 github 找，我就不广告了。

[badcode]

规则一旦写死
有些人就按照这个来各种破坏
还给了他 BB 的理由

---------------------以上来自 v2


个人认为，不太可能让这个规则明示，
换一句话就是，这个规则在管理层内部或者站长会根据当前的情况而定。

[also24]

@xxbutoo #8
所以说还是要看业务需求啊……

就算一个码农注意到了 status 字段，那对这个字段的用户该怎么处理，还是不知道啊。
如果需求方没有明确说明，这个业务对被封用户要怎么处理，那码农怎样越殂代疱来决定呢？

[aristolochic]

上面说到了微服务
其实单体应用也要拆分模块提供接口的
不明白为什么认为只有微服务才能解耦
任何系统大起来之后里面也不能是糊糊叭
微服务一开始就注意这些，可单体应用老油条们也各有各的解决方案
Java 的 Spring 那些不有业务层吗，不是用来干这个的？
Rails 充血模型，一开始写在模型里，后来复杂起来写在 Concern 里，再复杂一点学 Java 用 Service Object，等成熟了抽离出 Engine，就成了一个完整的独立模块
Django 的 App 应该也可以做这些（但我不太熟不好说明）

这又不仅仅是 Ban 一个用户如何实现的问题
其他涉及数据敏感的地方，也要谨慎啊

就算内部是一团浆糊，维护者需要直接访问数据，
但还有手册吧？虽然确实可能“忘记写什么东西了”，
要是 CodeReview 没有铺开也可能发现不了
但这个不是还有测试管着呢嘛
怕什么怕

[GGemini]

这种最简单的字段都能漏的人，他写的代码你敢用吗？

[dorothyREN]

密码前面加个！

[xxbutoo]

@felixcode 不是啊同学，blocked 字段和 status 字段有什么区别