User Manual Oromiya Portal System

Oromia Portal Architecture

Before we dive into the user interface for adding and maintaining various portal resources, it is best to go over the concepts Oromia portal uses to organize a portal.

Portals are accessed by Users.

Users can belong to Organizations or a bureau.

Organizations can be grouped into hierarchies, such as Home Office -> Regional Office -> Satellite Office.

Users, Groups, and Organizations can belong to Communities that have a common interest.

The simplest way to think about this is that you have users and various ways those users can be grouped together. Some of these groupings follow an administratively organized hierarchy, and other groupings may be done by the users themselves (such as different users from multiple organizations starting a community called “Writers” that has a common interest in writing). And other groupings may be done administratively via Roles for other functions that may cut across the portal (such as a Message Board (Forum) Administrators role made up of users from multiple communities and organizations, allowing those users to administer any message board (Forum) in the portal). This way of organizing portal concepts may be illustrated in the following manner:

In the illustration below, each arrow may be read using the words “can be a member of.” So this means that Organizations can be members of Communities, Communities can be members of Roles, Users can be members of anything, and so on.

Though this seems very complex, it provides a powerful mechanism for portal administrators to configure portal resources and security in a consistent and robust manner.

It is important to note that the diagram illustrates only users and their collections. Permissions do not flow through all of these collections: permissions can be assigned to roles only.




Figure 2.1. Portal Architecture

1. Users

Users can be collected in multiple ways. They can be members of a bureau that is employee of the bureau. They can be members of communities which draw together common interests. And they can have roles which describe their functions in the system, and these roles can be scoped by Portal, Organization, or Community.

2. Organizations

In Oromia Portal each bureau is grouped as Organizations. There is also a special type of Organization called a location, which can define where users are specifically located.

Organizations are handy for defining where a user belongs in a particular hierarchy. For example, if you are implementing Oromia portal for a bureau, it may help to define user Abebe Solomon via his position in the organization chart. If Abebe Solomon is an Office manager in the Addis Ababa office, working in the Central region division of the Investment Office, he might be a member of the following organizations:

● Office Manager

● Central region Division

● Addis Ababa Location

Now say that you have placed an Asset Publisher portlet as a static portlet on every user's home page so that you can inform employees of various announcements via the content management system. If you tagged your content appropriately, you could ensure that Abebe Solomon gets any announcements that are meant for Office Managers, the Central region Division, or the Addis Ababa location. Organizations can be members of Communities.

3. Communities

Communities are collections of Users who have a common interest. The Oromia portal default pages are in the Guest community, because everyone whether they are anonymous or members of the portal has a common interest in the default, public pages of your site. There are three types of Communities:

● Open

● Restricted

● Hidden

An Open Community (the default) allows portal users to join and leave the Community whenever they want to, using the Control Panel or Communities portlet added to a page to which they have access. A Restricted Community requires that users be added to the Community by a community administrator. Users may use the Control Panel or the Communities portlet to request membership. A Hidden community is just like a restricted community, with the added concept that it does not show up at all in the Communities portlet or the Control Panel.

4. Roles

There are three kinds of roles:

● Portal Roles

● Organization Roles

● Community Roles

These are called role scopes. Roles are used to define permissions across their scope: across the portal, across an organization, or across a community. For example, consider a role which grants access to create a Message Board category. A Portal role would grant that access across the portal, wherever there was a Message Board portlet.

A Community role would grant that access only within a single community. An Organization role would grant that access only within an Organization. Because Roles are used strictly for portal security, they also do not have pages, like Communities and Organizations. Users, User Groups, Communities, or Organizations can be members of a role.

3. 
   Using the Administration page
   

Figure 3.1 The control Panel

1. Introduction to Portal Administration

The Portal section of the Control Panel is used for most administrative tasks. You will find there an interface for the creation and maintenance of

● Users

● Organizations

● Communities

● User Groups

● Roles

Additionally, it allows you to configure many server settings, including:

● Password Policies

● Default User Associations

● Reserved Screen Names

● Mail Host Names

● Email Notifications

You will use the Portal section of the Control Panel to create your portal structure, implement security, and administer your users. Note that only users with the Administrator role—a portal scoped role—have permission to view this section of the Control Panel




Figure 3.2. Add user form.

2.