The Proposals Wiki has been deprecated in favor of creating Feature Requests in JIRA. If you wish to propose a new idea for a feature, visit the Community Ideas Dashboard and read the Feature Requests Wiki page for more information about submitting your proposal.
« Zurück zu FrontPage

Content Sharing

Description #

Introduction #

This page describes the needs, challenges and potential solutions regarding sharing of content within Liferay Portal v6. Sharing content is an increasing need among Liferay users. This document tries to summarize the different use cases that have been identified as well as the challenges have been faced when implementing sharing solutions for specific scenarios.

What is content sharing? In short it's the ability to publish in a given page of a community/organization content that was created within a different community/organization.

Currently Liferay Portal offers some basic mechanisms for sharing content, but some projects have higher demands and end up extending the portal to add more sharing capabilities. But such custom extensions take time and sometimes they end up facing problems, specially when the effect of sharing in permissions and search are not properly analyzed.

The final goal of this page is to come up with general solutions that can be applied to the product so that sharing can be achieved out of the box. Such solutions must consider all possible consequences of the sharing including how it effects content searches and permissions.

Status: This document is in draft state, it's specifically lacking in use cases and example scenarios. Having more of those would help evaluate each of the solutions proposed.

Background #

Scoping of content #

One of Liferay's Portal characteristics is that all content (in the broad sense of the word) is scoped. That means that each community, organization or user can have its own documents, web contents (journal articles), message board categories and posts, etc.

Note 1: Starting with Liferay Portal 5.2 it's also possible to create subscopes that are associated to an specific page of a community or organization. But such feature will be ignored for simplicity since it's not so relevant for sharing of content.

A content of an organization/community can be published in the public or private pages of that organization/community in two ways:

  • By using its own specific portlet. Example: Document Library, Image Gallery, Message Boards
  • By using generic publishing portlets (only valid for some types of contents). Example: Asset Publisher

Out of the box any content created through any of these portlets will be scoped to the current organization/community.

Challenges #

Permissions #

The permissions system controls (among other things) which users can view certain content.

Web Content is an special case, because by default view permission checks are disabled and all content is considered visible as long as the page in which it's published is visible.

The permission system is also aware of the scoping of content. In particular:

  • Users with the "Administrator" role can manage the content in all scopes
  • Users with the "Organization/Community Administrator" or the "Organization/Community Owner" roles can manage all the content in the organization/community in which the role is assigned.
  • Users that are explicit members of a community/organization (i.e. excluding membership through inheritance) have access to their private pages
  • Users that are explicit members of a community/organization (i.e. excluding membership through inheritance) may have additional permissions on certain contents if specified through the permissions checkboxes by the content creator

All of this is important in the context of content sharing at two different stages:

  1. When the shared content is selected: Which shared content should an administrator of a site be able to publish in his pages? Should it be any content that he can see? What if the selection is dynamic (for example, all web content with a given tag or category)? What if a second site administrator does not have permission to "view" that shared content and needs to change the configuration?
  2. When the shared content is viewed: This is specially important in the context of web content, which has view permission checking disabled by default. Because of this, content sharing could cause a security hole.

The search functionalities must be considered in the context of sharing content. The key question is "should content published in the current pages be found even if it's just a reference to a shared content in a different community/organization?" The answer often given is yes, but unfortunately it's not so easy to implement that in a generic way.

Let's start with a little background. Most content portlets provide its own search box. Such search is always scoped to the current organization/community. Liferay also offers a global search portlet based on Open Search that is able to search across all organizations/communities. The global search portlet takes permissions into consideration and can be configured to either search in the current organization/community or search in all organizations/communities (as permissions allow).

When sharing content there is an important challenge to be solved when doing any search that is not globl, but scoped to a given community or organization. Most search implementations in Liferay find any content that lives in a given scope (organization or community), regardless of whether it's referenced explicitly by a portlet. The only exception is the Web Content search portlet, which can be set up to search only within web content referenced from Web Content display portlets.

Because of this, the search code won't find content that is in other communities, even if it's published in the pages of the current community/organization. That might be very confusing for end users.

Staging #

When publishing shared content that "live" in other communities/organizations it will not be staged with the rest of the content.

Also, the import/export code of each of the portlets used by the staging publication mechanism must be smart enough to handle references to external shared content.

Export/Import #

What should happen when exporting a community/organization that publishes external shared content? Should the references be kept or the external shared content copied?

The answer depends on whether where is the exported content going to be imported. Because of that it should probably be a decision that the user should make during the export.

Alternatively, the system can always do both things and let the user decide when importing. That would be safer, but it might not work properly if there is a lot of referenced external share content.

