Managing Dynamic Web Menus with Oracle Portal 10g
I recently presented a paper at Collaborate 2007 that discussed leveraging Oracle Portal for Identity Management. This is a short excerpt from that presentation:
Case Study: Creating Dynamic Web Menus
XYZ Manufacturing decides that future web development will leverage the Oracle Portal framework; however, any legacy applications will continue to operate using their existing environments. For administrators, this scenario presents challenges for synchronizing security among the various legacy systems and complexity since multiple administration systems are likely to exist. In the following scenario, XYZ creates a new, web-based reporting interface with hierarchically-structured menu-items designed to access specific reports. The dynamic menus are constructed based upon privilege settings from the user’s Portal group membership.
Creating “Bottom-Up” Group Hierarchies
With a web menu, users gain access to the individual lowest-level menu items as well as all direct parents to preserve the visual structure of the menu. For this example, the XYZ Manufacturing’s web-enabled reporting system includes the following menu structure:
A user with access to only the Sales Forecast report must also gain access to the Sales node at Level 2 in the menu and the Reports node at the top of the menu. This is accomplished by creating a series of Portal Groups with children added as members to the direct parents.
Available menu items for a user privileged to view only one report.
To simulate a menu, Group membership moves UP the tree.
Portal Groups provide a powerful framework for developing hierarchical access to content but they lack the breadth of additional meta data that allow them to serve as a repository for dynamic web menu items. However, when Portal Groups and Items are joined into a single construct, the combined object provides a powerful tool for describing and applying a highly-customizable user security model to menus. Since Portal Items can include any number of custom attributes, a Menu Item Type is designed to store meta data such as the displayed text, the menu item type, the order the item appears in a menu and an optional URL for the lowest level items to invoke a report when clicked.
Portal Groups and Associated Items are combined to create a powerful provisioning tool.
Creating Custom item Types and the Hierarchical Menu
1. Create attributes from Navigator –> Page Groups –> Shared Objects –> Attributes –> Create New Attribute screen.
2. Create a custom item type from Navigator –> Page Groups –> Shared Objects –> Item Types –> Create New Item Type screen. Click to edit the item properties. The custom attributes are added under the Edit Item Type –> Attributes screen.
3. Create a page to contain the hierarchical menu as a set of Items and Sub-Items. The page itself is not accessed or viewable by users and does not require formatting, however it serves as a helpful visual aide for administrators to review the complete menu structure. In order to successfully traverse the menu with queries, subordinate items are created as Sub-Items; only menu items with no parents are created as Items.
4. Enable Item Level Security for the entire page as well as for each individual Item that is added to the page. Granting access to the associated Group in the menu hierarchy links the two constructs (i.e. Sales Item <-- --> Sales Group) and allows the Item to serve as the repository for the menu item metadata.
Note: Screen shots of the above process can be found in the full white paper.
Creating Consolidation Groups to Ease Administration
Because the Group hierarchical structure for a menu is built in a bottom-up fashion, administration can be tedious without the help of a Consolidation Group. In the absence of a Consolidation Group, granting access to all reports in the menu requires the administrator to add the user to each individual lowest level Group. Although this example depicts only four report options, a real-word scenario might have dozens or even hundreds of reports.
In Figure 15, the menu structure is inverted from Figure 8 to depict the lowest levels (individual reports) at the top and additionally includes a Consolidation Group (the All Menu Items Group). A Consolidation Group can include any logical subset of the reports that might be granted to a large number of users. It is conceivable that a Sales or Orders Consolidation Group (no to be confused with the Sales and Orders Groups that govern the menu items only) might be added to simplify the administration of different user roles.
In this example, User 1 sees the Order Detail Group, Order Group (the immediate “child” in this inverted view) and the Reports Group (ultimate “child” in this inverted view) while User 2 inherits access to all Menu Items from the Consolidation Group.
Granting access to an “All Menu Items Group” eases administration.
Putting it All Together - Dynamically Determining Group Access (Menu Items)
The final step for using Portal menu security is to expose the list of allowable Menu Items for a particular user. Since information regarding the structure and order of the menu as well as the URLs for the reports is also included via the attached Items, it is preferable to create a view into this information and return the data in the order the menu might be displayed. The view returns the following rows for a user with access to the entire menu (member of the All Menu Items Group) and the data is used to dynamically render a menu using JSPs or PL/SQL Server Pages and JavaScript.
Rows returned from the dynamic menu view for a user with full access.
The following query was constructed to return a SIBLINGS-sorted list of available menu items for the supplied user. Optionally, the query could include a passed Portal Page name to enable implementation of multiple menus. The query was designed with Subquery Factoring (better known as the WITH clause) to maximize efficiency and could include any number of custom attributes to enable the external application to properly render and control a web menu.
Table descriptions for a dynamic menu item query
This query returns an ordered list of allowable menu items, provided portal.wwctx_api.set_context is first executed for the specified user to ensure that tables are synchronized with Oracle Internet Directory (OID).
WITH temp AS (
SELECT t.masterthingid id,
t.title,
t.parentid,
wa.name item_name,
DECODE(ta.valuetype,'text',ta.value,ta.numbervalue) item_value,
pg1.name parent_page
FROM portal.wwv_things t,
portal.wwpob_page$ pg1,
portal.wwsec_group$ gp,
portal.wwsec_sys_priv$ p,
portal.wwv_user_groups wg,
portal.wwsbr_item_types wit,
portal.wwsbr_attributes wa,
portal.wwsbr_item_type_attributes wita,
portal.wwv_thingattributes ta
WHERE t.siteid = SUBSTR(p.name,1,INSTR(p.name,'/')-1)
and t.masterthingid = substr(p.name,instr(p.name,'/')+1,8)
and p.object_type_name = 'ITEM' -- ITEM / GROUP
and p.grantee_group_id = gp.id
and p.grantee_type = 'GROUP'
and t.siteid = pg1.siteid
and pg1.id = 1
and wg.group_name = gp.name
and wg.user_name = UPPER('GPIKE')
and wit.name = 'MenuItem'
and wit.id = t.subtype
and ta.masterthingid = t.id
and wita.item_type_id = wit.id
and wita.attribute_id = ta.attributeid
and wa.id = wita.attribute_id
)
SELECT id,title, parentid, menu_item_type, report_id, url, sort_order
FROM (
SELECT temp1.id,
temp1.parentid,
temp1.title,
temp1.item_value menu_item_type,
temp2.item_value report_id,
temp3.item_value url,
temp4.item_value sort_order
FROM temp temp1, temp temp2, temp temp3, temp temp4
WHERE temp1.id = temp2.id
AND temp2.id = temp3.id
AND temp3.id = temp4.id
AND temp1.item_name = 'MenuItemType'
AND temp2.item_name = 'MenuItemReportID'
AND temp3.item_name = 'MenuItemURL'
AND temp4.item_name = 'MenuItemSortOrder'
)
CONNECT BY parentid = PRIOR id
START WITH parentid = 0
ORDER SIBLINGS BY sort_order;
For step by step guidelines for implementing dynamic web menus with Oracle portal, see the full article .
 |
Greg Pike 
|
·
