Hi,

I have a situation and I do not know how to make an optimal solution for it:

- I would like to have 3 different portal with 3 different administrator
- they need to work with different databases
- I want the administrators not to be able to see all the portlets and themes, only those which they have grant to. I mean, some portlet can be seen only in the suitable instance, in the list of portlets (in Control Panel > Plugins Configuration and in Add Application list)

Can I solve this problem by installing only one portal with 3 instances, or should I install 3 portals.
I would rather having only one portal with 3 instances (less hardware req.) but my last criteria is not simple at all because all instance uses the same installed portlets list by default - so my main problem is that I need a companyId filter in the mentioned lists.

Please help me, I do not know how to start.

Thanks,
Gabor

Your only solution is really 3 separate installs. Unfortunately, most of the configuration happens at the installation level and it will apply to multiple "instances" which are really virtual hosts on the portal.

Things like who the registration emails come from.... Who the subscription updates come from, etc. all that is set for the entire server.

I thought I could solve my problems by configuring DB sharding and user roles.
I plan that I install another portal and export its datas only if it is very neccessary (when I have to change base configuration).

Thank you for answering.

Gabor

Until a lot of the configuration stuff becomes more isolated from one customer to another, using separate instances is really your best bet. Prime example... My liferay instance....

I host my own web site for my consulting company, a curly hair web site, a car web site, a dating site, and a few others. However, because I have to configure the emails from the message boards, calendar, blog, etc. in the portal-ext.properties, they call come from the same source no matter which site you are a user of. And what's ok for the curly-haired girls doesn't work for the car guys which also doesn't work for the dating site. Sharding won't affect that at all.

can we see the various sites. am interested in seeing different layouts.

Just to clarify,

sharding allows the records in a database table to be split amongst multiple database instances. From Liferay's point of view there is still only one logical database.

However, with multiple shards you gain some benefits. A performance one certainly, but also you can do seperate back up and restore by shard which can be more flexible.

Each portal instance has its own settings values, so it can have its own virtual host, mail domain and rules. The admin of one portal instance does not get access to other portal instances. Only the omni max admin can do that.

Plugin settings are also isolated to portal instances, but plugin installation is across an entire portal.

Just to clarify, liferay's sharding does not completely separate database data across portal instances. There are some portal information that is shared by all the liferay instances.

Yes, for example the shard table. Although it appears in each database instance only the one in the default shard is used.

The only thing i can say about this, is the last time i tested this ( Liferay 6.1 RC2 and GA1 ) liferay became pretty unstable en there where even portlets that didn't work anymore

I have been doing further work with shards. I have discovered some company associated data that is still kept on the default database only, instead of in the instance shard.

company, portalpreferences and virtualhost.

I also notice that the kaleo tables do this but it seems to be a mistake.

Finally there are two tables that seem to split company data between the shard and default: expandotable and role_. I have not worked out the rule used to decide which record goes where.