專利名稱：用戶權(quán)限設(shè)置方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種云交易平臺，尤其涉及一種適配于云交易平臺的用戶權(quán)限設(shè)置方 法。
背景技術(shù)：
隨著社會信息化及網(wǎng)絡(luò)化的深入發(fā)展，越來越多的商品交易可以基于電子交易服 務(wù)平臺完成。電子交易服務(wù)平臺可以將服務(wù)使用者(交易雙方)以及服務(wù)提供者(例如金 融、物流服務(wù)等)的信息一并整合，這種整合了多方資源、信息的平臺有效促進了商品交易 的信息溝通，給服務(wù)使用者帶來了極大的便利。隨著電子交易服務(wù)平臺的廣泛使用，電子商務(wù)技術(shù)也得到了長足發(fā)展，在申請?zhí)?為200510005264. 7的中國專利申請中就公開了一種電子交易服務(wù)平臺的交易方法，所述 方法包括接收和記錄買方期望條件；登記注冊賣方及其產(chǎn)品和期望；在移動電子交易服 務(wù)平臺上尋求符合買方期望條件的賣家；中央控制器監(jiān)視買方期望條件和賣方期望條件， 匹配出潛在的賣方，將買方的期望條件傳送給一定數(shù)量的賣方，若賣方反饋有意接受，則與 買方聯(lián)系確認、等待買方反饋，若買方確認，則產(chǎn)生一交易。所述方法以買方為主導(dǎo)，可以有 效控制期望商品的競價價格，而且操作簡單，易于實現(xiàn)。在電子交易服務(wù)平臺向用戶提供服務(wù)的過程中，電子交易服務(wù)平臺需要向服務(wù)使 用者提供豐富和完善的服務(wù)。隨著不斷地更新或改進，電子交易服務(wù)平臺可提供的服務(wù)積 累了多種版本。然而，現(xiàn)有技術(shù)的電子交易服務(wù)平臺中并沒有繁雜的用戶其提供給用戶的 服務(wù)提出有效的管理方法。

發(fā)明內(nèi)容
本發(fā)明要解決現(xiàn)有技術(shù)中龐大的用戶有效使用電子交易服務(wù)平臺的缺失。為解決上述問題，本發(fā)明提供一種用戶權(quán)限設(shè)置方法，包括獲取所述云交易平臺 生成的訂購信息；所述訂購信息中至少包括機構(gòu)信息、訂購的服務(wù)信息、針對所述服務(wù)訂購 的角色信息；接收組織設(shè)置請求操作，為前述機構(gòu)設(shè)置至少一個組織；接收組織角色設(shè)置 請求操作，為前述各組織設(shè)置至少一個訂購的角色信息；接收組織成員設(shè)置請求操作，為前 述各組織添加至少一個成員；針對所述訂購的服務(wù)，所述成員具備其所屬組織的角色。所述用戶權(quán)限設(shè)置方法，還包括生成用戶權(quán)限信息；發(fā)送所述用戶權(quán)限信息。所述為前述機構(gòu)設(shè)置至少一個組織包括接收設(shè)置組織請求；判斷發(fā)出設(shè)置組織 請求的用戶是否有權(quán)限添加所述組織；判斷成功時，查詢數(shù)據(jù)庫有無與請求中的組織相關(guān) 的信息；在未查詢到與請求中的組織相關(guān)的信息時，建立所述組織。所述為前述各組織添加至少一個成員包括對所述組織進行查詢。所述為前述各組織添加至少一個成員包括接收組織成員設(shè)置請求；判斷發(fā)出所 述組織成員設(shè)置請求的用戶是否有權(quán)限在所述組織下設(shè)置成員；判斷成功時，在所述組織 下添加所述成員，以及生成用戶和組織的關(guān)系信息。
所述組織成員設(shè)置方法還包括刪除組織中已經(jīng)設(shè)置的用戶。所述用戶權(quán)限設(shè)置方法還包括查詢已設(shè)置的組織。所述用戶權(quán)限設(shè)置裝置還包括修改已設(shè)置的組織。所述用戶權(quán)限設(shè)置裝置還包括刪除已設(shè)置的組織。所述用戶權(quán)限設(shè)置裝置還包括禁用已設(shè)置的組織。所述用戶權(quán)限設(shè)置裝置還包括啟用已設(shè)置的組織。與現(xiàn)有技術(shù)相比，本發(fā)明的服務(wù)訂購裝置提供一種新的云服務(wù)平臺的用戶權(quán)限管 理，用戶變得較為龐大時，提高了服務(wù)的訂購和授權(quán)管理效率。