Current sharing capabilities of Liferay Portal #

Some of Liferay Portal's out of the box portlets provide some basic sharing capabilities:

  • Global Scope
  • The Asset Publisher portlet can publish any content from the global scope: the global scope is accessible through the Control Panel and allows creating and managing all content types (that support scoping).
    • Any organization or community could be allowed to publish the global content by using the Asset Publisher portlet.
    • Any category vocabulary created in the global scope will be accessible when categorizing content in any community or organization.
    • Web content structures and templates created in the global scope can be used from any community or organization
  • RSS portlet: allows publishing content from any other organization/community as long as there is a public RSS feed for it.
    • The Web Content administration portlet allows creating custom feeds of Web Content.
    • The asset publisher portlet allows creating a feed of the content it publishes (since v 6.0)
  • Web Content List portlet (Journal Articles): allows showing a list of content from another community as long as the administrator belongs to it.
  • Web Content Display portlet (Journal Content): allows selecting a content from another community as long as the administrator belongs to it.

Known limitations and challenges #

Content published through any of the sharing mechanisms above will not appear in searches done using any of the search mechanisms other than the OpenSearch search portlet.

Specific to Web Content List and Display portlets #

If an organization/community has 2 or more administrators and they belong to different communities some configuration conflicts may happen. For example, administrator A belongs to community A and configures a Web Content List portlet to display the contents of such community. Later administrator B who does not belong to community A accesses the configuration of such portlet to change some visual setting. But since he doesn't have community A in the list of available communities to grab contents from so if he saves the original selection will be lost.

Permissions #

When using Web Content Display to show content from other communities the administrator is assumed to know what he's doing and no further permission checks are done by default. This default may be changed portal wide through the property journal.article.view.permission.check.enabled

Use Cases #

Sharing content from the top - down #

In other words, content created in an "upper" scope can be used by any subscopes. This is supported currently through the global scope, but it has the limitation that there can only be one scope for shared content.

An extension to this would be to support sharing of content top - down through the hierarchies of organizations. That is, any organization could publish content from taken from any of its parent organizations.

