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.
« FrontPage に戻る

Portal Improvements

 

Portal Improvments

If there is a feature on this list that is important to you, please leave a comment stating so OR vote (thumbs up) for someone else's comment.  The more votes a given feature has, the more likely it is to be included.

I've started trying to gather all of the posts that related to core portal functionality.  Some of these span a LOT of topics listed below while others only relate to one. In some cases, many people have been posting about essentially the same thing.  If you think something is missing, please feel free to add it in accordance with the guidlines on the front page.

 

Community Posts are referenced here... Please put comments/voting on this page...Post 1, Post 2, Post 3, Post 4, Post 5, Post 6, Post 7, Post 8, Post 9, Post 10, Post 11, Post 12, Post 13, Post 14 Post 15  Post 16  Post 17

Portal Security

  • Fix Session Hijacking (post)
  • Fix Log In with any password by default (post)
  • Encrypt LDAP passwords on import (post)
  • Log failed log in attempts so that admins can stop brute force attacks on portal (post)
  • If a User is removed from a Group, Community, or Org, he should no longer have access to those pages or any content he created/placed there (post)
  • User & Admin decisions on which portions of the profile are public and which are private (post)
  • Visual cues (color, icons, etc.) to distingush between instance and server
  • Log in should be via SSL by default
  • Control panel access should be via SSL by default
  • Admin control panel should be on different URL
  • Provide a dedicated site control panel for each site (at Organization or Community level).
  • Private pages should be via SSL by default
  • Upgrade/patch process should include an alert in the control panel (ala WordPress, SMF, Joomla, etc.)
  • Upgrade/patch process should be able to be conducted from control panel (ala WordPress, SMF, Joomla, etc.)
    • Throw portal into maintence mode
    • Download and install files
    • Backup before beginning to make it brainless (files and database)
    • Check for custom changes to filesat start of install
      • If found, upgrade process is halted
    • Apply patch/upgrade
    • Check for additional upgrades that may need to take place such as specific portlets
    • Repeat steps 2-7 as needed
    • Restart portal and resume normal operations
  • No more configuration from the text file.  Only database options should be there.  All configuration should be from the database and handled via the GUI in the Control Panel.
  • Add virus scan for uploaded files (post)

Plugin Installation

  • Plugins from known repositories should be signed using PGP
  • Mechanism for importing PGP key for new repository
  • Unsigned or incorrectly signed plugins should cause an alert
  • Plugin Installion in Control Panel should supress installed plugins unless there is a new COMPATIBLE version available (e.g latest chat portlet should not appear in list for someone using 3.1)
  • Add feature for undeploying a plug in (post)
  • Needs search function

Portal Instances

  • Stateless operation mode (post)
  •  Lots of settings should be in the instance or even more finely grained and not for the entire server. 

Server Administration

  • Garbage Collector should be able to be scheduled to run from the control panel
  • Reindexing should be able to be scheduled from the control panel
  • Should be able to schedule other activites from control panel
  • Editing of properties should be done from control panel
  • Provide GUI to change the default Liferay logo to any desired logo.The similar feature is available at Community level but not at system level.
  • Provide GUI to change the default Liferay favorite icon to any desired logo.
  • LDAP mapping GUI to custom Liferay attributes (post)

 

Plug Ins Configuration

  • Should be per instance not per server to better assist those who do virtual hosting.  This way I can turn off the photo show for some customers without having to turn it off for everyone on that server.
  • Portal administrator can assign portlets (or other plugins) to a particular instance, group, community, or org. Once assigned, an administrator or owner can then add portlets to their pages from the assigned portlet pool. This is more desired if each site is for different customer (such as in portal hosting environment).
  • Needs search function

Monitoring

  • Stale page reminders
  • Some monitoring should be per instance
  • Should include reporting, click tracking, and heat maps (post)
  • And all of this

Settings

  • Settings should be per instance (Post1) and this post

Password Policy

  • Should be per instance (Post1)

Roles

  • Should be per instance (Post1)

User Groups

  • Should be per instance (Post1)
  • Ability to turn on and turn off public and private pages via the Control Panel
  • Ability to push portlets to public & private pages via the Control Panel
  • GUI for default configuration for public & private pages.  In short, give admin or owner access to a "default" set of public & private pages so that portlets, content, etc. can be added and then pushed out to all the groups in a given instance.
  • Changes to the group pages or their content should also be pushed out to already created users and not only to newly created users
  • Ability to move pages between public and private (Post 9)
  • Show Counts of groups
  • Ability to have User Groups within other Groups (like Orgs and Sub-Orgs)
  • Provide GUI to change the default Liferay favorite icon to any desired logo.
  • Ability to create a template and then mass produce Groups
  • Ability to assign and unassign a user to group dynamically based on predetermined critera (post)
  • Ability associate community roles to user group (post)

