Dynamics CRM - 如何修复 Access Is Denied,ObjectTypeCode: 2500 的错误
? ? ? 最近被 Dynamics CRM 的權限配置問題惡心了一個星期,老是報“Access Is Denied”,幾經波折,最后終于找到一個比較合適的解決方案,寫個博客 mark 下來,方便以后查看。
首先,介紹一下權限設置的要求:
? ? ? 1.在根 Business Unit 下建立好 Security Role,并根據文檔要求賦予 Sense Role 相關 Entity 及 CRM 系統的操作權限;
? ? ? 2.建立多個 Team,每個 Team 都有各自的權限配置,給 Team Role 賦予不同的 Security Role;
? ? ? 3.創建 User,但是不給 User Role 賦 Security Role,而是直接將 User 加到 Team 中,這樣 User 也可以得到與 Team 相同的權限(但這個并不是User本身擁有的權限)。
?
然后,我來描述一下 Bug 是怎么產生的:
? ? ? 當我按照需求設置好 Security Role 的各種權限并添加完 Team 和 User 后,開始使用這些 User 在 CRM 系統上進行測試,當我測試完某個 Entity 的 BPF(Business Process Flow),返回到列表視圖后,再次雙擊 Record 想進來再查看的時候,開始報錯,如下圖所示:
圖1 Access Is Denied
?
? ? ? Acess Is Denied? 此時的我???Ok,這條 Record 進不去,那我換一條,雙擊,Access Is Denied。嗯???Ok,那我直接 New 一條 Record,Access Is Denied……
?
接下來,講一下我艱難的排 BUG 過程:
? ? ? 既然發現了 Bug ,那么先來找找 Bug 是怎么被觸發的。
? ? ? Download Log File,從文件里可以得到以下的一段信息:
<Message> SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: f7014009-b409-e911-943a-00155d16b40a, OwnerId: c062acbd-fcfc-e811-943a-00155d16b40a, OwnerIdType: 8 and CallingUser: c062acbd-fcfc-e811-943a-00155d16b40a. ObjectTypeCode: 2500, objectBusinessUnitId: 9cfbf85c-3e0f-e911-8b87-e0aa182461d5, AccessRights: WriteAccess </Message>? ? ? 第一眼看到 WriteAccess,我以為是 Security Role 沒有設置好,檢查了一下,設置沒有問題,而且 Read 的權限也在正常運作,因為可以看到 Active View 里所有的 Record。接著在屏蔽了 JS 以及 Plugin 代碼后,重新添加新的 system user 后,執行一步 BPF:OK,不出所料報了 Acess Is Denied 的錯誤,通過測試驗證了這個 bug 跟 JS 以及 Plugin 代碼無關,剩下就是要找出權限設置哪里出了差錯。
?
現在,就講一下這類bug要如何修復:
? ? ? 1.首先從下載下來的 log 中可以看到,ObjectTypeCode:2500,對 CRM 數據庫新建查詢,執行以下查詢語句:
SELECT * from EntityView ORDER BY ObjectTypeCode? ? ? ?可以得到一個列表,并且可以在列表中查詢到 ObjectTypeCode:2500 對應的 Entity Name 為 UserEntityUISettings。
圖2 數據庫查詢結果?
?
? ? ? 2.在設置權限的時候我們可以看到這個 UserEntityUISettings 就在 Security Role -> Core Records -> User Entity UI Settings:
圖3 Security Role 設置
?
? ? ? 根據 log 上報缺少 Write 權限,那么我們在 Security Role 里面將整行權限全部點上(這里的設置也只能點一下,賦予了 User 級別的權限),然后使用 User 重新打開剛剛 Access Is Denied 的 Record:發現還是打不開,還是報了 Acess Is Denied ,還是報了 ObjectTypeCode:2500 的錯誤。
? ? ? 猜想:難道是 Team Role 的權限不能被帶到 User Role 那邊?于是在 System User 的 User Role 里勾上了這個 Security Role,再次使用 User 打開 Record,驚喜,所有的操作都可以正常執行,不再報 Acess Is Denied 的錯誤了(此刻內心簡直思緒萬千)。然而,bug 雖然解決了,但這個方式顯然是不行的,因為如果在 User Role 里勾選上與 Team Role 一樣的 Security Role 的話,那么通過將 User 加到 Team 里來獲得權限這一點就已經失去了意義(除去 ownerid 為 Team 的情況),因為此時 User 自身已經擁有與 Team 相同的權限。
? ? ? 為了符合通過將 User 加入 Team 來獲取權限這一需求,可以使用以下方法:
1 新建一個叫做 UI 的 Security Role,在這個 Security Role 只賦予它 User Entity UI Setttings 的權限; 2 其他 Security Role 不賦予 User Entity UI Settings 權限,并且這些 Security Role 只供 Team Role 使用; 3 每個 System User 的 User Role 都使用 UI Security Role,不必勾選其他 Security Role。?
Note:
? ? ? 這里再提一個奇怪的修復方法,也算是一個隱藏 bug,就是當你在 system user 的 User Role 那邊勾選了一個具有 UserEntityUISettings 的 Security Role,并使用這個 user 去訪問了之前無權限訪問的 Record 后,這個時候我們再將 User Role 上勾選的 Security Role 取消,再去訪問那些 Record,你可以發現都變成有權限訪問了……沒錯,它就是如此的神奇,可能是存在“緩存”,或者勾選了之后會在數據庫某張權限表上加了一條代表某種關系的記錄,取消勾選又不會移除該條關系,關于具體原因我并沒有深入探究,也不建議通過這種方式來修復這個 bug,因為當你新加了 Entity 實體后又會再次出現同樣的錯誤,因為你之前并沒有訪問過。
?
總結:
? ? ? 最后總結一下,當出現“Acess Is Denied”相關的錯誤時,可以通過下載 log 文件,根據文件提示的?ObjectTypeCode 代碼及其他相關的日志信息,在數據庫中查詢出相對應的 Entity Name,再具體修復該 bug。
?
參考:https://nishantrana.me/2018/05/15/seclibaccesscheckex-failed-objecttypecode-2500-accessrights-writeaccess-error-on-user-entity-ui-settings-in-dynamics-365/
轉載于:https://www.cnblogs.com/Sunny20181123/p/10283351.html
總結
以上是生活随笔為你收集整理的Dynamics CRM - 如何修复 Access Is Denied,ObjectTypeCode: 2500 的错误的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 设计模式第19篇:访问者模式
- 下一篇: tomcat日志格式中的含义