search

Ptt-official-app / Ptt-backend

PTT APP 的後端
BSD 3-Clause "New" or "Revised" License
208 stars 67 forks source link

[主線] [PTT] 實作上下箭頭推文 #210

Open titaneric opened 3 years ago

titaneric commented 3 years ago

實作細節 / Details of Implement

Quote from Pichu:

在放入 user01 Access Token 的情況下，發出一篇文章，user02 可以用 「↑」進行推文，評價數要加一，user02第二次用 ↑ 推文時評價數不變 接著user02 用 「↓」推文時原先的上箭頭推文被刪去，評價數減一（收回），第二次用 ↓ 推文時評價數減一，第三次用↓推文時評價數不變 在放入 user01 Access Token 的情況下，發出一篇文章，user01 用 「↑」進行推文，評價數不變 （自己不能推自己）

  • 修改usecase /article.go
  • 增加類似UpdateUsefulness function，以模仿stackoverflow或reddit
  • 在repository/article.go中新增Usefulness struct，與後端gobbs對接
  • 在delivery/http新增route_update_usefulness.go處理http routing
  • 可能會有權限問題需要處理
  • 對應測試需要撰寫

    期程 / Schedule

備註

wagaru commented 3 years ago

嗨，想幫忙這個 issue，但想確定一下結節…

  1. 這個+1-1的計算看起來應該是在 ptt-backend 這邊計算，然後判斷執行+1/-1的 user 跟文章作者是否是同一人，再決定+1/-1的行為 2.透過 gobbs 提供的 public interface 取得目前的推文總數，計算完後再透過另一個 gobbs 的 public interface 更新

然後現況是目前 gobbs 還沒有相關的實作，並且 Google DOC 也還沒有這個 endpoint 對嗎？

titaneric commented 3 years ago

@wagaru 目前是這樣沒錯唷，我剛把Google Doc那邊註記，如果有更新你可以依照spec實作

PichuChen commented 3 years ago

嗨，想幫忙這個 issue，但想確定一下結節…

  1. 這個+1-1的計算看起來應該是在 ptt-backend 這邊計算，然後判斷執行+1/-1的 user 跟文章作者是否是同一人，再決定+1/-1的行為

差不多

2.透過 gobbs 提供的 public interface 取得目前的推文總數，計算完後再透過另一個 gobbs 的 public interface 更新

對

然後現況是目前 gobbs 還沒有相關的實作，並且 Google DOC 也還沒有這個 endpoint 對嗎？ go-bbs 相關的實作要等 https://github.com/Ptt-official-app/go-bbs/issues/82 這個完成，知道目前推文數以及修改推文數的應該直接呼叫文章屬性相關的函式就行了？ 目前 google doc 使用原有的推文，type 改成上下箭頭 ↑ ↓

golopot commented 3 years ago

我想詢問一個實做細節，因為推文數的計算有一個規則是「使用者在文章的推數影響最大 +1 最小 -1」，所以實做時需要使用當前使用者在這篇文章的推噓數，那麼這個數字要從何計算？

  1. 解析文章的推文部份，解析出屬於當前使用者的推文來計算。這個作法的漏洞是文章作者可以編輯推文段落，使得最多 +1的規則無法落實。
  2. go-bbs 提供這篇文章所有推文列表結構，以此計算。問題：go-bbs會提供這個結構嗎？
  3. 其他方法？
PichuChen commented 3 years ago

在.DIR檔案裡面有紀錄文章目前的推文數

PichuChen commented 3 years ago

關於上下箭頭部分，我認為可以先求有再求好。

在原本 BBS 的設計中有 recommend 來表示推文數，然後這個推文數和上下箭頭的數字是分離的。

所以先求有再求好的狀況就是直接抓內文然後去統計上下箭頭的數量，暫時先不考慮做假的狀況。

也就是流程上就是 （在usecase）

  1. 抓內文
  2. 抓到\n↑ \n↓
  3. 抓出ID ，統計該ID的上下狀態
  4. 加總

這樣。

nickyanggg commented 3 years ago

也就是流程上就是 （在usecase）

  1. 抓內文
  2. 抓到\n↑ \n↓
  3. 抓出ID ，統計該ID的上下狀態
  4. 加總

這樣表示目前我們打算將使用者按上下箭頭的紀錄當成一般推文一樣直接寫進 filename 底下嗎？

PichuChen commented 3 years ago

對，這樣可以比較簡單的做到向下支援