This wiki does not contain official documentation and is currently deprecated and read only. Please try reading the documentation on the Liferay Developer Network, the new site dedicated to Liferay documentation. DISCOVER Build your web site, collaborate with your colleagues, manage your content, and more. DEVELOP Build applications that run inside Liferay, extend the features provided out of the box with Liferay's APIs. DISTRIBUTE Let the world know about your app by publishing it in Liferay's marketplace. PARTICIPATE Become a part of Liferay's community, meet other Liferay users, and get involved in the open source project. Rule-based Permissions
Project Title #
Rule-based Permissions
Background #
Liferay has an extensive and fine-grained permissioning system, where permissions for objects can be specified (for example, specifying that a certain user or certain group can VIEW a particular page or piece of content).
The Problem #
Currently, permissions, once specified, are fixed. For example, you can specify that a particular user group can VIEW a specific entry. But you cannot specify that a particular user group can VIEW any entry that has a particular attribute. For example, there's no way to specify that anyone imbued with the "Power User" role can view any asset tagged with "pwr_user".
The Solution #
The idea would be to leverage the asset framework to allow to specify view/update/delete permissions on roles based on asset queries. For instance: role "a" can view all assets tagged with "tag1". Rules should be scoped to apply at the portal/org/site level. If we use 'positive' rules (those which grant permissions) there should be no conflicts. This may be implemented as an improvement of the current permissions administration page, which may remain as is.
Skills Needed #
- Required: Java programming
- Nice to have: Linux packaging knowledge, Shell Scripting, Liferay knowledge
Prerequisites #
None.
Deliverables #
- Code changes to implement the above functionality.
References #
Related Issues #
External References #
None.
