support set visibility(public/private/friend) for post

[alimy]

• support set visibility(public/private/friend) for post

simple implement for #93.

支持特性:

• 发表文章时可以设置文章可见性(公开/私密/好友可见)；
• 广场文章列表 只显示 公开/好友可见 文章；
• 用户主页显示 公开/好友可见 文章；
• 拥有者主页显示 公开/私密/好友可见 文章；
• 搜索索引 目前只索引 公开/好友可见 文章， 需要后续完善；
• 管理员可以查看用户主页的 公开/私密/好友可见 文章；
• 由于目前还没有 好友 功能，默认你与全世界都是好友，所以好友可见的文章 等效于 公开 可见的文章，后续如果加入好友体系或者关注者体系再来优化完善；

目前状态？
简单的初步实现。 前端UI是瞎折腾出来的(我不是前端开发，业余瞎搞)～ 需要优化完善。

技术预览状态，建议先不要合并到主线，考虑是否需要这个功能 并 优化完善后 再合并到主线。

如何测试预览?
在feature/post-visibility分支有完整代码提供测试预览。

git switch feature/post-visibility
cd web && yarn && yarn build && cd -
make run TAGS='embed'

[alimy]

如果有运行的现成数据库，

• mysql 需要执行scripts/migration/mysql/001-2206131310.sql
• sqlite3 需要执行scripts/migration/sqlite3/001-2206131310.sql

新数据库：

• mysql执行 scripts/paopao-mysql.sql , scripts/migration/mysql/001-2206131310.sql
• sqlite执行 scripts/paopao-sqlite3.sql , scripts/migration/sqlite3/001-2206131310.sql

[orziz]

这个功能是很好的，之前也想过是否要加

[rocboss]

想法和实施速度都很赞👍🏻

[alimy]

快速测试预览方法:

%> git clone github.com:rocboss/paopao-ce
%> cd paopao-ce
%> docker compose up -d --build
# visit paopao-ce(http://127.0.0.1:8008) and phpMysqlAdmin(http://127.0.0.1:8080)

[orziz]

新增了修改已发布动态的可见度，入口同 删除、锁定、置顶

[alimy]

新增了修改已发布动态的可见度，入口同 删除、锁定、置顶

nice~

[alimy]

新增了修改已发布动态的可见度，入口同 删除、锁定、置顶

nice~

优化完善了一下， 添加tag处理、搜索索引的处理，但是暂时没有处理@, 在考虑 这种重新修改推文可见度的场景还需要去处理 @ 吗， 这里我偏向于放弃处理，因为：

1. 可能推文已经很长时间发的，突然某个时间心血来潮就公开了，这种@他人关注这条推文是否有点唐突？
2. 或许可以精细化处理， 判断一下推文最后发布时间，在一定时间内的话就去处理 @
   目前暂时没去处理@， 想想再说～

[rocboss]

优化完善了一下， 添加tag处理、搜索索引的处理，但是暂时没有处理@, 在考虑 这种重新修改推文可见度的场景还需要去处理 @ 吗， 这里我偏向于放弃处理，因为：

1. 可能推文已经很长时间发的，突然某个时间心血来潮就公开了，这种@他人关注这条推文是否有点唐突？
2. 或许可以精细化处理， 判断一下推文最后发布时间，在一定时间内的话就去处理 @
   目前暂时没去处理@， 想想再说～

不建议对“@”做过多处理，甚至编辑推文的操作也只在一定范围时间内开放，过了一段时间后就不允许编辑了，原因基本同1，目前paopao的这种产品形态其实还是比较注重实效性的，所以重新编辑的能力可以一定程度上弱化

[alimy]

新增了修改已发布动态的可见度，入口同 删除、锁定、置顶

nice~

优化完善了一下， 添加tag处理、搜索索引的处理，但是暂时没有处理@, 在考虑 这种重新修改推文可见度的场景还需要去处理 @ 吗， 这里我偏向于放弃处理，因为：

1. 可能推文已经很长时间发的，突然某个时间心血来潮就公开了，这种@他人关注这条推文是否有点唐突？
2. 或许可以精细化处理， 判断一下推文最后发布时间，在一定时间内的话就去处理 @
   目前暂时没去处理@， 想想再说～

忘了查询到的post没有带@ 信息， 需要的话还得重新解析处理，麻烦的一批～ 又一个 不管它 的借口～

[alimy]

不建议对“@”做过多处理，甚至编辑推文的操作也只在一定范围时间内开放，过了一段时间后就不允许编辑了，原因基本同1，目前paopao的这种产品形态其实还是比较注重实效性的，所以重新编辑的能力可以一定程度上弱化

我也这么想， 怎么简单怎么来～

[orziz]

确实艾特也是一个问题。但是我在想，既然是私密的，那么艾特也不应该提醒才对，或者说，转为公开或者好友可见的时候再推送艾特消息

[alimy]

确实艾特也是一个问题。但是我在想，既然是私密的，那么艾特也不应该提醒才对，或者说，转为公开或者好友可见的时候再推送艾特消息

