Multiple Organizations in the Repository

If you implement multiple organizations, there are certain considerations when designing the repository structure for your deployment.

Multiple organizations are only available in the professional edition of JasperReports Server.

Organization Folders

In the repository, each organization has its own branch, contained in a folder named after the organization. JasperReports Server automatically restricts users’ view and access to the branch of the repository in their organization’s folder. Organization admins can create any folder structure needed within the organization.

The top folder of an organization is contained in a folder called Organizations in the parent organization. Top-level organizations are contained in a folder called Organizations at the root of the folder hierarchy. Administrators can view and browse the Organizations folder, and if any suborganizations are created, they can also view all folders and resources in the suborganization. As administrators of the parent organization, they can also create folders and resources in the suborganization.

By default, users of an organization can also view and create folders and resources in any suborganization. To prevent this, administrators can change the permissions on the Organizations folder or individual organization folders.

The Organizations folder in every organization is a special folder that is managed by the server. Administrators cannot create folders or resources directly in the Organizations folder. The server creates the folder for each suborganization when the administrator creates a new organization through the Manage > Organizations page. Administrators can create folders and resources in the Folder Template folder in the Organizations folder; these resources are copied into new organizations. For more information, see Default Folders for Organizations

Design Considerations

Careful design of the JasperReports Server repository leads to a clear and robust environment for your BI environment and easy yet secure access for users. One of the main decisions is how you want your organizations and users to access resources: which resources are shared across organizations as opposed to which are specific to a particular organization. This usually breaks down into several scenarios, depending on the resources that organizations need:

Organizations have private resources - Organizations have separate data sources, reports, OLAP views etc. This would be typical in an organization with departments. These private resources would be stored in each organization's own folders, and perhaps only a few resources such as company logos would be shared between them.
Organizations share resources - Resources are kept in the public folders where they can be used by all organizations and users. You may have common data sources and reports across customers, but the underlying data is partitioned by organization. Data level security restricts what users see when running public reports and OLAP views.
Organization share resources, but have some customizations - For example, users in the organization create reports that are private and stored locally, but they access resources in the public folders.
Organizations have a hierarchical organization - You can have one organization containing other organizations. By default, the parent organization can access all the resources of its child organizations. If you don't want this, you must avoid creating suborganizations or customize the server’s multi-organization architecture.

Referencing Resources in the Repository

All resources in the repository can be referenced by Universal Resource Identifiers (URIs), which specifies the resource name and folder path of the resource. Because of the hierarchy of organizations, references are relative to the user accessing them. JasperReports Server transforms relative references into actual resource locations in the repository based on the user’s organization and the organization’s main folder. By default, folder locations are transformed in the following ways:

For organization members, locations in /public are not transformed, but those in the organization’s main folder are transformed to the actual location, for example, /organizations/organization_1.

For example, if a user in org_1 runs a report that references /images/myLogo image resource, the actual path in the repository that is fetched is /organizations/org_1/images/myLogo. If the report also references /Public/sharedLogo, the server fetches the resource in /Public/sharedLogo.

For system admins, locations throughout the repository are not transformed. They see the actual repository path names.

If a system admin runs the same report in the example above, the reference to /images/myLogo attempts to fetch a resource named /image/myLogo, which only works if there is a folder at the root of the repository named images with a copy of the myLogo. The report fails (or is missing a resource) when run by the system admin, unless he logs in as that user through the Manage > Users page.

This transformation enables URIs to reference different resources depending on the organization of the user who accesses them. For example, a report may have an organization-specific logo as an image. We can set up the report as follows:

Logo URI specified in the JRXML: /images/orgLogo. When transformed for each user, the URI accesses a location relative to his organization’s main folder.
Every organization using this report must have a folder named /images containing an image resource with the ID orgLogo. When a user in any organization runs the report, the server fetches the organization-specific image and displays it.

There are three exceptions to references being transformed. In these cases, the references must be literal:

In report units, references to data sources, JRXMLs, or input controls.
In OLAP views, references to OLAP connections.
In OLAP connections, references to data sources or schemas.

Also, because these references are not transformed, you must observe the following:

For maintenance tasks on an organization’s report units, OLAP views and OLAP connections, you must log in to that organization and do the tasks there. You cannot administer the resources as superuser or another organization’s admin.
The three resources (report units, OLAP views and OLAP connections) cannot reference objects across organizations or even in their own parent organization. The reference would not be transformed; it would be taken literally and would fail. For example, if the data source for a report unit is in the /dataSources folder of This_Org, users in That_Org cannot access it because their reference cannot cross organizations.

To test the absolute references, you should login as an admin of the organization using the references. See Testing User Permissions.

Best Practices

The best practices for resources in a repository shared by multiple organizations are as follows:

The system admin must login as an organization user in order to maintain or run organization resources.
Resources with absolute references to resources in organization folders only work for users within the organization or a parent organization.
If a JRXML that accesses organization resources with URIs must run across organizations, then all organizations must have identical folders, object names, and expected object types for those resources.
The public folder should be used for resources that are shared across organizations.
Version: 
Feedback
randomness