BASIS权限的设定达沃旗SA.ppt

目錄 1 總述2 職能 TemplateRole 設定的分工3 三種不同的常規權限的設定方法4 常規以外的權限設定方式5 如何快速檢查權限設定的情況 總述 1 在開始學習之前2 SAP權限的架構 在開始學習之前 在開始了解權限前 有几點是要大家注意的1 權限設定非常重要 而且權限的DEBUG操作非常繁瑣 耗時 所以請大家設定時一定要非常謹慎 每次更改都要記錄 2 權限設定除非特殊情況 不允許在正式環境直接更改 請在測試環境修改好再傳到正式環境 3 MIS不是決定user權限的人 而是user大大小小的leader 所以 要變更權限設定 務必要求user提供經過簽核的申請表 當然 對user不合理的權限要求 MIS也有責任退回 4 權限的設定 是MIS的工作 廢話 所以 本教材是MIS內部教材 請不要隨便泄漏 SAP權限的架構 Roletemplate Description Menu Authorizations Authorizationprofile Objectclass Authorizationobject Authorizations Assignto Bindwith Assignto SAPUseraccount Address Logondata Group 這是SAP權限的架構圖 大家也接觸過 請大家一定要記住他們的關系 SAP權限的架構 名詞解釋 英譯中 Useraccount 就是我們平常說的 帳號 也稱為 USERID Role 同類的USER使用SAP的目的和常用的功能都是類似的 例如業務一定需要用到開S O的權限 當我們把某類USER需要的權限都歸到一個集合中 這個集合就是 職能 Role 所謂的 角色 或者 職能 是sap4 0才開始有的概念 其實就是對user的需求進行歸類 使權限的設定更方便 面向對象的權限 分為singlerole和compositerole兩種 后者其實是前者的集合 SAP權限的架構 Profile 真正記錄權限的設定的文件 從sap4 0開始是與Role綁定在一起的 雖然在sap4 6c還可以單獨存在 但按sap的行為推測 以后將不能 一個人活着 TemplateRole Role的模板 一般是singlerole 但這個模板具有一個強大的功能 能通過更改模板而更改所有應用 sap稱為Derive 繼承 此模板的Role sap稱之為adjust SAP權限的架構 例外權限 這是公司創造的名詞 當一個USER除了其職位一般所需的權限外 還需要一些特殊的權限 我們把這些權限稱之為這個USER的例外權限 例如開工單對生管來說是其職能應有的權限 但對倉庫來所就是例外權限 Role的命名和分類 Role的命名規則和分類如下 以 G 開頭都是TemplateRole 模板 都不會直接assign給userid G 職能名稱 全球共同TemplateRoleG 職能名稱 1 地區TemplateRole以 Z 開頭都是UserRole 直接assign給userid Z UserID 職能名稱 繼承全球共同TemplateRoleZ UserID 職能名稱 1 繼承地區TemplateRoleZ UserID Exception 沒有繼承任何Role 例外權限以 Y 開頭都是BasisRole 直接assign給userid Y 職能名稱 全球共同BasisRole Role的命名和分類 附件是一張職能 Rolename對照表我們以其中一個職能 AR作業人員 做解釋 職能中文名稱 職能英文名稱 全球共同TemplateRole 地區TemplateRole 全球共同BasisRole Role的命名和分類 全球共同TemplateRole 是指此職能在全球任何一個地區都一致的那部分權限的模板 命名特征是以 G 開頭 非 1 結尾 例如 G CO CO 地區TemplateRole 是指此職能根據不同地區而不同的那部分權限的模板 命名特征是 G 開頭 1 結尾 例如 G CO CO 1 Role的命名和分類 UserRole 是指根據每個user的具體需求進行設定的權限的Role 命名特征是 Z USERID開頭 東莞 台灣地區 W USERID開頭 吳江地區 例如 Z PSC1 ACT01 CO CO 全球共同BasisRole 是指此職能關系到整個系統的安全的那部分權限的Role 命名特征是 Y 開頭例如 Y CO CO 權限設定者分工 一 以Role類型分1 TemplateRole即 G 開頭的 台北本部的APMIS2 UserRole 以Z開頭的 東莞APMIS以W開頭的 吳江APMIS3 BasisRole 即以Y開頭的 台北和東莞BasisMIS 權限設定者分工 二 以USERID分從USERID可以區分出這個ID所屬的廠別和模組 例如 PSC1 ENG01這是PSC1廠的帳號 屬于PP模組 所以這個帳號申請的權限將由東莞PP模組的MIS主要負責和監督 權限設定者分工 三 以所申請的權限歸屬的模組分由于user所申請的權限通常涉及多個模組 這就需要多個模組的MIS共同合作設定user的權限 這時先按第二條執行 由ID所屬模組MIS接受申請 并從始至終跟進 然后具體的權限屬于哪個模組就由那個模組的MIS作設定 但無論如何 作為跟進的MIS都是負主要責任的 權限設定的操作 上面說過 權限的大架構由UserID Role Profile三層組成 那么 權限的設定自然也會有三層 但由于sap4 6是Profile與Role是捆綁在一起的 所以在建立Role的時候 Profile是會自動創建的 具體見后文 而UserID的建立比較簡單 所以 我將主要說明Role的部分 USERID的建立 TCODE SU01 USERID的建立 填好這些欄位 USERID的建立 設定初始密碼 有效期一般不設定 USERID的建立 按圖設定 印表機按實際設定 USERID的建立 接著按save 就把USERID創建好了 USERID創建好了 但這時這個ID沒有賦予 Assign 任何權限 是什么都不能做的 USER得到這樣的帳號沒有任何意義 如何Assign權限給一個帳號 主要就是Assign一個Role給這個帳號了 下面我們看看如何建Role和給權限 Role的建立 新創建Role主要有三種方式 TCODE PFCG1 由始至終新建 可以對應所有新建Role 主要對應例外權限Z USERID EXCEPTION2 繼承 主要對應設定Z USERID 職能名稱3 復制 COPY 主要對應設定Z USERID 職能名稱 1 Role的建立 完全新建 我們假設有一個帳號 FORTEST 他申請了例外權限VA01和YF30 下面我將會一步一步向大家說明操作的步驟和應該注意的地方 看到PFCG的畫面了嗎 沒有 哦 在下一頁 Role的建立 完全新建 輸入Rolename 注意選第二項 Role的建立 完全新建 描述一般與Rolename一致 記錄此Role的創建者 記錄此Role的最后修改者 把描述填好后 按save 然后點擊menu頁簽 Role的建立 完全新建 建立新目錄 修改TEXT 項目下移 項目上移 刪除項目 手動增加Tcode 從SAPMenu中增加Tcode 從其他Role中CopyMenu 這些是常用的功能 Menu頁簽定義的是USERMENU 個人化菜單 的內容 Role的建立 完全新建 請大家按圖所示建立目錄 第一層是職能 這里是EXCEPTION 下面分 標准 Standark 和 外挂 AddOn 兩個目錄 讓菜單保持清晰 可以令User的個人菜單清楚 不混亂 我們MIS檢查權限也比較方便 Role的建立 完全新建 大家可以對比下面兩個USER的個人化菜單 左邊職能清晰 右邊非常混亂 同名的目錄大量出現 但里面的內容又不盡相同 這對依賴路徑執行指令的user是很麻煩的 Role的建立 完全新建 菜單的殼子有了 如何往里面添加內容呢 比較常見的是 從SAP菜單添加和直接添加TCODE 從SAP菜單添加 所有標准的TCODE和沒有TCODE的標準程式都可以用這種方法添加 好處是可以尋找 可以一次添加標准菜單的一個目錄 Tcode在標准菜單中的位置也可以顯示出來 缺點是很浪費時間 而且外挂的程式無法添加 Role的建立 完全新建 直接添加 所有TCODE 包括外挂 和沒有TCODE的標準程式都可以用這種方法添加 好處是比較快缺點是必須知道Tcode 不能帶出路徑 Role的建立 完全新建 從SAP菜單添加 Role的建立 完全新建 Role的建立 完全新建 Role的建立 完全新建 Role的建立 完全新建 OBJECT完全沒有給值 OBJECT只有部分給值 OBJECT已經全部有值 請注意 綠燈只是表示全部有值而已 但不一定就是我們所需要的值 這時 標准Tcode所需要的Object 系統會自動帶出來 Role的建立 完全新建 這個Object是任何權限設定文件中都應該有的 這是給予啟動Tcode的權限 如果Tcode沒有出現在這個列表中 user連這個指令的畫面都無法進入 Role的建立 完全新建 在這里 需要向大家介紹一個很重要的概念 Org level 在權限設定中 有許多地方的控制點是一致的 sap公司為了方便權限的設定 把這些地方設計為與全局變數關聯 當改變全局變數時 這些地方就可以全部改變過來 這個全局的變數就是 Org level Role的建立 完全新建 當Org Level給值后 相應的Objectvalue的值也變了 Role的建立 完全新建 對Org Level都給值之后 會發現相當一部分的Objectvalue都已經給值了 但還有一些Object是紅燈或者是黃燈 這些Object是要單獨給值的 Role的建立 完全新建 按一下標志 就可以輸入值 按保存在這里介紹一下的作用 點擊它 就相當於給這個Object一個 star 的意義是AllAuthorization 不卡任何權限 Object給值后 就變成綠色 不能點擊了 Role的建立 完全新建 如果是外挂的Tcode 就只能用 直接添加 的方式加入到菜單中 需要注意的是 外挂的Tcode的Object不會自動帶出來 需要自己手工添加 按 點擊Y AUTH PRT前的 Role的建立 完全新建 變為后 按屏幕上方的 插入Object 注意 外挂的Tcode 除了前面所說的列表中要有外 這里框住的地方要給Tcode 否則user還是不會有權限 Role的建立 完全新建 都給好值后 按保存 按 勾 然后按激活 退出 Role的建立 完全新建 Authorization已經變成綠燈 這表示權限的設定已經可用了 點擊USER AssignUSERID給這個Role Role的建立 完全新建 點擊USERCOMPARE 再點擊Completecompare 就完成了COMPARE 至此 此權限已經Assign完畢 FORTEST這個帳號已經具有VA01和YF30的權限 Role的建立 繼承 所謂 繼承 是指兩個Role形成這樣的母子關系 子Role的所有Menu Authorization Org level除外 都源于母Role 并與母Role保持一致 母Role與子Role是1對多的 Role的建立 繼承 下面 我們來學習用 繼承 方式建立Role 我們假設有一個帳號 FORTEST 他申請了職能 AP立帳員 AP立帳員 的TemplateRole是 G CO AP 我們先來按命名規則Create一個新Role Role的建立 繼承 大家注意這個地方 建立 繼承 關系就是靠這里了 Role的建立 繼承 填入TemplateRole 按Enter 是否建立繼承關系 回答當然是 YES 了 否則我們怎樣上課 如果在此前沒有做過存檔 系統會詢問是否存檔 回答同樣是 YES Role的建立 繼承 可以看到 菜單已經自動根據TemplateRole生成了 點擊Authorization頁簽 設定權限去 Role的建立 繼承 進入Profile里面了 請注意下面所說的操作 如果做錯了 可能要拉倒從新開始的喲 點擊這個按鈕 1 系統會自動進入Org level 請點擊 X 退出Org level 2 按 SAVE 對Profile存檔 Role的建立 繼承 3 執行菜單Edit中的Copydata 系統會提示這個操作不可反轉 按 勾 繼續 執行完畢后我們會看到 許多Object已經變成綠燈了 Role的建立 繼承 現在可以維護Org level的設定了 進入的方法如上 當Org level每一個欄位都賦值之后 應該每一個Object都是綠燈 如果還有紅黃燈 請通知台北修正 Role的建立 繼承 當所有權限 其實只是設定Org level 都設定完畢后 按激活設定 Assign給USERID 就完成了 Role的建立 繼承 大家是否覺得 繼承 的方法好簡單 几下就做完了 其實這種方法思路最復雜了 后面的處理還隱藏不少陷阱 不過現在大家先掌握Role的建立方法 其它的問題等一下再說 那么 我們來看看第三種方法 復制 Role的建立 復制 復制其實是一種從思想到操作都很簡單的操作 它的核心就是 復制 雞蛋和番茄飛了起來 我們來看看如何操作吧 先告訴大家 AP立帳員 的TemplateRole還有一個 是 G CO AP 1 我們就用它來學習 Role的建立 復制 一開始當然是進入PFCG了 先把TemplateRole名輸進去 然后按COPY按鈕 Role的建立 復制 Role的建立 復制 把描述改成與Role名一樣 要注意 1 的Role的menu是空的 這里是空的 Role的建立 復制 紅色框住的都是要填入值的地方 最好先填完Org level Role的建立 復制 與其它方式建立的Role一樣 當所有權限都設定完畢后 按激活設定 Assign給USERID 一個Role就設定完成了 Role的建立 繼承與復制 小結 非 1 的那種TemplateRole 用繼承的方式建立新Role 繼承后 只需要填入Org level Object就全部是綠燈了 而 1 的那種是用復制的方式 還需要在Object里填入值 才能全部綠燈 這是兩者操作上的最大特點 Role的修改 1 Merge2 新增 刪除TCode3 從其它Role導入4 Adjust Role的修改 對Role的修改最常見的是有TCode的新增 刪除 這種改動 一般是從Menu開始 當Menu改變任何改變 系統都會偵測到 Authorization和User會變成紅燈 在Authorization頁簽里有兩個按鈕 他們有什么不同呢 Role的修改 我們先點擊 會出現一個小窗口 里面是三個選項 他們的意義是不同的 第一項 刪除此Role的Profile后重建第二項 編輯原有的Profile第三項 讀取原有Profile并根據Menu的變化對Profile進行更改 Role的修改 第一項會把Profile整個重建 并且會把已經被屏蔽掉或刪除的Object重新顯示出來 極容易造成權限設定錯誤 反對使用 第二項完全保留之前可用的Profile 即使新的權限沒設好 還有原有的權限可用 推荐使用 缺點是Object的變更需要手動進行 第三項重新讀取Role的Menu 按菜單的變化變更Object 具有一定的智能 但會把已經Merge的Item彈開 造成設定者的混亂 不反對使用 Role的修改 這個按鈕相當與前面所說的第三項 由于已經包含這個選擇 而且第三項不是最優選擇 所以我們一般不建議使用它 總的來說 我們認為選的第二項比較穩當 保留原有的可用設定 可以看到變化前的Profile 詳細細節請繼續看后面的章節 Role的修改 Merge 當Role所包含的TCode經過多次修改后 可能產生多個同樣的Object 其Value可能互相包含 這時可以通過Merge 合并 的動作使同一個Object內Value相同或者互相包含的Item合并起來 使權限的條目更清晰 Role的修改 Merge 紅框框住的兩個Object 是同樣的Object 而且其Value又是第一個包含第二個 Role的修改 Merge 上頁紅框里的兩項被合并了 選擇菜單Utilities里的Merge Role的修改 Merge的規則 我們來看一個簡單的Object 它只有兩項 Activity和下面的Group 我稱Acitivity為 動作 它下面的Group等項目為 參數 Merge的規則 當兩個相同Object的Item的動作或參數完全一致時 這兩個Item可以Merge Role的修改 Merge 當一個Role經過Merge后 這個Role的Object會比較精簡 但當Menu發生改變后 系統會提示菜單已經變化 Authorization和User會從綠燈變成紅燈 現在我來舉一個例子 假設新增一個TCode FSS0 Role的修改 Merge 這時 如果我們選擇的第二項 進入Profile 會發現所有的Object都和菜單沒有變化前一樣 到底FSS0對Object的影響有哪一些 需要自己的經驗 這里我就不詳細介紹 如果一點都不知道 可以做一個測試用的Role 只含有這一個TCode 看看系統自動為它帶出的Object即可 Role的修改 Merge 如果選擇的第三項 進入Profile 我們會發現 不少Object變成了黃燈 但如果有經驗的話 仔細看看 會發現有好几個Object其實都是以前Merge過 現在給彈開或者刪除過 再次帶出 Role的修改 Merge 對于熟悉的人來說 這些多余的Item可以刪除就可以了 但也要費時間確認 對于不熟悉的人來說 就可能無法區分那些Object是新增TCode所需要的 哪些是因為不能開放而刪除的 耗費的時間可能更多 所以 我們不推荐這種做法 Role的修改 新增和刪除TCode 新增和刪除TCode其實在前面都有提到 在Menu頁簽的操作這里就不再重復了 細節請參照 Role的新建 完全新建 在Authorization頁簽的操作請參考 Role的修改 這里只重點提醒一件事 Role的修改 新增和刪除TCode 在每一個有Menu的Role里 必定有一個叫S TCODE的Object 這個Object里記錄的是這個Role所有可以執行的TCode 當Menu變化 這里也要相應變化 但這個Object永遠是綠燈 所以大家一定要記得檢查這里 Role的修改 新增和刪除TCode 經過測試 在Menu新增TCode后 在進入Profile時選擇第二項時 系統不會在此Object自動增加TCode 選擇第三項 系統會自動增加TCode 在Menu刪除TCode后 無論選擇第二項還是第三項 系統都不會自動刪除TCode 必須手工刪除 這一點請大家務必注意 Role的修改 從其它Role導入 當我們要處理的RoleA與某個RoleB的設定十分相似 可以通過Insert功能把RoleB的Object設定導入到RoleA中 請留意 實際上是導入Profile哦 所以一般還要去看RoleB的ProfileName 不是很方便 Role的修改 從其它Role導入 需要注意的是 這樣導入進去的Object的設定都跟RoleB的一樣 一定要把其中對RoleA不適用的部分更正過來 對RoleB不熟悉不要亂用這功能哦 還是那句老話 欲速不達 不熟的事 沒有把握的事一定要謹慎 Role的修改 Adjust Adjust是專門針對存在繼承關系的母子Role的一項功能 在 Role的建立 一章 我們學習到 從子Role可以通過CopyData從母Role得到ObjectValue 現在 我們看看從母Role傳送ObjectValue到子Role的功能Adjust Role的修改 Adjust 用Display模式進入TemplateRole的Profile 選擇菜單上的Generatederivedroles即可 從操作來看 十分簡單 注 不要用Change進入TemplateRole 否則Adjust會造成TemplateRole本身最后修改日期和最后修改人發生改變 對查對權限產生誤會 Role的修改 Adjust 簡單比較CopyData和Adjust Role的傳輸 1 產生RequestNum2 Release3 Transport Role的傳輸 產生RequestNum 在PFCG的開始畫面 可以看到 由于單個Role的傳送比大批量的傳送從操作上來說要簡單而且類似 所以我們重點說大批量傳送的操作 大批量的傳輸 單個Role的傳輸 Role的傳輸 產生RequestNum 選擇SingleRole 選擇要傳輸的Role Role的傳輸 產生RequestNum 確定要傳輸 Role的傳輸 產生RequestNum 如果這個Role第一次傳輸這里一定要打勾 否則傳輸到其它client后會沒有Assign到UserID 但如果不是第一次傳輸請不要打勾 因為只要打了勾就要到目標的Client端去做一次Compare的動作 權限才能激活 沒有起用 Role的傳輸 產生RequestNum 如果要新建一個Request 按 如果現在已經有一個還沒有Release的可用的RequestNum 請在這里輸入 然后打勾 Role的傳輸 產生RequestNum 簡要說明傳輸的內容或目的 Role的傳輸 產生RequestNum RequestNum產生 C00K開頭的都是大陸地區產生的 T00K開頭的都是台灣地區產生的 Role的傳輸 產生RequestNum 單個Role的傳輸RequestNum產生的過程與打批量的相似 只是開始不一樣而已 單個傳輸直接KeyRole名字 按按鈕 其它操作就一樣了 Role的傳輸 Release Release的TCode SE10 輸入RequestNum的產生者 選擇查看Modifiable Role的傳輸 Release 可以看到 其實是有兩個RequestNum的 一個記錄Header 一個記錄Item Role的傳輸 Release 先ReleaseItem的Num 在下面 作為子項的那一個 再Header的Num方法是 點擊Item的Num 然后按按鈕 會進入另一個畫面 按 會回到原來的畫面 然后再ReleaseHeader的Num 同樣是點擊Header的Num 然后按 進入另一畫面后 不用存盤 按即可 Role的傳輸 傳送 這一部分是Basis的工作 本來是在Unix下進行 但我們開發了兩支外挂程式 從測試環境到正式環境是YATP從測試環境到QAS是YATPQA進行傳送的RequestNum必須是已經Release的Number Role的傳輸 傳送 兩者的畫面很象 填入RequestNum 選擇好目標Server 按就可以了 Role的傳輸 刪除 如果發現Role搭錯了一個RequestNum 在沒有Release前可以補救 同樣是在SE10 點擊Num后使用就可以了 Role的傳輸 刪除 如果已經Release就沒有辦法刪除了 只能整個Number作廢 所謂 作廢 其實是不做最后的傳送動作 讓這個Number閑置而已 Role的刪除 在PFCG中填好Role的名字 按按鈕 確認 即可把Role及其專屬Profile刪除 Role的刪除 請注意 如果需要利用傳輸功能在多個環境中刪除Role 一定要按以下順序進行 1 對Role產生傳輸的RequestNum 2 刪除本環境的Role 3 Release 此時本環境中已經沒有這個Role了 4 傳輸 帳號刪除 帳號 UserID 的刪除操作也十分簡單 在SU01中 輸入帳號名稱 按就可以了 帳號刪除 刪除一個帳號后 為其專設的Role 即Z或W開頭的 也要刪除 包括測試和正式環境 減少系統無用的資料 也減少不必要的查對 或許有人會認為 保留這些Role 雖然占用一點硬盤 但如果以后這個帳號再次起用 不就可以不用重設權限嗎 這個理由咋看起來很有道理 實際上USER一旦決定刪除某個帳號 在相當長的時間內都不會再起用 一個帳號的費用不菲 決定不會輕易下的 在經過長時間后即使需要再次起用 其權限需求也要重新審視 與其把其新需求與舊有設定一項一項對比修改 還不如重新設定來得方便快捷 而且更安全 Debug 查看 有一些工具對權限的問題處理很有幫助1 SU532 SUIM雖然還有一些其它工具 但一般很少用或者不實用 這里就不介紹了 Debug 查看 SU53 當一個帳號反映沒有某個應有的權限時 我們可以在系統出現沒有權限的信息時 馬上輸入 NSU53 Debug 查看 SU53 Debug 查看 SU53 上頁紅色框住的就是沒有權限的地方 而藍色框住的是跟這個帳號已經有的權限 但是請注意 SU53給出的信息并不詳細 大部分情況只能作為一個大方向的參考 有時還可能指示不出來問題所在 但無論如何 有一個參考總比沒有好 Debug 查看 SUIM SUIM其實就是Information系統的一個集合界面 我們最常用的功能是 已知某個TCode 查找含有這個TCode的Role Debug 查看 SUIM Debug 查看 SUIM 輸入TCode后執行 就可以得到含有這個Tcode的Role的列表 請注意 其判斷條件是Role的Menu 而不是Profile 特殊的權限設定 SD的權限在SD模組 有一個解S OBillingBlock權限的設定 它是在YS08中設定 其它知識 1 Object的狀態Standard Manually Maintained Changed2 ObjectValueVSOrg level 其它知識 Object的狀態 其它知識 Object的狀態 當我們用第三項進入一個Profile的時候 我們可以看到每個Object的描述前有都有兩個狀態 現在我來給大家解釋一下他們的含義 右邊的狀態共有兩種 NEW和OLDNEW 此Object有新的Item或Value ProfileSave后會變成OLDOLD 此Object的Item是以前建立的 其它知識 Object的狀態 左邊的狀態有好几種 Standard 由系統帶出后沒有經過任何更改Maintained 對系統初次帶出時Value為空的Item進行過變更或補充Changed 對系統初次帶出時Value為非空的Item進行過變更 其它知識 ObjectValueVSOrg level 大家可能對ObjectValue與Org level的關系有一些疑問 對Adjust時子Role到底那些地方會被母Role控制變更有點把握不住 那么下面介紹的東東對大家可能有點幫助1 Adjust大原則 Org level 子Role有值時 Adjust時以子Role為准 子Role無值時 Adjust以母Role為准Object Value 一律強制以母Role為准 其它知識 ObjectValueVSOrg level 2 Value與Org level我們可以發現 在Object里有些Item的Value是與Org level相關聯的 其值在沒有手工更改前都是以 開頭 這類值都是變量 指向對應的Org level 當Org level給值后 Object就通過這些變量把Org level的值顯示出來 但實際上Object的值仍然是原來以 開頭的那個值 其它知識 ObjectValueVSOrg level 在子Role中 如果這些ObjectValue被手工更改 在母Role沒有做Adjust之前 子Role的ObjectValue是可以與Org level不一致的 實際權限以ObjectValue為准 但一旦母Role做了Adjust 子Role的ObjectValue就強制與母Role一致 而母Role一般對這類ObjectValue的處理是保持其變量狀態 那么子Role的Value就變會變量狀態 XXXX 然后根據子RoleOrg level的值顯示出新的值 其它知識 ObjectValueVSOrg level 3 如果不小心變更了與Org相連的Value 但又想恢復其變量狀態 怎么操作 首先 簡單地把Value清空是不行的 這樣的操作只是把當前值變為NULL 空 第二 把其原有的 開頭的值Key進去也是不行的 主要原因是輸入欄位的長度不夠 正確操作是 把這個Object整個刪除 然后手工添加這個Object 請大家把自己的發現告訴我 這個教材是我在工作之余測試編寫的 因為看到不少兄弟姊妹包權限的時候還有不少的疑問 所以希望能總結一下 對大家有點幫助因為時間很不夠用 斷斷續續寫了一個多月 本來有些東西想寫 但由于沒有時間進一步了解 怕寫出來誤人子弟 只好作罷 同時由于時間和精力 美觀方面就不做多的修飾了 反正是內部教材 請大家把自己的發現告訴我 這不是客套話 這個教材雖然是我很辛苦寫出來的 但可能還是有不對的地方 請大家發現后告訴我 我有時間的時候會修正 同時如果大家有自己的心得也請不吝賜教 特別是各個模組特有的權限設定 輔助工具的使用 Basis組所負責的權限部分 權限的傳輸等方面 我還有些地方了解的很不足夠 希望各位能告訴我