圖1是本發(fā)明一云交易平臺管理系統(tǒng)結(jié)構(gòu)示意圖；圖2是本發(fā)明服務(wù)訂購裝置結(jié)構(gòu)示意圖；圖3是本發(fā)明服務(wù)訂購方法流程示意圖；圖4是本發(fā)明訂購信息查詢的一實施例示意圖；圖5是本發(fā)明用戶權(quán)限設(shè)置裝置結(jié)構(gòu)示意圖；圖6是本發(fā)明用戶權(quán)限設(shè)置方法流程示意圖；圖7是本發(fā)明組織設(shè)置的一實施例示意圖；圖8本發(fā)明為組織設(shè)置成員的一實施例示意9是本發(fā)明另外一云交易平臺管理系統(tǒng)結(jié)構(gòu)示意圖；圖10是一云交易平臺系統(tǒng)結(jié)構(gòu)示意圖。
具體實施例方式為使本發(fā)明的上述目的、特征和優(yōu)點能夠更加明顯易懂，下面結(jié)合附圖對本發(fā)明 的具體實施方式
做詳細的說明。在下面的描述中闡述了很多具體細節(jié)以便于充分理解本發(fā)明，但是本發(fā)明還可以 采用其他不同于在此描述的其它方式來實施，因此本發(fā)明不受下面公開的具體實施例的限 制。如圖10所示，一種云交易平臺系統(tǒng)包括至少一個終端設(shè)備、云交易平臺，以及至 少一個服務(wù)系統(tǒng)，所述終端設(shè)備、云交易平臺、服務(wù)系統(tǒng)之間通過網(wǎng)絡(luò)進行信息交換。服務(wù) 系統(tǒng)通過云交易平臺提供各種服務(wù)，終端設(shè)備在云交易平臺上使用這些服務(wù)，如物流服務(wù)， 合約服務(wù)，銀行服務(wù)等。服務(wù)系統(tǒng)提供的服務(wù)由至少一個功能點組成，每個角色具有至少一個功能點的使 用權(quán)限。如服務(wù)包括功能點1、2、3，角色1具有功能點1的使用權(quán)限，角色2具有功能點1、 2的使用權(quán)限，角色3具有功能點1、2、3的使用權(quán)限。用戶通過終端設(shè)備在云交易平臺使用服務(wù)系統(tǒng)提供的各種服務(wù)、角色之前，需要 先在云交易平臺上訂購其所需要的服務(wù)、角色。云交易平臺授權(quán)用戶訂購的服務(wù)、角色后， 用戶可以在云交易平臺使用其訂購成功的服務(wù)、角色。當使用終端設(shè)備的用戶變得較為龐 大時，每個用戶對其所需要的服務(wù)、角色發(fā)出訂購請求，則云交易平臺需要處理的信息量激 增，導(dǎo)致信息沖突、信息處理滯后、信息丟失等。因而，本發(fā)明在云交易平臺中提供了一種云交易平臺管理系統(tǒng)，該管理系統(tǒng)對服務(wù)訂購的管理和用戶權(quán)限的設(shè)置做出了有效的改進， 提高了云交易平臺系統(tǒng)的信息處理準確率和效率。本發(fā)明提供的云交易平臺管理系統(tǒng)，如圖1所示，所述云交易平臺管理系統(tǒng)包括 云交易平臺的服務(wù)訂購裝置1、適配于云交易平臺的用戶權(quán)限設(shè)置裝置2。所述服務(wù)訂購裝 置1適于與終端設(shè)備耦接。服務(wù)訂購裝置1，適于接收來自終端設(shè)備的服務(wù)訂購請求，生成與所述服務(wù)訂購請 求對應(yīng)的訂購信息并向所述終端設(shè)備發(fā)送反饋信息；用戶權(quán)限設(shè)置裝置2，適于獲取所述云交易平臺生成的訂購信息，所述訂購信息中 至少包括針對所述服務(wù)訂購的角色信息，為前述各組織設(shè)置至少一個訂購的角色信息，為 前述各組織添加至少一個成員，針對所述訂購的服務(wù)，所述成員具備其所屬組織的角色。如圖2所示，本發(fā)明提供的與終端設(shè)備耦接的服務(wù)訂購裝置1包括第一接口單元 111、用戶驗證單元112和訂購請求處理單元113。第一接口單元111適于接收來自終端設(shè) 備的服務(wù)訂購請求，所述服務(wù)訂購請求至少對應(yīng)發(fā)起請求的用戶信息、所述用戶對應(yīng)的機 構(gòu)信息、請求訂購的服務(wù)信息、針對所述服務(wù)請求的角色信息。用戶驗證單元112，與所述第 一接口單元匹配，適于對所述用戶信息進行驗證。訂購請求處理單元113，與所述用戶驗證 單元匹配，適于在所述驗證單元驗證通過后對所述服務(wù)訂購請求進行判斷；在判斷通過時 生成與所述服務(wù)訂購請求對應(yīng)的訂購信息并向所述終端設(shè)備發(fā)送反饋信息。如圖3所示，本發(fā)明還提供服務(wù)訂購方法，包括以下步驟步驟Sl 1，接收來自終端設(shè)備的服務(wù)訂購請求，所述服務(wù)訂購請求至少對應(yīng)發(fā)起請 求的用戶信息、所述用戶對應(yīng)的機構(gòu)信息、請求訂購的服務(wù)信息、針對所述服務(wù)請求的角色 fn息；步驟S12，對所述用戶信息進行驗證；步驟S13，所述驗證單元驗證通過后對所述服務(wù)訂購請求進行判斷；步驟S14，判斷通過時生成與所述服務(wù)訂購請求對應(yīng)的訂購信息并向所述終端設(shè) 備發(fā)送反饋信息。下面結(jié)合附圖2、3對本發(fā)明提供的服務(wù)訂購裝置和服務(wù)訂購方法進行更詳細的 說明。第一接口單元111可由現(xiàn)有技術(shù)中的網(wǎng)路接口單元組成。用戶信息包括ID(identity)、用戶賬號、用戶名、職位、公司、密碼、辦公室電話、 辦公室傳真、手機號碼、地址、電子郵箱、語言類型和描述等。用戶信息還可以包括用戶所屬 機構(gòu)的ID、所述機構(gòu)狀態(tài)。用戶信息也可以包括所屬組織的ID、所屬組織狀態(tài)。機構(gòu)信息包括ID、機構(gòu)名稱、一個所屬該機構(gòu)的用戶的ID、狀態(tài)。服務(wù)信息包括ID、服務(wù)代碼、服務(wù)名、服務(wù)擴展名、服務(wù)描述、狀態(tài)、創(chuàng)建者、創(chuàng)建 日期、更新者、更新日期。角色信息包括ID、角色代碼、角色名稱、所屬應(yīng)用的ID、角色級別、描述、狀態(tài)、創(chuàng)
建者、創(chuàng)建日期、更新者、更新日期。用戶驗證單元112對所述用戶信息進行驗證包括驗證用戶信息的用戶賬號是否 正確、發(fā)起請求的用戶是否有權(quán)限發(fā)起該服務(wù)訂購請求等。進行所述驗證前，可以先分析服 務(wù)訂購請求中對應(yīng)發(fā)起請求的用戶信息，
用戶驗證單元112驗證用戶賬號是否正確可以包括驗證用戶賬號是否注冊、用 戶賬號中的賬號名稱和賬號密碼是否匹配等。發(fā)起請求的用戶以機構(gòu)名義訂購服務(wù)時，用戶驗證單元112驗證發(fā)起請求的用戶 是否為該用戶所屬機構(gòu)的機構(gòu)管理員。若發(fā)起請求的用戶為所屬機構(gòu)的機構(gòu)管理員，則繼 續(xù)驗證其他的內(nèi)容或發(fā)送驗證通過通知。若發(fā)起請求的用戶不是所屬機構(gòu)的機構(gòu)管理員， 則停止驗證其他的內(nèi)容，并發(fā)送驗證失敗通知。訂購請求處理單元113對所述服務(wù)訂購請求進行判斷包括判斷服務(wù)訂購請求費 用是否已經(jīng)繳納，服務(wù)訂購請求的是否錯誤等。判斷訂購請求費用是否已經(jīng)繳納時，需要核查該服務(wù)訂購請求中每項服務(wù)、角色 的費用是否均已繳納。若費用繳納清楚，則繼續(xù)核查其他項目或生成與所述服務(wù)訂購請求 對應(yīng)的訂購信息并向所述終端設(shè)備發(fā)送反饋信息。若有一項或者多項未繳納則返回錯誤信 息至請求用戶。此處所述的服務(wù)訂購請求的內(nèi)容是否明顯錯誤，包括服務(wù)訂購請求中的服務(wù)、角 色關(guān)系是否選擇錯誤等。所述訂購請求處理單元113生成與所述服務(wù)訂購請求對應(yīng)的訂購信息至少包括 機構(gòu)信息、訂購的服務(wù)信息、針對所述服務(wù)訂購的角色信息。還可以包括訂購單、訂購實例 信息、授權(quán)信息等。訂購單包括訂購ID、用戶ID、服務(wù)ID、機構(gòu)ID、訂購開始時間、訂購結(jié)束時間、訂
購級別、授權(quán)賬戶數(shù)。訂購實例信息包括ID、訂購名、用戶的ID、訂購的服務(wù)的ID、機構(gòu)的ID、開始日
期、結(jié)束日期、訂購數(shù)量、角色級別、狀態(tài)、創(chuàng)建者、創(chuàng)建日期、更新者、更新日期。授權(quán)信息包括ID、服務(wù)代碼、服務(wù)名、服務(wù)擴展名、服務(wù)描述、狀態(tài)、創(chuàng)建者、創(chuàng)建 日期、更新者、更新日期。訂購請求處理單元113向所述終端設(shè)備發(fā)送反饋信息可以包括訂購信息和/或訂 購成功通知。所述訂購成功通知至少包括訂購ID。一個服務(wù)訂購請求可以訂購一個或者多 個服務(wù)，但是只產(chǎn)生一個訂購信息。用戶每訂購一個服務(wù)，就會產(chǎn)生一個服務(wù)環(huán)境，稱為訂 購實例，每個訂購信息對應(yīng)一個訂購實例。所述訂購請求處理單元113還適于更新與發(fā)起請求的用戶對應(yīng)的服務(wù)訂購信息。 更新的服務(wù)訂購信息包括發(fā)起請求的用戶對應(yīng)的訂購信息、應(yīng)用訂購實例信息、授權(quán)信息寸。所述機構(gòu)信息可以攜帶在服務(wù)訂購請求，也可以是單獨添加的機構(gòu)信息。所述機構(gòu)的建立可以依機構(gòu)建立請求而開始。接收到機構(gòu)建立請求后，查詢是否 已經(jīng)建立有與該請求相關(guān)的機構(gòu)，若已經(jīng)建立有與該請求相關(guān)的機構(gòu)，則產(chǎn)生建立機構(gòu)失 敗信息，若未建立有與該請求相關(guān)的機構(gòu)，則依據(jù)機構(gòu)建立請求建立該機構(gòu)。依機構(gòu)建立 請求可以建立一個或多個機構(gòu)，以一個或多個機構(gòu)名義向服務(wù)訂購裝置1發(fā)出服務(wù)訂購請 求。所述機構(gòu)信息可以包括ID、機構(gòu)名稱、一個所屬該機構(gòu)的用戶的ID、狀態(tài)。已建立的機構(gòu)還可以被管理。接收機構(gòu)管理請求，檢查請求用戶的權(quán)限是否具有 管理機構(gòu)的權(quán)限。較佳的，僅有機構(gòu)管理員具有查詢和除查詢以外的管理權(quán)限，機構(gòu)內(nèi)普通 用戶僅具有查詢機構(gòu)的管理權(quán)限。權(quán)限核實后，機構(gòu)管理請求用戶可以在權(quán)限內(nèi)管理機構(gòu)。
所述機構(gòu)管理請求可以包括機構(gòu)查詢請求、機構(gòu)修改請求、機構(gòu)刪除請求、禁用、 機構(gòu)啟用請求。管理已經(jīng)建立的機構(gòu)包括查詢、修改、刪除、禁用、啟用機構(gòu)。具體的，機構(gòu)ID —旦生成，不能更改，機構(gòu)查詢請求可以包括機構(gòu)ID。系統(tǒng)管理員可以請求刪除所有的機構(gòu)，用戶可以刪除自己創(chuàng)建的機構(gòu)。刪除機構(gòu)， 包括刪除機構(gòu)信息，以及刪除其他相關(guān)。刪除機構(gòu)后，標記刪除，并且需要更新該機構(gòu)的所 有訂購實例的狀態(tài)為禁用，這些訂購實例需要用戶重新指定一個可用的機構(gòu)，才能再次使 用。系統(tǒng)管理員可以請求禁用所有的機構(gòu)。禁用機構(gòu)后，所述機構(gòu)信息中的狀態(tài)被設(shè) 置為禁用。系統(tǒng)管理員可以請求啟用所有的機構(gòu)。啟用機構(gòu)后，所述機構(gòu)信息中的狀態(tài)被 設(shè)置為啟用。又一實施例中，所述第一接口單元111還適于接收訂購信息查詢、修改、刪除、禁 用、啟用請求中一個或多個。所述訂購信息的查詢、修改、刪除、禁用、啟用請求至少對應(yīng)發(fā) 起請求的用戶信息、所述用戶對應(yīng)的機構(gòu)信息、訂購ID或訂購實例ID。訂購請求處理單元 113包括查詢請求處理單元、修改請求處理單元、刪除請求處理單元、禁用請求處理單元、啟 用請求處理單元中的一個或多個。所述查詢請求處理單元適于查詢已經(jīng)生成的訂購信息。所述修改請求處理單元適于修改已經(jīng)生成的訂購信息。所述刪除請求處理單元適于刪除已經(jīng)生成的訂購信息。所述禁用請求處理單元適于禁用已經(jīng)生成的訂購信息。所述啟用請求處理單元適于啟用已經(jīng)生成的訂購信息。具體地說，如圖4所示，數(shù)據(jù)庫保存有與發(fā)起請求用戶信息、用戶對應(yīng)的訂購信 息，以及用戶權(quán)限信息等。用戶通過終端設(shè)備發(fā)出服務(wù)訂購實例查詢請求，服務(wù)訂購裝置1的第一接口單元 111接收該服務(wù)訂購實例查詢請求。訂購請求處理單元113的查詢請求處理單元查詢數(shù)據(jù) 庫中保存的與該請求用戶相關(guān)的用戶權(quán)限信息，并依據(jù)返回的用戶權(quán)限信息判斷請求用戶 是否有權(quán)限查詢請求中的服務(wù)訂購實例。若判斷失敗，則發(fā)送查詢失敗信息至請求用戶。若 判斷成功，則查詢數(shù)據(jù)庫中保存的與該服務(wù)訂購實例查詢請求相關(guān)的數(shù)據(jù)，并將該查詢到 的數(shù)據(jù)發(fā)送至請求用戶。訂購請求處理單元113收到訂購信息修改、刪除、禁用或啟用請求后，可以先進行 訂購信息查詢，再進行訂購信息修改、刪除、禁用或啟用修改。較佳的，僅有機構(gòu)管理員具有 修改、刪除、禁用或啟用訂購信息的權(quán)限，機構(gòu)內(nèi)的普通用戶具有查詢訂購信息權(quán)限。刪除 請求處理單元刪除訂購信息時，只對該訂購信息做刪除標識，不刪除訂購信息涉及的數(shù)據(jù)。 訂購請求處理單元113的適于禁用、啟用請求處理單元單個或批量禁用或啟用訂購信息。 訂購請求處理單元113還適于在修改、刪除、禁用或啟用訂購信息后，更新的服務(wù)訂購信息 包括發(fā)起請求的用戶對應(yīng)的訂購信息、應(yīng)用訂購實例信息、授權(quán)信息等。用戶代表所述機構(gòu)發(fā)出服務(wù)訂購請求。所述的機構(gòu)具有一個或者多個用戶，一個 機構(gòu)可以發(fā)出多個服務(wù)訂購請求。機構(gòu)內(nèi)的用戶需要訂購服務(wù)時，均以其所屬機構(gòu)的名義 發(fā)出服務(wù)訂購請求。較佳的，機構(gòu)具有一個機構(gòu)管理員，機構(gòu)內(nèi)的普通用戶需要訂購服務(wù) 時，均由機構(gòu)管理員以機構(gòu)名義發(fā)出服務(wù)訂購請求。
值得注意的是，一個用戶可以屬于一個或多個機構(gòu)。當一個用戶屬于多個機構(gòu)時， 其所屬的多個機構(gòu)發(fā)出的服務(wù)訂購請求會相應(yīng)產(chǎn)生多個訂購實例，則該用戶可以具有多個 訂購實例，但是，每個訂購實例只屬于一個訂購信息。例如，一個用戶需要在兩個機構(gòu)中訂 購?fù)粋€服務(wù)的同一個角色，也必須產(chǎn)生兩個訂購實例分別對應(yīng)兩個機構(gòu)的訂購信息。若 訂購請求機構(gòu)被刪除，則該機構(gòu)所有發(fā)出的所有訂購信息狀態(tài)修改為禁用。為了方便用戶訂購，可預(yù)先查詢可以訂購的服務(wù)和角色信息，再訂購所需服務(wù)和 角色，生成訂購實例。服務(wù)由不同的功能點組成，每個功能點對應(yīng)一個接口、一個流程等，每 個角色具有使用不同功能點集合的權(quán)限。如圖5所示，本發(fā)明提供的適配于云交易平臺的用戶權(quán)限設(shè)置裝置2包括訂購信 息獲取單元211、組織設(shè)置單元212、組織角色設(shè)置單元213和組織成員設(shè)置單元214。訂購 信息獲取單元211，適于獲取所述云交易平臺生成的訂購信息；所述訂購信息中至少包括 機構(gòu)信息、訂購的服務(wù)信息、針對所述服務(wù)訂購的角色信息。組織設(shè)置單元212，適于接收組 織設(shè)置請求操作，為前述機構(gòu)設(shè)置至少一個組織。組織角色設(shè)置單元213，適于接收組織角 色設(shè)置請求操作，為前述各組織設(shè)置至少一個訂購的角色信息。組織成員設(shè)置單元214，適 于接收組織成員設(shè)置請求操作，為前述各組織添加至少一個成員；針對所述訂購的服務(wù)，所 述成員具備其所屬組織的角色。如圖6所示，本發(fā)明還提供用戶權(quán)限設(shè)置方法，包括以下步驟步驟S21，獲取所述云交易平臺生成的訂購信息，所述訂購信息中至少包括機構(gòu)信 息、訂購的服務(wù)信息、針對所述服務(wù)訂購的角色信息。步驟S22，接收組織設(shè)置請求操作，為前述機構(gòu)設(shè)置至少一個組織。步驟S23，接收組織角色設(shè)置請求操作，為前述各組織設(shè)置至少一個訂購的角色信 肩、ο步驟S24，接收組織成員設(shè)置請求操作，為前述各組織添加至少一個成員；針對所 述訂購的服務(wù)，所述成員具備其所屬組織的角色。下面結(jié)合附圖5、6對本發(fā)明提供的用戶權(quán)限設(shè)置裝置和用戶權(quán)限設(shè)置方法進行 更詳細的說明。訂購信息獲取單元211獲取的訂購信息至少包括機構(gòu)信息、訂購的服務(wù)信息、針 對所述服務(wù)訂購的角色信息。機構(gòu)信息包括ID、機構(gòu)名稱、一個所屬該機構(gòu)的用戶的ID、 狀態(tài)。服務(wù)信息包括ID、服務(wù)代碼、服務(wù)名、服務(wù)擴展名、服務(wù)描述、狀態(tài)、創(chuàng)建者、創(chuàng)建日 期、更新者、更新日期。角色信息包括ID、角色代碼、角色名稱、所屬應(yīng)用的ID、角色級別、 描述、狀態(tài)、創(chuàng)建者、創(chuàng)建日期、更新者、更新日期。組織設(shè)置單元212，適于接收組織設(shè)置請求操作，為前述機構(gòu)設(shè)置至少一個組織。 組織設(shè)置請求包含機構(gòu)ID和組織代碼等。如圖7所示，所述數(shù)據(jù)庫保存有與發(fā)起請求用戶 信息、已建立的組織信息，以及用戶權(quán)限信息等。用戶通過終端設(shè)備發(fā)出組織設(shè)置請求，組織設(shè)置單元212接收所述組織設(shè)置請 求。組織設(shè)置單元212查詢數(shù)據(jù)庫中保存的與該請求用戶相關(guān)的用戶權(quán)限信息，并依據(jù)返 回的用戶權(quán)限信息判斷請求用戶是否有權(quán)限添加所述組織。若判斷失敗，則發(fā)送添加失敗信息至請求用戶。若判斷成功，則查詢數(shù)據(jù)庫有無與 請求中的組織相關(guān)的信息。若返回的查詢結(jié)果為數(shù)據(jù)庫已有與請求中的組織相關(guān)的信息，則組織設(shè)置單元212發(fā)送添加組織失敗信息至請求用戶。若返回的查詢結(jié)果為數(shù)據(jù)庫沒有 與請求中的組織相關(guān)的信息，則建立所述組織，并添加組織信息至數(shù)據(jù)庫、發(fā)送添加組織成 功至請求用戶。組織信息包括ID、組織代碼、組織名稱、父組織的ID、所屬機構(gòu)ID、組織類型、節(jié) 點類型、描述、創(chuàng)建者、創(chuàng)建日期、更新者、更新日期。組織角色設(shè)置單元213分析所述訂購的角色信息，關(guān)聯(lián)所述角色信息與所述機構(gòu) 下已經(jīng)設(shè)置的組織。關(guān)聯(lián)后的組織具有該角色對應(yīng)的權(quán)限。組織成員設(shè)置單元214，適于接收組織成員設(shè)置請求操作，為前述各組織添加至少 一個成員；針對所述訂購的服務(wù)，所述成員具備其所屬組織的角色。組織成員設(shè)置請求包含 組織代碼和用戶ID等。可選擇的，組織成員設(shè)置單元214向組織中設(shè)置用戶前，可以先對所述組織進行 查詢。如圖8所述，所述數(shù)據(jù)庫保存有與發(fā)起請求用戶信息、已建立的組織信息，以及用 戶權(quán)限信息等。所述數(shù)據(jù)庫還可以保存有已經(jīng)建立的用戶和組織關(guān)系信息。用戶通過終端設(shè)備發(fā)出組織成員設(shè)置請求，組織成員設(shè)置單元214接收所述組織 成員設(shè)置請求。組織成員設(shè)置單元214查詢數(shù)據(jù)庫中保存的與該請求用戶相關(guān)的用戶權(quán)限 信息，并依據(jù)返回的用戶權(quán)限信息判斷請求用戶是否有權(quán)限在所述組織下設(shè)置成員。若判 斷失敗，則發(fā)送設(shè)置失敗信息至請求用戶。若判斷成功，則在所述組織下添加所述成員，添 加所述用戶和組織關(guān)系信息至數(shù)據(jù)庫，并發(fā)送設(shè)置成功信息至請求用戶。所述用戶和組織的關(guān)系信息包括ID、用戶的ID、所屬組織的ID、狀態(tài)、創(chuàng)建者、創(chuàng) 建日期、更新者、更新日期。組織成員設(shè)置單元214還可以依據(jù)組織成員刪除請求，刪除所述組織中已經(jīng)設(shè)置 的用戶。與設(shè)置成員類似，用戶通過終端設(shè)備發(fā)出組織成員刪除請求，組織成員設(shè)置單元 214接收所述組織成員刪除請求。組織成員設(shè)置單元214查詢數(shù)據(jù)庫中保存的與該請求用 戶相關(guān)的用戶權(quán)限信息，并依據(jù)返回的用戶權(quán)限信息判斷請求用戶是否有權(quán)限刪除在所述 組織下已經(jīng)設(shè)置的用戶。若判斷失敗，則發(fā)送設(shè)置失敗信息至請求用戶。若判斷成功，則刪 除所述組織中的用戶信息、所述用戶和組織關(guān)系信息至數(shù)據(jù)庫，并發(fā)送刪除成功信息至請 求用戶。為組織設(shè)置角色和成員后，所述組織內(nèi)的用戶均具有使用為所述組織設(shè)置的角色 的權(quán)限。例如，組織角色設(shè)置單元213為組織1設(shè)置有角色1，組織成員設(shè)置單元214為組 織1設(shè)置用戶1和用戶2，則用戶1和用戶2均具有使用角色1的權(quán)限。通過設(shè)置組織、為 組織設(shè)置角色和用戶可以方便的實現(xiàn)服務(wù)、角色與用戶的關(guān)聯(lián)。類似的，通過在組織中刪除 用戶，可以移除用戶使用所述角色的權(quán)限。這樣一來，方便了服務(wù)、角色的授權(quán)管理及應(yīng)用。另外一實施例中，所述用戶權(quán)限設(shè)置裝置2還包括用戶權(quán)限信息生成單元和發(fā) 送單元。所述用戶權(quán)限信息生成單元適于生成用戶權(quán)限信息，所述發(fā)送單元適于發(fā)送所述 用戶權(quán)限信息。生成的用戶權(quán)限信息被發(fā)送至云交易平臺和數(shù)據(jù)庫。所述用戶權(quán)限信息包 括用戶分別具有建立、刪除、修改、禁用、啟用組織的權(quán)限，以及為組織設(shè)置、刪除成員的權(quán) 限。用戶可以分為系統(tǒng)管理員、機構(gòu)管理員和一般用戶，權(quán)限遞減。系統(tǒng)管理員可以添加、 修改、刪除禁用和啟用任何機構(gòu)管理員和用戶。機構(gòu)管理員可以添加、修改、刪除禁用和啟用任何本機構(gòu)的用戶。系統(tǒng)管理員可以為某機構(gòu)添加該機構(gòu)管理員。通常組織機構(gòu)管理員向云平臺訂購服務(wù)，并根據(jù)需要將訂購的服務(wù)的角色分配給 不同的用戶或用戶組又一實施例中，用戶權(quán)限設(shè)置裝置2還包括組織查詢請求處理單元、組織修改請 求處理單元、組織刪除請求處理單元、組織禁用請求處理單元、組織啟用請求處理單元中的 一個或多個。所述組織信息查詢、修改、刪除、禁用、啟用請求至少對應(yīng)發(fā)起請求的用戶信息 和組織ID。所述組織查詢請求處理單元適于接收組織信息查詢請求，查詢已經(jīng)生成的訂購信 息。所述組織修改請求處理單元適于接收組織信息修改請求，修改已經(jīng)設(shè)置的組織信息。所 述組織刪除請求處理單元適于接收組織信息刪除請求，刪除已經(jīng)設(shè)置的組織信息。所述組 織禁用請求處理單元適于接收組織信息禁用請求，禁用已經(jīng)設(shè)置的組織信息。所述組織啟 用請求處理單元適于接收組織信息啟用請求，啟用已經(jīng)設(shè)置的組織信息。所述組織修改請求處理單元修改組織，包括修改組織信息。組織刪除請求處理單 元刪除組織，包括刪除組織信息。組織禁用請求處理單元禁用組織，包括設(shè)置組織信息中的 狀態(tài)為禁用。組織啟用請求處理單元啟用組織，包括設(shè)置組織信息中的狀態(tài)為啟用。較佳的，進行上述組織信息查詢、修改、刪除、禁用、啟用前依據(jù)用戶信息，查詢數(shù) 據(jù)庫中的用戶權(quán)限信息，對請求用戶進行權(quán)限查詢。系統(tǒng)管理員可以請求禁用所有的組織， 機構(gòu)管理員可以請求禁用其所屬機構(gòu)下的所有組織。用戶權(quán)限設(shè)置裝置2還適于在已經(jīng)建立的組織下擴展組織，在組織中擴展組織的 方式與在機構(gòu)中建立組織的方式類似，此處不在贅述。如圖9所示，本發(fā)明提供的云交易平臺管理系統(tǒng)還包括訂購信息獲取單元3、用 戶權(quán)限信息接收單元4和信息管理單元5。所述訂購信息獲取單元3，與所述服務(wù)訂購裝置 匹配，適于獲取與所述服務(wù)訂購請求對應(yīng)的訂購信息。用戶權(quán)限信息接收單元4，與用戶權(quán) 限設(shè)置裝置匹配，適于接收用戶權(quán)限信息。信息管理單元5，適于處理所述用戶權(quán)限信息和 所述訂購信息。當用戶以機構(gòu)名義訂購服務(wù)、角色后，所述訂購信息獲取單元3獲取與所述服務(wù) 訂購請求對應(yīng)的訂購信息；用戶權(quán)限信息接收單元4發(fā)出用戶權(quán)限信息后，用戶權(quán)限信息 接收單元4接收用戶權(quán)限信息；信息管理單元5處理所述用戶權(quán)限信息和訂購信息。處理 所述用戶權(quán)限信息和訂購信息后，用戶的權(quán)限信息與該用戶所屬機構(gòu)的訂購信息被關(guān)聯(lián)在一起。例如，用戶1以機構(gòu)1的名義發(fā)出對應(yīng)服務(wù)1中的角色1和角色2的服務(wù)訂購請 求。服務(wù)訂購裝置1生成訂購信息并向用戶1發(fā)送訂購成功信息。用戶1依據(jù)訂購信息， 在機構(gòu)1內(nèi)設(shè)置組織1和組織2，組織1被設(shè)置服務(wù)1的角色1，組織2被設(shè)置服務(wù)1的角 色2的，用戶1被設(shè)置在組織1內(nèi)，用戶2被設(shè)置在組織2內(nèi)。信息管理單元5處理上述用 戶權(quán)限信息和訂購信息，處理后，用戶1與機構(gòu)1、組織1、角色1相關(guān)聯(lián)，用戶2與機構(gòu)2、組 織2、角色2相關(guān)聯(lián)。應(yīng)當理解的是，用戶權(quán)限信息和訂購信息內(nèi)容可以包含更多內(nèi)容，信息 管理單元5處理的內(nèi)容可以更豐富。在訂購信息或用戶權(quán)限信息發(fā)生變更時，信息管理單元5做出與所述變更內(nèi)容對 應(yīng)的處理。信息管理單元5還適于接收的信息，查詢與所述用戶權(quán)限信息和與之對應(yīng)的訂購信息內(nèi)容。 雖然本發(fā)明己以較佳實施例披露如上，但本發(fā)明并非限定于此。任何本領(lǐng)域技術(shù) 人員，在不脫離本發(fā)明的精神和范圍內(nèi)，均可作各種更動與修改，因此本發(fā)明的保護范圍應(yīng) 當以權(quán)利要求所限定的范圍。
權(quán)利要求
一種用戶權(quán)限設(shè)置方法，其特征在于，包括獲取所述云交易平臺生成的訂購信息；所述訂購信息中至少包括機構(gòu)信息、訂購的服務(wù)信息、針對所述服務(wù)訂購的角色信息；接收組織設(shè)置請求操作，為前述機構(gòu)設(shè)置至少一個組織；接收組織角色設(shè)置請求操作，為前述各組織設(shè)置至少一個訂購的角色信息；接收組織成員設(shè)置請求操作，為前述各組織添加至少一個成員；針對所述訂購的服務(wù)，所述成員具備其所屬組織的角色。
2.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，還包括生成用戶權(quán)限信息；發(fā)送所述用戶權(quán)限信息。
3.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述為前述機構(gòu)設(shè)置至少一個 組織包括接收設(shè)置組織請求；判斷發(fā)出設(shè)置組織請求的用戶是否有權(quán)限添加所述組織； 判斷成功時，查詢數(shù)據(jù)庫有無與請求中的組織相關(guān)的信息；在未查詢到與請求中的組織相 關(guān)的信息時，建立所述組織。
4.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述為前述各組織添加至少一 個成員包括對所述組織進行查詢。
5.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述為前述各組織添加至少一 個成員包括接收組織成員設(shè)置請求；判斷發(fā)出所述組織成員設(shè)置請求的用戶是否有權(quán)限 在所述組織下設(shè)置成員；判斷成功時，在所述組織下添加所述成員，以及生成用戶和組織的 關(guān)系信息。
6.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述組織成員設(shè)置方法還包括 刪除組織中已經(jīng)設(shè)置的用戶。
7.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述用戶權(quán)限設(shè)置方法還包括 查詢已設(shè)置的組織。
8.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述用戶權(quán)限設(shè)置裝置還包括 修改已設(shè)置的組織。
9.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述用戶權(quán)限設(shè)置裝置還包括 刪除已設(shè)置的組織。
10.如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述用戶權(quán)限設(shè)置裝置還包括 禁用已設(shè)置的組織。如權(quán)利要求1所述用戶權(quán)限設(shè)置方法，其特征在于，所述用戶權(quán)限設(shè)置裝置還包括啟 用已設(shè)置的組織。
全文摘要
本發(fā)明提供一種用戶權(quán)限設(shè)置方法，包括獲取所述云交易平臺生成的訂購信息；所述訂購信息中至少包括機構(gòu)信息、訂購的服務(wù)信息、針對所述服務(wù)訂購的角色信息；接收組織設(shè)置請求操作，為前述機構(gòu)設(shè)置至少一個組織；接收組織角色設(shè)置請求操作，為前述各組織設(shè)置至少一個訂購的角色信息；接收組織成員設(shè)置請求操作，為前述各組織添加至少一個成員；針對所述訂購的服務(wù)，所述成員具備其所屬組織的角色。
文檔編號G06Q30/00GK101951409SQ20101050309
公開日2011年1月19日 申請日期2010年9月30日 優(yōu)先權(quán)日2010年9月30日
發(fā)明者虞鋼 申請人:西本新干線股份有限公司