Communities

  • Should be per instance (Post1)
  • Ability to turn on and turn off public and private pages via the Control Panel
  • Ability to push portlets to public & private pages via the Control Panel
  • GUI for default configuration for public & private pages.  In short, give admin or owner access to a "default" set of public & private pages so that portlets, content, etc. can be added and then pushed out to all the communities in a given instance.
  • Ability to move pages between public and private (Post 9)
  • Show counts of Communities
  • Provide GUI to change the default Liferay favorite icon to any desired logo.
  • Ability to create a template and then mass produce Communities

Orgainzations

  • Should be per instance (Post1)
  • Ability to turn on and turn off public and private pages via the Control Panel
  • Ability to push portlets to public & private pages via the Control Panel
  • GUI for default configuration for public & private pages.  In short, give admin or owner access to a "default" set of public & private pages so that portlets, content, etc. can be added and then pushed out to all the orgs in a given instance.
  • Should be able to add User Groups (ala LDAP, Active Directory, etc.) to Orgs
  • Ability to move pages between public and private (Post 9)
  • Show counts of orgs
  • Provide GUI to change the default Liferay favorite icon to any desired logo.
  • Ability to create a template and then mass produce Orgs
  • Ability associate community roles to organization (post)

Users

  • Should be per instance (Post1)
  • Ability to turn on and turn off public and private pages via the Control Panel
  • Ability to push portlets to public & private pages via the Control Panel
  • GUI for default configuration for public & private pages.  In short, give admin or owner access to a "default" set of public & private pages so that portlets, content, etc. can be added and then pushed out to all the users in a given instance.
  • Ability to move pages between public and private (Post 9)
  • Show count(s) of users
  • Clone users (post)
  • Custom Attributes Wizard (post)
  • In portal control panel, all users can be displayed and searchable. In site control panel, only users who belong to this site (instance, group, organization or community) can be displayed and searchable.
  • Import process for users from other applications
  • Supress any or all non-required user fields

