List submitted articles of a LINE user

[MrOrz]

As discussed in 20180207

It can be used in:

• When the user is banned, other users can see what kind of article will cause one being banned
• Can have a list of article called "I submitted before"

[MrOrz]

Related discussion on slack

mrorz
關於這個功能在技術上怎麼實做，我在思考一件事情：
#65

1. 目前每個 article 都有 userId 與 appId 欄位，可以用 userId + appId 查詢到這個人之前發過的文。API 只要增加 userId 與 appId 欄位，就可以查一個人的文章。

2. appId 是預留給未來開放第三方 app 申請 appId 之後，讓第三方 app 可以在不註冊使用者的狀況下送入資料用的。目前我們 LINE bot 的 appId 是固定的一個常數值（https://github.com/cofacts/rumors-api/blob/master/src/checkHeaders.js#L8 ）， userId 則是直接拿使用者在我們 LINE channel 的 userId。

3. 問題在於如果我們想要在官網做「顯示此文作者送過的文章」功能，那我們就得要把 userId 給 expose 到外面來，例如說這個列表頁面就要拿 userId 作為 URL param 之一，並且要做成超連結放在文章頁面讓大家都能任意點入。但 userId 可能是個資的一部份；未來開放第三方 app，第三方可能會把更敏感的東西（如 email）當成 userId 傳入資料庫。

nonumpa [1 day ago]
不能直接用articleID當url param找userID和appID嗎?

mrorz [1 day ago]
有道理耶，這招不錯。

雖然會要多撈一次資料庫（在 API 裡先拿 articleId 撈 userId + appId）但我覺得不會太 costy。

拿 articleId 的另一個設計上的問題會是，這樣就只會符合「顯示此文作者送過的文章」這個 use case。不過我目前還沒想到別的應用場合，所以在現在這個時間點使用 articleId 會是個相當合適的解。

nonumpa [1 day ago]
後來想想正確的解法應該是要避免 userId 用敏感資料來表示。
這樣如果未來用會到email的話，就要再建一張 userId 對應email的表，或是連line_userid也一併重建進去，但這感覺又是一個大工程。 (edited)

mrorz [1 day ago]
其實如果是網站的使用者（有經過 FB / Twitter / Github 註冊），就會記在 users 資料表裡了，此時 userId 是 users 資料表的 ID，不是敏感資料。不過 LINE 的使用者（ userId + appId）是沒有在 users 資料表裡的。

之後如果有要在網站上加入 LINE login 的話（看看能不能把 chatbot user 與 editor 連起來），就會採用在 users 資料表新增 line user id 欄位的方式。 (edited)

[MrOrz]

From the discussion above, I will add 3 filter parameters to article list to list all articles of a specific sender.

• appId
• userId - The above 2 must be used in pairs.
• fromUserOfArticleId - selects only the articles sent from the sender of the specified article ID

[MrOrz]

Deployed to staging https://cofacts-api.hacktabl.org/