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.