来个二八原则， 以修改推文可见性为相对而言比较少见的操作为前提，对这个功能就没必要过度设计，或许以后有时间再回过头来卷这个功能。原则上是可以精细化处理艾特的:

1. 在短时间内(比如5分钟内)修改可见性从 私密 转为 非私密，则处理一下艾特；
2. 短时间内（比如5分钟内)修改可见性从 非私密 转为 私密，也处理一下艾特，反向收回艾特（这里又要实现一个反向收回艾特的逻辑处理）；
3. 长时间的可见性修改，静默艾特处理；
4. 由于推文可见性修改在现实中应该是属于稀少操作，不是特别频繁，所以这个操作接口带给后端 服务器的压力不会很大，对时延的要求不是很高，只要按意图完成操作即可，所以后端内部对这个接口多做一些繁琐的工作还是可以承受的；
5. 推文可见性修改，短时间/长时间内 操作对于用户而言都有需求的，也许用户只是平时记录一下当时所想，记录收藏一下有趣推文，但是当作私密推文暂时收藏在paopao-ce，也许某个心血来潮就想公开分享其中一些私密推文，所以在UI/UX上就允许任意时间更新推文的可见性；
6. *** 艾特功能的处理有点繁琐， 这个版本就不引入了，有待另一个PR去完善这个功能；***

[orziz]

确实艾特也是一个问题。但是我在想，既然是私密的，那么艾特也不应该提醒才对，或者说，转为公开或者好友可见的时候再推送艾特消息

来个二八原则， 以修改推文可见性为相对而言比较少见的操作为前提，对这个功能就没必要过度设计，或许以后有时间再回过头来卷这个功能。原则上是可以精细化处理艾特的:

1. 在短时间内(比如5分钟内)修改可见性从 私密 转为 非私密，则处理一下艾特；
2. 短时间内（比如5分钟内)修改可见性从 非私密 转为 私密，也处理一下艾特，反向收回艾特（这里又要实现一个反向收回艾特的逻辑处理）；
3. 长时间的可见性修改，静默艾特处理；
4. 由于推文可见性修改在现实中应该是属于稀少操作，不是特别频繁，所以这个操作接口带给后端 服务器的压力不会很大，对时延的要求不是很高，只要按意图完成操作即可，所以后端内部对这个接口多做一些繁琐的工作还是可以承受的；
5. 推文可见性修改，短时间/长时间内 操作对于用户而言都有需求的，也许用户只是平时记录一下当时所想，记录收藏一下有趣推文，但是当作私密推文暂时收藏在paopao-ce，也许某个心血来潮就想公开分享其中一些私密推文，所以在UI/UX上就允许任意时间更新推文的可见性；
6. *** 艾特功能的处理有点繁琐， 这个版本就不引入了，有待另一个PR去完善这个功能；***

我倒觉得其实没必要想这么复杂。相对来说，任何时候，从私密改到了非私密，被艾特的应该都能收到回复，这是可以接受的，毕竟这是人家提醒我去看，发布时间来说其实都还好。
至于非私密转私密，其实也不用收回，大不了点进去就是无权查看或者404罢了（同github的private项目），这其实是可以接受的。
只是有一个需要注意，那就是发布本来就是非私密的，然后转私密了，再转非私密，这里就不应该再推送艾特了，只有第一次非私密的时候推送。也就是说，一条推文，一个用户只会收到一次推送，不管发布者转了几次的私密非私密。

[alimy]

至于非私密转私密，其实也不用收回，大不了点进去就是无权查看或者404罢了（同github的private项目），这其实是可以接受的。

嗯， 这样处理也尚可～

只是有一个需要注意，那就是发布本来就是非私密的，然后转私密了，再转非私密，这里就不应该再推送艾特了，只有第一次非私密的时候推送。也就是说，一条推文，一个用户只会收到一次推送，不管发布者转了几次的私密非私密。

这种魔幻操作我倒一时没注意到， 确实需要保证艾特提醒只能推送一次, 不过这也不难解决～

[orziz]

至于非私密转私密，其实也不用收回，大不了点进去就是无权查看或者404罢了（同github的private项目），这其实是可以接受的。

嗯， 这样处理也尚可～

只是有一个需要注意，那就是发布本来就是非私密的，然后转私密了，再转非私密，这里就不应该再推送艾特了，只有第一次非私密的时候推送。也就是说，一条推文，一个用户只会收到一次推送，不管发布者转了几次的私密非私密。

这种魔幻操作我倒一时没注意到， 确实需要保证艾特提醒只能推送一次, 不过这也不难解决～

简单一点，没必要想得太复杂

[orziz]

想了想，各种类型的处理还是用枚举做，这样方便于管理

[orziz]

想了想，各种类型的处理还是用枚举做，这样方便于管理

之前的类型修改也全部放到这个版本里面了，以防冲突，到时候一起合并吧

[orziz]

如果差不多的话，就可以合并一个版本了

[alimy]

如果差不多的话，就可以合并一个版本了

+1 @rocboss