Portal Functionality

  • Fix browser caching issue (post)
  • Allow user to toggle edit controls off and place link to them in dock if they rights to edit controls (post)
  • Role based top menu (post)
  • Context Sensitive Account creation (post)
  • Multiple Navigation Root (post)
  • Convert orgs, user groups and commnities to each other - e.g. covert an org to a user group or a community or vice versa (post)
  • Friendly URLS for staging (post)
  • Admin and User control for landing page on authentication (post)
  • Fix XHTML (post)
  • Personalization Engine (post)
  • Impersonate Administrator (post)
  • Moving or Renaming Pages would be automagically kept track of (post)
  • Configure Session Time Out on a Per instance, Group, Community, Org or User level (post)
  • Email settings should be per instance at minimum with Server email only going to/from omniadmins not general users.
  • Ability to set landing page after accepting terms of use (Post 13)
  • Ability to lock user out of editing personal settings (useful in a corporate environement where you don't want "SpankyClown" as a screen name- post)
  • Ability to remove a portal instance.
  • Ability to configure the portal in a way that the action-url-redirect redirects are only done for non-ajax requests(post)

Workflows

I debated putting this in a seperate child page but this really does seem to be part of the core issue.  We need to have the ability to institute workflows that don't involve granting "Manage pages" to people.  Manage pages is *dangerous*.  Just using that one right, you can delete every page in your community!  You can rearrage content because it infers "Configuration", "Look and Feel", "Permissions", "Sharing" and a lot of other things that my end users have absolutely NO BUSINESS WHAT SO EVER messing with.  They should be editing text in Web Content Portlets, edting events on their calendars, and editing text on wiki pages. 

Now, in order to lock them out of that stuff, I have to go in and wrap the gear, "Look and Feel", "Configuration", and "Close" for every single portlet in a permission checker that will block them from it. 

I have had to edit the dock.vm and portal_normal.vm to block them from the Control Panel, My Account, Manage Pages, Layout Templates, and anything else where they might get into trouble. 

There has got to be a better way to do work flows.  I'm going to suggest some default roles for this:

Content Editor - someone who change content but not do anything to portlets.  They can fix typos, change dates, upload revisions of documents, etc. 

Content Creator - someone who can edit content but who can also add pages (through the add pages wizard) and add portlets (but not configure them)

Content Remover - someone who can delete pages and remove portlets

Content Approver - someone who can approve changes for their department

Style/Marketing Approver - someone who should be checking content changes for style, message, etc.  but who doesn't have the ability to edit themselves

Final Approver - someone who has the publish to live right. 

0 添付ファイル
28063 参照数
平均 (1 投票)
平均評価は5.0星中の5です。
コメント
コメント 作成者 日時
I see a big need for features to be implemented... Yogesh Gowdra 2009/09/18 9:44
The Administrator should be able to set up... Randy Kevin May 2009/10/20 9:58
where is the original page with my comments? Dmitry Babain 2009/09/21 8:08
That's on the original wiki page before they... Lisa Simpson 2009/09/21 8:40
Liferay has a steep learning curve today. For... Sverker Abrahamsson 2009/09/21 13:01
We actually build out the pages for our users... Lisa Simpson 2009/09/21 14:03
When the navigation bar is of class "sort-pages... Sverker Abrahamsson 2009/09/21 13:05
I'd rather see something else - an option... Lisa Simpson 2009/09/21 14:05
Looking for CLI - Command Line Interface and/or... Raja Nagendra Kumar 2009/09/23 0:11
Extension environment way to define new pages,... Raja Nagendra Kumar 2009/09/23 0:13
A functionnality to add for integrators: -... Mathieu Beaufour 2009/10/08 4:10
Current Liferay Create Account / Registration... Anand Abhyankar 2009/10/09 6:34
I think that all settings and improvement for... Denis Signoretto 2009/11/25 15:16
Convert orgs, user groups and commnities to... James Denmark 2009/11/30 10:58
Ability to create a template and then mass... James Denmark 2009/11/30 11:00
Changes to the group pages or their content... James Denmark 2009/11/30 11:02
Vote for maintenance mode Corné Aussems 2010/02/09 13:59
A non Administrative User who can manage all... Corné Aussems 2010/02/09 14:00
less in portal-ext.properties or better... Corné Aussems 2010/02/09 14:03
I am really interested in a way to mass change... Sean McClelland 2010/03/09 12:51
For Organizations, should be able to add User... Scott Rabon 2010/05/18 16:37
Administration should separate out portal admin... James McGovern 2010/06/13 15:40
Need ability to lock user out of editing... Rick Archibald 2010/09/04 23:07
==Enable Friendly URL Mapper to set JSR-286... Flávio Stutz 2010/12/17 13:54
Very important for me: GUI for default... Piotr Swiniarski 2011/08/16 6:04
A new topic for "Portal Instances" - Ability to... Danny Stevens 2012/07/19 17:05

I see a big need for features to be implemented narrated under "User Groups". I personally have such requirement and have seen loads of similar requirements in the forum.
投稿日時:09/09/18 9:44
where is the original page with my comments?
投稿日時:09/09/21 8:08
That's on the original wiki page before they created this new node.
Dmitry Babainへのコメント。投稿日時:09/09/21 8:40
Liferay has a steep learning curve today. For non-technical users it's hard to get started. For example, I want certain users to be able to create and edit content. Today they have to go to control panel, select web content, create an article and there remember to select the right structure, add the right tags and if they have the right to do so approve it before it can be published.

I'd like to see wizards for common tasks, e.g. create an article which starts a wizard where the user can select which type of article to be created and then the editor is started with all fields filled out.

Another example to add a page of a certain type etc.

These common tasks (and others) could be placed at the first view of the control panel for easy access.
投稿日時:09/09/21 13:01
When the navigation bar is of class "sort-pages modify-pages" then it is possible to directly edit page names, add new pages and move them around. However, it's a bit too powerful so it's easy to blow a hole in your foot.

This feature should only be active when edit controls is turned on.
投稿日時:09/09/21 13:05
We actually build out the pages for our users and then turn them loose with edit-only access. If they want something new, they can ask for it to be created for them. If they want something removed, they can ask that it be removed.

I totally agree with you about the wizards because it's a pain for us to have to manage it.
Sverker Abrahamssonへのコメント。投稿日時:09/09/21 14:03
I'd rather see something else - an option that's currently not present - like "Move Pages" that can be toggled on and off.

That way you could 1) restrict that to a given group of users 2) toggle that seperately from the "Edit" which includes your changing 5 words in a paragraph of text in Web Content.
Sverker Abrahamssonへのコメント。投稿日時:09/09/21 14:05
Looking for CLI - Command Line Interface and/or API and/or extension/plugin sdk way to do all the things which could currently be done using the Admin Console UI.
投稿日時:09/09/23 0:11
Extension environment way to define new pages, new contents and page layouts so that when extension deploy happen all these pages gets loaded on liferay start.

Ref:

http://www.liferay.com/web/guest/community/forums/-/message_boards/mes­sage/4056258
投稿日時:09/09/23 0:13
A functionnality to add for integrators:

- Object-based import-export :
1) Via XML files from the User Interface
2) Via batch processing on the command line

- SQL based import
Provide custom scripts to semi-automate objects creation

Objects in my point of view are :
- Users
- User Groups
- Organizations
- Communities
- Roles
- Pages
- etc...

