Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "/Stardust/KnowledgeBase/Customization/Portal/Role Based Stardust UI Customization Using Spring Bean Post-processor"

m
m
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
−
In this article, we will see how you can customize access permission to the Stardust Portal UI components using spring bean post processor approach.
+
In this article, we will see how you can customize role based access permission to the Stardust Portal UI components using spring bean post processor approach.
  
−
In the portal, perspectives, launch panels, and views are implemented and controlled by spring backing beans. The spring backing beans take care of UI component visibility (like launch panel links) and role based access permissions.
+
In the Stardust portal framework, perspectives, launch panels, and views are implemented and controlled by spring backing beans. The spring beans take care of UI component visibility (like launch panel links) and role based access permissions.
  
−
If you need to change the default UI access policy, you can use spring bean post processor and change access
+
If you need to change the default UI access policy, you can use spring bean post processor to access component backing beans and change the required or restricted roles. You can achieve things like  
−
*permissions by changing UI component backing beans as per your need. For example, you can change the things like:
+
*Restrict access to X perspective for users with role R1.
−
*Make the ‘my documents’ launch panel not to be accessible to X role;
+
*Restrict access of users with role R2 to view V1.
 +
*Hide the launch panel, say managements view from BCC perspective, to users with role R2.
  
−
Restrict the process details view to be visible for Role Y and so on
 
 
Now let us see all this in action with illustrative example;
 
Now let us see all this in action with illustrative example;
  
  
 
== Spring Bean Post-processor ==
 
== Spring Bean Post-processor ==
−
As you know once we create a class implementing spring’s BeanPostProcessor and defines it as a bean in spring context file. The post process has two call back methods, one before bean initialization and second after bean initialization.
+
As you know once we create a class implementing spring’s BeanPostProcessor and define it as a bean in spring context file. The post process has two call back methods, one before bean initialization and second after bean initialization.  
  
 
The spring framework will invoke your post processor for every bean in the given spring context during context initialization.
 
The spring framework will invoke your post processor for every bean in the given spring context during context initialization.
Line 19: Line 19:
 
In this case, we will use the bean post processors after initialization method to access initialized Stardust Portal UI beans and change default access permissions as per our needs.
 
In this case, we will use the bean post processors after initialization method to access initialized Stardust Portal UI beans and change default access permissions as per our needs.
  
−
The following section shows how to customize UI access with few select use cases and code snippets.
+
The following section shows how to customize UI access with select use cases and code snippets.
  
  
 
== Customizing Perspective Access ==
 
== Customizing Perspective Access ==
−
By default, Business Control Center perspective is available all roles. But you want to change this and hide BCC perspective to a role, say “RoleX”.  This can be achieved using bean post process as shown in the follow code snippets; Where, '''SidsIssueModel''' is a model id and '''Role_2''' is Role id for which we want to add restrictions.
+
By default, Business Control Center perspective is available all roles. But if you want to change this default behavior and hide BCC perspective to a role, say “Role 2”.  This can be achieved using bean post process as shown in the follow code snippet below; Where, '''SidsIssueModel''' is a model id and '''Role_2''' is Role id for which we want to add restrictions.
  
 
<source lang="Java">
 
<source lang="Java">
Line 40: Line 40:
  
 
== Restricting Views ==
 
== Restricting Views ==
−
There are common views, meaning available from multiple perspective of the Stardust portal. Thus they are shared. Common views example are document view, document search view, and process instance details view.
+
There are common views, meaning one view is available in multiple perspective of the Stardust portal. Thus they are shared. The example of common views are document view, document search view, and process instance details view. They are available in workflow, BCC, and admin perspectieves.
 
   
 
   
−
Now, consider that we want to restrict the process instance details view and document search views to “RoleX”. The code snippets below show how.
+
Now, consider that we want to restrict the process instance details view and document search view to “Role 2”. The code snippets below show how.
  
 
<source lang="Java">
 
<source lang="Java">
Line 56: Line 56:
 
</source>
 
</source>
  
−
'''Note that links to these views remain active in the portal. But when you click on them, you get a custom message saying, you do not have access to the given view, and the use is restricted to the view.'''
+
'''Note that links to these views remain active in the portal. But when you click on them, you get a custom message saying, you do not have access to the given view, and thus the access is restricted to the view.'''
  
  
 
== Restricting Launch Panels ==
 
== Restricting Launch Panels ==
−
Now, we will see how to restrict access to launch panels for the given perspective. Consider that we want to restrict '''RoleX''' users from accessing management views launch panel of the BCC perspective. Here is the code snippet that does it.
+
Now, we will see how to restrict access to launch panels for the given perspective. Consider that we want to restrict '''Role 2''' users from accessing management views launch panel of the BCC perspective. Here is the code snippet that does it.
 
<source lang="Java">
 
<source lang="Java">
 
...
 
...

Revision as of 07:40, 13 December 2011

Introduction

In this article, we will see how you can customize role based access permission to the Stardust Portal UI components using spring bean post processor approach.

