1樓：紅秀招
乙個需要流轉管理的系統，不論是給內部使用，還是合作夥伴用，都不可避免的遇到乙個問題：如何應對不同流轉過程的帳號及帳號對應的許可權設計
如果我們把流程寫死了，以應對乙個甲方，一旦產品需要拓展市場化，各個部門和合作關係，則需要靈活配置，以便軟體系統能夠應付。
常用的帳號及許可權，市面上都已形成規範化。
諸如訂單系統、服務管理系統、SCM系統等往往在乙個發起單後，經歷不同的崗位（部門）進行流轉，通過普通的方式往往很難滿足：
以下是一種設計思路：
1新建帳號
2帳號管理
3許可權組合管理：新建乙個許可權組，並且將各種許可權中該流轉中需要的許可權進行統一配置
4帳號對應的許可權組
對起單的型別做統一設定，針對該型別，定義不同的流程
2 設定該流程對應的帳號
PS：通常情況下，帳號的流與許可權設定，往往是分開的。這樣導致在使用配置過程中，存在滯後不夠靈活，用許可權組合的方式，固定住帳號的實際許可權；又通過狀態流對應的許可權，來固定每個帳號對應的流程許可權。
達到的效果：
每個表單的流程對應的許可權是不一樣的，即不同帳號看到的表單是不一樣的
每個帳號對應的操作許可權又以許可權組合的能力為準
示例：起單的帳號，只能操作起單
示例：審批的帳號，只能操作審批
詳情請檢視，如何設計流轉產品的系統許可權
我有乙個志向，建立乙個「瘦」產品的群，主要是解決產品設計中的乙個瘦弱的部位（PM應該放棄只關注風口的高尚大的玩意，應該腳踏實地做產品）
QQ群：66805777
關於系統許可權設計 主要是邏輯結構的問題。？
紅秀招 乙個需要流轉管理的系統，不論是給內部使用，還是合作夥伴用，都不可避免的遇到乙個問題 如何應對不同流轉過程的帳號及帳號對應的許可權設計 如果我們把流程寫死了，以應對乙個甲方，一旦產品需要拓展市場化，各個部門和合作關係，則需要靈活配置，以便軟體系統能夠應付。常用的帳號及許可權，市面上都已形成規範...
知乎是否需要對修改問題許可權做一些限制？
自言臣是酒中仙 必須要做出限制啊。我覺得問題本來就是提問者個人的思考，如果引起較多人的共鳴，回答者眾多，也是好事。但是如果誰都可以隨便改問題，那真是太好玩了。有乙個遊戲叫隨便改問題，然後下面的很多付出心血的回答，變成了不明所以，不知所答。不允許非提問者修改是最好的辦法。如果是提問者自己修改，如果有了...
物件導向設計 表設計 OR的一些疑問
查了一些資料，補充一下 其實不用太過糾結物件設計的是否符合OO，比如不是說User與Message是1v多關係，就一定要在User中加入List messages這樣的屬性來表示這種關係。而要秉承幾個原則 1.實現簡單且符合業務需求。2.模組化。3.靈活性。4.易於擴充套件。比如在上面的User與M...