Finally, bulk assignment functionnality :
1) Bulk assignment of permissions to Roles.
2) Bulk assignment of Roles to User
3) Any other bulk assignment...
投稿日時:09/10/08 4:10
Current Liferay Create Account / Registration Flow

1. Fill Form
2. Auto generated password send through mail
3. Login with this auto-generated password
4. Change password

Alternative Flow
1. Fill form along with user's own password
2. Account is created in Liferay but not activated.
3. Mail send to user with a link, the link will be used only once.
4. When user clicks on the link, he/she is directed to portal/personal/community home page
5. Account is activated.

These two (or more) flows for registration should be configurable.

This 2nd flow is similar to the registration flow for most of the sites like linkedin.com, facebook.com etc.
投稿日時:09/10/09 6:34
The Administrator should be able to set up default public and private pages by User Group. Our clients typically have 500+ Users that use the system rarely enough that having them create their own pages (and add portlets) is not feasible (they actually laughed out loud when this option was presented).
Yogesh Gowdraへのコメント。投稿日時:09/10/20 9:58
I think that all settings and improvement for instances are necessary.
投稿日時:09/11/25 15:16
Convert orgs, user groups and commnities to each other - e.g. convert an org to a user group or a community is an interesting one. We are currently trying to implement a workflow for new organization self registration and will be asking the first user to use the create account workflow and include a custom field with the desired organization name. We will then create the org manually, assign the user as the org admin and then inform them the account is ready. Would be much better if they could just create account and then convert that account to an organization later or better yet, just create an organization and account at the same time.
投稿日時:09/11/30 10:58
Ability to create a template and then mass produce Orgs. We can do it for users and communities, why not orgs?
投稿日時:09/11/30 11:00
Changes to the group pages or their content should also be pushed out to already created users and not only to newly created users. As our site evolves, we really need an easy way to update all existing pages to a new template.
投稿日時:09/11/30 11:02
投稿日時:10/02/09 13:59
A non Administrative User who can manage all users/orgs/groups
投稿日時:10/02/09 14:00
less in portal-ext.properties
or better implementation of company-id-properties
投稿日時:10/02/09 14:03
I am really interested in a way to mass change user profile information as right now we have no way of doing this. If we decide to add a portlet to all of our users profile page we have no automated way of accomplishing this.

On that note two of these items seemed really important:

* Ability to push portlets to public & private pages via the Control Panel

*GUI for default configuration for public & private pages. In short, give admin or owner access to a "default" set of public & private pages so that portlets, content, etc. can be added and then pushed out to all the groups in a given instance.
投稿日時:10/03/09 12:51
For Organizations, should be able to add User Groups (ala LDAP, Active Directory, etc.) to Orgs.
投稿日時:10/05/18 16:37
Administration should separate out portal admin from security admin. The security admin role should be allowed to administer all users/orgs/groups where portal admin should only be portal-specific.

Having more of the properties in a database works in environments where you have lots of portal instances. Otherwise, you would have to push properties to each instance and do multiple restarts.

In order to protect against automated attacks, I believe the best direction for Liferay would be to incorporate the OWASP AppSensor Project Libraries: http://www.owasp.org/index.php/CategoryemoticonWASP_AppSensor_Project
Scott Rabonへのコメント。投稿日時:10/06/13 15:40
Need ability to lock user out of editing personal settings (useful in a corporate environment where you don't want "SpankyClown" as a screen name).
投稿日時:10/09/04 23:07
==Enable Friendly URL Mapper to set JSR-286 public params in portlets==

Multiple portlets on the same page that supports the same public param could read the same parameter set in FriendlyURL mechanism.

Both would have a route.xml like <pattern>/${myPublicParam}</pattern>. When a page is hit with "/-/valueOfPublicParam", both could get it by renderRequest.getParameter("myPublicParam").

See:
http://issues.liferay.com/browse­/LPS-4023
投稿日時:10/12/17 13:54
Very important for me:

GUI for default configuration for public & private pages. In short, give admin or owner access to a "default" set of public & private pages so that portlets, content, etc. can be added and then pushed out to all the groups in a given instance.

Changes to the group pages or their content should also be pushed out to already created users and not only to newly created users
Flávio Stutzへのコメント。投稿日時:11/08/16 6:04
A new topic for "Portal Instances" - Ability to extract a portal instance into a file (equivalent to a LAR but including users and their groups, roles etc.) and load it into another instance. Along with this the ability to delete a portal instance.

This enables moving portal instances between portals, backing up portal instances individually and possibly cloning portal instances.

See also http://www.liferay.com/community/forums/-/message_boards/message/2767593
Piotr Swiniarskiへのコメント。投稿日時:12/07/19 17:05