In the Stardust portal framework, perspectives, launch panels, and views are implemented and controlled by spring backing beans. The spring beans take care of UI component visibility (like launch panel links) and role based access permissions.

If you need to change the default UI access policy, you can use spring bean post processor to access component backing beans and change the required or restricted roles. You can achieve things like

  • Restrict access to X perspective for users with role R1.
  • Restrict access of users with role R2 to view V1.
  • Hide the launch panel, say managements view from BCC perspective, to users with role R2.

Now let us see all this in action with illustrative example;


Spring Bean Post-processor

As you know once we create a class implementing spring’s BeanPostProcessor and define it as a bean in spring context file. The post process has two call back methods, one before bean initialization and second after bean initialization.

The spring framework will invoke your post processor for every bean in the given spring context during context initialization.

In this case, we will use the bean post processors after initialization method to access initialized Stardust Portal UI beans and change default access permissions as per our needs.

The following section shows how to customize UI access with select use cases and code snippets.


Customizing Perspective Access

By default, Business Control Center perspective is available all roles. But if you want to change this default behavior and hide BCC perspective to a role, say “Role 2”. This can be achieved using bean post process as shown in the follow code snippet below; Where, SidsIssueModel is a model id and Role_2 is Role id for which we want to add restrictions. 

...
 
             if (bean instanceof PerspectiveDefinition) {
			PerspectiveDefinition perspectiveBean = (PerspectiveDefinition) bean;			
			if (perspectiveBean.getName().equals("ippBccPerspective")) {
				perspectiveBean.setExcludeRoles(perspectiveBean
							.getExcludeRoles() + ",{SidsIssueModel}Role_2");			
			}
		}


Restricting Views

There are common views, meaning one view is available in multiple perspective of the Stardust portal. Thus they are shared. The example of common views are document view, document search view, and process instance details view. They are available in workflow, BCC, and admin perspectieves.

Now, consider that we want to restrict the process instance details view and document search view to “Role 2”. The code snippets below show how. 

...
 
             if (bean instanceof ViewDefinition) {			
			ViewDefinition view = (ViewDefinition) bean;			
			if(view.getName().equals("documentSearchView") 
                           || view.getName().equals("processInstanceDetailsView") ){
				view.setExcludeRoles(view.getExcludeRoles()+ ",{SidsIssueModel}Role_2");
			}			
		}

Note that links to these views remain active in the portal. But when you click on them, you get a custom message saying, you do not have access to the given view, and thus the access is restricted to the view.


Restricting Launch Panels

Now, we will see how to restrict access to launch panels for the given perspective. Consider that we want to restrict Role 2 users from accessing management views launch panel of the BCC perspective. Here is the code snippet that does it. 

...
 
            if (bean instanceof LaunchPanel) {
			LaunchPanel lp = (LaunchPanel) bean;
			if(lp.getName().equals("managementViews")){
				lp.setExcludeRoles(lp.getExcludeRoles()+ ",{SidsIssueModel}Role_2");				
			}
		}


Spring Bean Post Processor Source Code

package com.test;
 
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;
 
import com.infinity.bpm.portal.common.LaunchPanel;
import com.infinity.bpm.portal.common.PerspectiveDefinition;
import com.infinity.bpm.portal.common.ViewDefinition;
 
public class PortalUIPostProcessor implements BeanPostProcessor {
 
	@Override
	public Object postProcessAfterInitialization(Object bean, String beanId)
			throws BeansException {
 
		if (bean instanceof PerspectiveDefinition) {
			PerspectiveDefinition perspectiveBean = (PerspectiveDefinition) bean;			
			if (perspectiveBean.getName().equals("ippBccPerspective")) {
				perspectiveBean.setExcludeRoles(perspectiveBean
							.getExcludeRoles() + ",{SidsIssueModel}Role_2");				
			}
		}
 
		if (bean instanceof ViewDefinition) {			
			ViewDefinition view = (ViewDefinition) bean;			
			if(view.getName().equals("documentSearchView") 
                           || view.getName().equals("processInstanceDetailsView") ){
				view.setExcludeRoles(view.getExcludeRoles()+ ",{SidsIssueModel}Role_2");
			}			
		}
 
		if (bean instanceof LaunchPanel) {
			LaunchPanel lp = (LaunchPanel) bean;
			if(lp.getName().equals("managementViews")){
				lp.setExcludeRoles(lp.getExcludeRoles()+ ",{SidsIssueModel}Role_2");				
			}
		}
 
 
		return bean;
	}
 
	@Override
	public Object postProcessBeforeInitialization(Object bean, String arg1)
			throws BeansException {
		// TODO Auto-generated method stub
		return bean;
	}
}
Retrieved from "https://wiki.eclipse.org/index.php?title=/Stardust/KnowledgeBase/Customization/Portal/Role_Based_Stardust_UI_Customization_Using_Spring_Bean_Post-processor&oldid=282073"

Back to the top