Attribute Based Administration
Attribute Based Administration provides a facility to customize the layout of a page for individual users. It tells the portal to show or hide pages and portlets based on dynamic characteristics determined at runtime. Portal Personalization rules can be used to control whether a page is displayed in the site navigation; this is managed by choosing a rule appropriate for the user attribute you want to enable to see the page. If the rule returns true, the page or portlet will be shown, otherwise, it will be hidden. If Personalization is not installed or is not enabled in the properties settings, you will not see this option.
Access Control and Visibility Rules
Access control and visibility rules both impact what appears on a portal page or portlet.
Access control determines what a user is allowed to see on a page or in a portlet. In order to see pages and portlets, a user must be explicitly defined as a member of the group that has access. The groups are arranged in a hierarchy and each group is assigned roles such as administrators or editors.
Visibility rules determine what a user will see, or what has been targeted towards a user, and access control is based on group membership, visibility rules use any type of information, including LDAP attributes, or time of day. For example to hide a portlet for an individual in a certain geography, store the location as an attribute in LDAP, and assign a visibility rule hiding the portlet. For example, a user may have access to the revenue figures for all divisions all year round, but these figures should not be displayed prominently except when they are first released. For a week after the figures are first released, the figures for the employee's division should show prominently on their home page. The visibility rule hides figures for divisions the employee is not in and only shows the employee's figure's the week after they are released.
Access control takes precedent over visibility rules. You must have access to a page or portlet before visibility rules can be applied. access control also determines if a page or portlet will be returned in a search; if a user does not have access, he will not be able to see the portlet or page in search results. If a user has access to a portlet or page, but has the visibility rule set to hide the page or portlet, it will show up in search results.
Assign attribute based administration rules to pages and portlets
Attribute based administration rules can be assigned manually in the portal in the Edit Properties and Edit Layout portlets, or through the XML configuration interface. The rule must be present on the system in order to assign it to a page or portlet. This can usually be done using Personalization Publish.
In order to map rules, non-administrator users must be given at least user access to the rule that is being mapped and edit access to the page or portlet where the rule is being mapped.
Pages or portlets on derived pages show an inherited visibility rule if no rule is defined for them. We cannot deselect the inherited visibility rules on derived pages.
Using the XML configuration interface, we can assign a rule to a page or portlet. Set the parameter com.ibm.portal.navigation.rule to indicate the rule to assign to the page or portlet. The value of the parameter should be the rule's unique id or UUID. The UUID can be found by exporting the rule in the Personalization user interface and inspecting the exported XML for the jcr:uuid parameter.
For example, to assign a rule with the UUID
7ce9d5004ee31f41b0d3b944c9f7965c...to a page or portlet, add the following parameter to the content-node in the XML access script:
<parameter name="com.ibm.portal.navigation.rule" type="string" update="set"> <![CDATA[7ce9d5004ee31f41b0d3b944c9f7965c]] </parameter>
Error handling
If there is an error finding or executing a rule assigned to a page or portlet, by default that page or portlet will be hidden. We can override this behavior globally by editing
wps/shared/app/config/services/PersonalizationService.properties...and changing the value of rulesEngine.visibilityDefault to show
...to show portlets or pages if an error occurs. This is particularly useful in development environments.
The property rulesEngine.throwObjectNotFoundException, also located in...
wps/shared/app/config/services/PersonalizationService.properties...specifies what happens if an object such as a user is not found when needed during rule execution. This may occur when Personalization cannot find the current user or when an expected application object does not exist on the session or request at the expected key. When set to false, a null user or object is not treated as an error but is instead only printed to the logs as a warning. Personalization will continue as if the requested attribute of the null object is itself null.
For example, if no user object is found and rulesEngine.throwObjectNotFoundException is set to false, a rule such as
Show page or portlet when user.name is null...would return show
A null user is treated as if the user name is null. However, if no user object was found and rulesEngine.throwObjectNotFoundException is set to true, this same rule would throw an exception. If this rule was used to determine the visibility of a page or portlet, the ultimate result would depend upon the value of the rulesEngine.visibilityDefault property, which would decide what occurs if an exception is thrown during processing of a rule in attribute based administration.
Related Information