GitLab: 记录一个循环的功能增强

GitLab提供了管理用户修改其他人的密码的功能，这给使用GitLab进行功能集成的使用者带来了方便，但是同时该功能确实可能存在隐患和可能引起混乱的地方，于是给此功能添加了一个特性，就是必须修改密码后下次登录必须强制修改密码。于是这引起了很多其他的问题，于是又打开了一个Issue改回去或者说部分改回去，这篇文章来一起看一下这些Issue和对应。

Issue：13691

• 13691 标题：Allow admin to reset user password and force password reset on next login。标题写的非常清楚，允许admin重设其他用户的密码，被修改了密码的用户下次登录的时候就应该强制密码重设。

首先，作为维护者给出了两种方式，是否应该有个复选框让用户决定，还是直接替用户决定，这就是最佳实践。 被@的回应是：强制重设吧 还有一个回应是：always force 当时还有个路人甲John Stephen赞同了checkbox，被忽视了。 然后John Stephen认为，从Web上操作和API操作结果不一致也是一个问题，再起一个Issue吧

Issue：24606

• 24606 标题：Force password reset on next login when change password through API

John Stephen在上述Issue的基础上创建了24606 然后正常关闭，就是一个简单的特性增强的示例，如果没有后面的Issue的话。

Issue：61587

标题：Why Force new password after password reset via API。为什么使用Password通过API设定密码之后需要强制密码重设？原因就是前面的Issue的标题和增强的特性的内容，这就是最佳实践吧。

Issue：36412

标题：Do not force password reset on next login when change password through API。简单来说就是之前的Issue对应的特性删除掉。

Issue：19141

标题：Do not force password reset on next login when change password through API。类似的Issue还有很多，因为19141的状态为Open，所以其他都关闭了，但是这个三年前开的，现在还没有关闭，三年前刚好24606的Issue关闭了。所基本上从某种程度上来说是一个很具争议性的Issue或者对应方式很具争议性。

实际上确实有很多人都有类似的问题，比如 再比如 然而，状态还是Open。

总结

开源，前向兼容有的时候就会有这个问题，考虑太多，自己很痛苦，考虑太少，用户很痛苦。慢慢来，习惯就好。

参考文档

https://gitlab.com/gitlab-org/gitlab-foss/-/issues/24606 https://gitlab.com/gitlab-org/gitlab-foss/-/issues/13691 https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61587 https://gitlab.com/gitlab-org/gitlab-foss/-/issues/36412 https://gitlab.com/gitlab-org/gitlab/-/issues/19141