Example (by community member Andrew Gruhn): I've got a parent organization and 30 children organizations of that parent. I have a Web Content in the parent, which I'm positioning on the page as a pre-footer (it's just a bunch of links that wind up on the bottom of the page). I want to have that blob of links on the pre-footer of every page across the parent and all 30 children organizations, but I also want the Web Content in a single location so I can edit it in one place (I definitively do not want to have 31 Web Content blobs of the same set of links re-created in each Organization).

Sharing collaborative content from the bottom up #

Example: Product specific collaboration occurs in their dedicated communities. For instance:

  • forums, blogs, wiki activity, etc on soccer within the "outdoor sports" community
  • forums, blogs, wiki activity, etc on basketball within the "indoor sports" community There is a "parent" community called "Sports" that will pull content from both "outdoor sports" and "indoor sports".

Example (by community member Andrew Gruhn): I've got a child organization under it's parent. Authors within the child organization are blogging away ("News") and one of them writes something so interesting, we want to pull it up to the parent to highlight it for all to see. Via the Asset Publisher of the parent organization, it'd be great to reach into it's child org to pull out that asset of type blog up to the parent.

Another example is a simple intranet: A parent org (Corporate) has child orgs for each department (Sales, HR) or location (US, Asia, etc). The company's main pages are in the parent org, and common content is displayed there, however much of it is sourced from work done in child orgs. A simple case might just aggregate blog posts, or a more comprehensive use case involving all content, like documents, image galleries, or even forum categories. For example, a combined image gallery portlet showing all galleries created across child orgs.

Any such approach should support filtering based on criteria like categories, etc. (imagine a "Front Page" tag when creating a blog post, for example). Naturally permissions would be honored, so that content set to community-only would not filter up, while less restrictive content would show in the parent org.

Specific proposals #

Allow an organization to access content of parent organizations #

STATUS: Planned for 6.1 or 6.2, but still needs review to make sure there aren't any significant challenges

This proposal is to extend the global scope to allow each organization to share content with all the suborganizations. The usage would be exactly the same as it's now with the global scope.

Pending challenges #

There are still several challenges not solved to implement this solution. One of them is how should search work.

This solution can be simplified for specific projects by assuming a given organizations hierarchy. For the general case it's harder to implement.

Provide a mechanism to //send// a copy of a content from one organization to another #

STATUS: Evaluation. Has been implemented in some projects by 3rd parties

This is a mechanism specially useful to support the bottom-up approach. The author of the content is allowed to send the content to the administrators of any parent category and they would be responsible for approving it or not.

It has to be evaluated whether this feature is generic enough to be added as a core functionality.

Configurable sharing per content #

Note: this is a suggestion by Ed Shin

When any content is created show a select box to configure whether to share this content with...

  • Everyone: You want to share this content across Organizations, and you don't care about security.
  • All Members: Default option. This Organization and all Sub-Organizations.
  • This Organization only
  • Me only

Specify sharing scope by using a category vocabulary #

STATUS: Initial discussion

Suggested by Sven Werlen (implemented and tested in a real world project through a hook plugin):


  • Users are attached to organizations and communities.
  • Organizations are attached to regions
  • The region is attached to the agencyPublications
  • Users can publish content with one of the following scope: public, whole agency, region, organization.

We developed a hook for the asset publisher such the scope can be "the entire company" (= all organizations and communities). The users create content in their organization only. Scope is handled with categories (diffusion) and permissions (access). Approval is required when publishing with larger scope than organization.


  • If someone in organization A publishes a content with scope public, that content will appear on the agency and the regions. But the content is still attached to organization A.
  • If someone in organization B publishes a content with scop "region R", that content will appear on that region only.
  • ...

Loose coupling #

We can argue for a different approach of content sharing by advocating a loose coupling between contents and containers. Indeed, we can consider that "linking" container and content, is another aspect that the contributor don't want to face at the first step, when creating a new content.

This will offer more possibilities like letting the contributors choosing to share content between organizations that are not necessarily in the same hierarchy.

You can even be compatible with the current behavior to force (this can be configurable) a "default" container.

Concretely, this will lead to abandon, in content tab of the control panel (where is administration of (web content, wiki, blog, calendar and so on...), the selection of the organization/community.

"Liberal" sharing mode #

This solution consists on creating a new property to enable a "liberal" content sharing mode. When this mode is enabled, the asset publisher will let site administrators to select web content from any community/organization to which they belong.

This means that they trust the source and they are willing to risk the fact that the original content may change. Also, the content authors should assume that their content may be published in the pages of other organization/communities.

This might be too "liberal" for some portals, but based on the feedback of many people it seems that it's exactly what is needed in some other scenarios.

Open Question: should this mode be enabled by default or not?

Implementation details #

Is it really possible to implement this without messing permissions and search completely?

Open questions #

  • Should all content types be considered the same in regards of content sharing? Are the needs of web content, blogs, documents, etc. really the same?

Related discussions #

0 Anhänge
60778 Angesehen
Durchschnitt (2 Stimmen)
Die durchschnittliche Bewertung ist 5.0 von max. 5 Sternen.
Antworten im Thread Autor Datum
This would be a very useful feature - the... david overoye 13. Mai 2011 17:52
For my point of view, I feel your vision too... Lirone75 M. 15. Juli 2011 06:06
In case my last post wasn't clear enough, to be... Lirone75 M. 15. Juli 2011 06:10
The biggest issue, IMHO is security. I would... Raghavendra Jayaram 26. Januar 2012 12:43

This would be a very useful feature - the ability to push content up and down along the organizational structure. I thought this concept on the calendar:­age/1642817 was a good one - allows the user to select where along the organization hierarchy an event would go. Would also need to be connected to workflow to allow organizations above in the hierarchy to approve before posting, while going down the organization might not need the approval.
Gepostet am 13.05.11 17:52.
For my point of view, I feel your vision too skimpy.

Because after doing what you suggest in this proposal, some will suggest sharing content between organizations that are not hierachally organized, and let's start again with content sharing.

For me, it's quite an evidence that there is a problem at the basis because a content is content, the fact that a content is in organisation is another aspect that must not be mixed and that the user don't want to face at the first step of a new content creation.

So for me the better vision is to share content in a weak coupling mode between content and container. This way you can do everything you want and all the customer needs will be fulfiled.

You can even reach the same behavior as now by proposing a "default" container.
Gepostet am 15.07.11 06:06.
In case my last post wasn't clear enough, to be very concrete, my proposition is a way to say that the organization/community selection in the control panel for content (web content, wiki, blog, calendar and so on...) should be abandonned.
Gepostet am 15.07.11 06:10 als Antwort auf Lirone75 M..
The biggest issue, IMHO is security.

I would like to have multiple presentation servers, servicing different types of users (internet based, private network baser) that are permitted to securely share documents between them. My original idea was to use WSRP: producer server for WRSP portlets and all of the presentation servers consuming the portlet (in this case, the Document Library).

Unfortunately, Liferay supports only open, unsecured WSRP connections. Seems to me that a good and secure implementation of WSRP solves a lot of the issues.
Gepostet am 26.01.12 12:43 als Antwort auf Lirone75 M..