NocoDB 權限與協作教學：誰能看、誰能改

一個人用的時候，權限是多餘的。

但只要多兩個人，問題就會出現：有人不小心改了篩選條件、有人看到不該看的成本欄位、有人刪了一整欄還沒人發現。

這篇講怎麼在事情發生前把界線設好。

30 秒總覽

實務上最重要的一條界線是 Creator 和 Editor 之間：能不能改結構。

為什麼結構權限要收緊

改資料錯了看得出來——那一格的值不對，可以改回去。

改結構錯了很難發現。有人把一個欄位型別從數字改成文字、或把某個檢視的篩選條件動了一下，畫面看起來一切正常，只是數字開始對不上，而你要好幾天後才注意到。

所以預設給 Editor，只有真的需要調整資料表的人才給 Creator。

檢視鎖定：比角色更細的保護

角色是整個 base 層級的。但常見的需求是「這個檢視大家都能用，但不要被改壞」。

鎖定檢視之後，其他人可以看、可以在裡面編輯資料，但改不了這個檢視的篩選、排序與欄位設定。

對共用的工作檢視，建議一律鎖定。被改掉的篩選條件是那種「沒有人承認、也沒有人發現」的問題。

公開連結：最容易出事的地方

檢視可以產生公開連結，不需要帳號就能看。方便，但有三個要注意的：

第三點最容易出事：你以為隱藏了成本欄位，但那是在別的檢視隱藏的。開公開連結之前，用無痕視窗自己開一次連結看看實際長什麼樣，這一步花不到一分鐘。

表單是最安全的對外方式

如果目的只是「讓外部的人填資料」，用表單檢視，不要開公開的表格檢視。

表單只能寫入不能讀取——填的人看不到既有資料。這是收集資料時預設該用的方式。

API Token 也是權限

NocoDB 每張表都有 REST API，而 API Token 等於一把不會過期的鑰匙。

• 每個用途發一把——n8n 一把、網站表單一把。這樣要撤銷時不會影響其他系統
• 不要寫進前端程式碼——那等於公開
• 離職或專案結束就撤銷

串接的做法在 API 快速上手那篇。

多人協作的實際建議

先想「誰要看什麼」，再開檢視

按角色開檢視，比按功能開有用。業務看自己的客戶、主管看全部加金額排序、其他部門只看狀態。

結構改動要有一個人負責

不是權限問題，是習慣問題。資料表的結構應該只有一個人能改，其他人有需求跟他說。這比事後追查誰改了什麼容易得多。

刪除比修改危險

改錯還原得回來，刪掉就沒了。給 Editor 權限的時候要意識到那包含刪除資料列。

一個實際的權限規劃

五人團隊的客戶資料庫，實務上會這樣分：

兩個關鍵決定：主管給 Viewer 不給 Editor（他不需要改，而誤改的成本很高），以及自動化用獨立 Token 不共用（要撤銷時不會影響別的系統）。

權限之外，更常見的是習慣問題

誠實講：多數協作問題不是權限設錯，是沒有講好誰負責什麼。

三件比權限設定更有效的事：

• 結構改動指定一個人——其他人有需求跟他說，而不是自己動手
• 共用檢視一律鎖定——被改掉的篩選是最難發現的問題
• 定期看一次公開連結清單——那些連結不會自己過期

常見問題

Q：可以做到欄位層級的權限嗎？

透過檢視隱藏欄位可以達到類似效果，但那是呈現層的控制，不等於嚴格的資料權限。如果你的需求是「這個欄位絕對不能被某些人看到」，那應該把資料拆到不同的表或 base。

Q：怎麼知道誰改了什麼？

紀錄層級有異動歷程可以查。但這是事後追查，不是預防——比較有效的做法還是把結構權限收緊。

Q：外部合作夥伴要看資料怎麼辦？

建一個只含必要欄位與篩選的檢視，設密碼後分享連結。不要為了這件事開帳號給他，帳號的權限範圍比你想的大。

Q：公開連結可以追蹤誰看過嗎？

公開連結本質上是匿名的。需要知道誰看了什麼，就得走帳號登入的方式。

離職或專案結束的檢查清單

這是最容易漏掉的一環，因為它不像設定權限那樣有明確的觸發時機。

第二列是實務上最常出事的：帳號停用了，但他寫的自動化還在用一把沒人記得的 Token 讀寫資料。這也是為什麼建議每個用途發一把獨立 Token——至少你知道那把是誰的、做什麼用的。

資料來源與延伸連結

• NocoDB 角色與權限官方說明——各角色的完整能力對照
• NocoDB 官方文件
• NocoDB 原始碼與版本紀錄

延伸閱讀

• NocoDB 檢視教學：表格、看板、日曆與表單怎麼用
• NocoDB API 快速上手：取得 Token、讀寫資料表、串接自動化
• 用 NocoDB 當 CRM：什麼時候夠用，什麼時候該換掉
• NocoDB 常見問題：API 串接、資料量與多人協作
• RoamerHost NocoDB 託管方案