shared document library between communities

[Joerg Mauz, modificado hace 15 años.]

Well at least i am new to liferay but after playing around i thought it might be solution that fit my company's needs but today i run into an issue that might destroy all my ideas.

My main intention to use liferay is to create a portal that can be used by employees as well as by customers and suppliers. Everything shall be focussed on sharing information.
I started by creating 3 different communities:

* employees
* suppliers
* customers

I created 3 differnt users employee_user, supplier_user and customer_user and made sure each of these users has only access to their community and the corresponding private pages that I created at each community level. So far everything works fine.

Now I created a private page for the employee community containing a document library portlet. I setup 4 folder named

* internal
* public
* suppliers_only
* customers_only

The idea behind these folders is quite simple. All content below the "internal" folder shall only be accessable to employees (which is standard I think due to the document library portlet is hosted at employee community level). But all other folder shall be accessable in this way:

public => read-only access by customers and suppliers
suppliers_only => read-only access by suppliers
customers_only => read only access by customers

I gave "VIEW" permissions to the corresponding community roles (role_community_customer and role_community_supplier) at each corresponding folder. At customer and supplier communities I added a document library display portlet. But nothing showed up there.

I tried playing around with lots of other permissions but still no luck.

So is there a way to achieve this kind of behavior ? For my employees I only want to have one entry point of managing document library
and of course other things that might be used in the future (such as wiki).
I also played around with organizations instead of communities but again: No luck.

Would be great to get some ideas, probably it might be a good starting point for a tutorial about inter-granting permissions. Perhaps there might also be a document around how to setup a liferay portal in the way I want to do, because this might be a standard usecase for companies that are willing to share information but at least they do not want to make the use too difficult to use and administrate for employees and partners.

Many thanks in advance for any hits, links to corresponding documents (that i haven't found yet)


Joerg

[Victor Zorin, modificado hace 15 años.]

One way of doing it, rather than creating folders and allocating permissions to folders by communities, (which I am not sure whether it is going to work now), you may work on the level of communities, create the same setup as you do now on folder level but switch to community level.

I.e.:
Step 1. create one community per group, eg. employee, supplier, customer. In each community create document folder that will be specific and restricted to this community only.

Step 2. create shared community(ies), eg. if you have got documents that are to be shared between employee & supplier,, create ES community and make document folder for this community.

Step 3. Allocate users to those communities that they will need to have access to, eg. supplier user will be allocated to Supplier community and ES community.

We use this approach for separation and allocation of responsibilities, some users may be granted access event to 8+ communities, if they have to perform business functions that are pertinent to those communities.

An example:
* records department employee will be allocated to Company Community and Records Community
* records department head will be allocated to Company Community, Records Community, Executive Community, DashBoard community

I found that this way is helpful not only because of restricting access to documents but also to other information displayed on community pages, for example Executive Team blog.

[Joerg Mauz, modificado hace 15 años.]

many thanks for your reply, but when I understood your statement

Victor Zorin:

One way of doing it, rather than creating folders and allocating permissions to folders by communities, (which I am not sure whether it is going to work now), you may work on the level of communities, create the same setup as you do now on folder level but switch to community level.

I can extract 2 information:

1. probably somewhen liferay will we able to allocate these kinds of permissions (based on your
statement "which I am not sure whether it is going to work now").
So do you know if this will happen, probably even when this will happen ?

2. For each combinition of information sharing (regardless of its content e.g. documents, blogs, forums) I have to create a
community ? So this brings me exactly into the trouble I was/am worried about, because there is no single point of management of
documents (or whatever else) for my employees. They are not used to use this kind of navigation, because now they have to
"jump around" and manage/access all these data


After some hours of sleep I got a new idea:

I created these communities with corresponding permissions:

1) employees_aggregator
[indent]Read-Write: Community_Role_Employees[/indent]

2) suppliers_aggregator
[indent]Read-Write: Community_Role_Employees
Read-Only: Community_Role_Suppliers[/indent]

3) suppliers_content_rw
[indent]Read-Write: Community_Role_Employees
Read-Write: Community_Role_Suppliers[/indent]

4) suppliers_content_ro
[indent]Read-Write: Community_Role_Employees
Read-Only: Community_Role_Suppliers[/indent]

5) customers_aggregator
[indent]Read-Write: Community_Role_Employees
Read-Only: Community_Role_Customers[/indent]

6) customers_content_rw
[indent]Read-Write: Community_Role_Employees
Read-Write: Community_Role_Customers[/indent]

7) customers_content_ro
[indent]Read-Write: Community_Role_Employees
Read-Only: Community_Role_Customers[/indent]

8) public_content_rw
[indent]Read-Write: Community_Role_Employees
Read-Write: Community_Role_Customers
Read-Write: Community_Role_Suppliers[/indent]

9) public_content_ro
[indent]Read-Write: Community_Role_Employees
Read-Only: Community_Role_Customers
Read-Only: Community_Role_Suppliers[/indent]


All communities named "*_content_*" serve as content-provider and all communities named "*_aggregator" serve as aggregation point and therefor as one stop aggregated view.
To achieve this aggregation I am using Iframe-portlets or pages with type=embedded which are referring to a "content community portlet URL". When using an Iframe-portlet I just disabled the borders which will assume that this is a "local portlet".


In general this might be a useful idea/workaround but this also makes life as administrator / content-deployer much complexer. Even managing all those different kinds of roles might be bit weird.


I think thats very close to what you suggested, or is there still an easier way ?

Again many thanks in advance

Joerg

[Victor Zorin, modificado hace 15 años.]

1. On Data sharing between communities

"which I am not sure whether it is going to work now").
So do you know if this will happen, probably even when this will happen ?

From my experience I know that I can not share document libraries between communities, as well as calendards, etc
May be it is possible, but I do not believe so and therefore did not try to investigate any further.

As a result of this 'knowledge', we have adjusted our requirements and modified access to the data and functionality.
And now I believe that working on community-based restrictions is a much better concept because it is not just the document library but the rest of data and functions as well, I mean everything you enter under the community name.

2. On 'Community' definition
Semantics is important. 'Community' is a liferay word for portal administrators only.
However, your local understanding of word 'Community' and how do you represent(sell) it to your users is very important. We never tell the end-user that this is a 'community', we call it the by the name of whatever function it does carry. It may be:
- department
- work group
- work place
- traning documentation
- product specificaions library
- HR - related documentaion
- My Payslips
- My Invoices,
etc

But if I tried to explain community concept to an end-user, this would be very confusing, and not really connected to their mindset. So, try to transalte it properly.



To avoid further confusion for the end-user, we construct portal pages in such way that end-user never notices when switching between different 'communities'. All users can see on a screen is a set of buttons or links, so they can click on them to proceed from one area of interest to another.

I have attached a couple of images that users can see on their screen. It is up to your graphics deigner how to provide such links to different communities for each user on each page.

I am not making comments on your items (1)-(9). Try to re-think your understanding of a community. You may find that it may model and represent your physical reality much closer than an enforcement of restrictions on your document store(s).

[Joerg Mauz, modificado hace 15 años.]

You made up my day and opened my eyes ! ;-)

After having a look at your screenshots and reading your post again and again I think I understood how to handle communities in my setup. I think the most important mistake I did was to think in usescases (such as documents, wikis and so on) but after I realized that I tried to put the cart before the horse everything seems to be quite more logically.

But still one issue remains which I think could only be solved by adding inter-community permissions to some portlets.
As an example I want to mention again my document library thing:
Lets say my Marketing department is working at a new company brochure. Somewhen the work on this document is finished and it should be only accessable to all our employees. This is no problem because our Marketing department stored that document at the employee community document library. Now we want to officially launch that document, so Marketing staff have to manually add this new brochure to the public community document library rather than grant only view permission to the public community.
The same goes for other types of information such as wiki entries. Some of the entries may contain internal technology secrets other might contain more public information. So all employees who enter data to our wiki have to enter these data twice (or even more).
E.g. an wiki article on how a rechargable battery works in general has to be created at the public wiki and the private wiki whereby the specifications on our rechargable battery technology has to reside in the employee community. Of course the wiki author might only write the "general" article at public wiki and use a link to from the employee wiki to this public article but this makes life not easier for those writers..

In general I think I've got a better understanding of communities after your post and I try to do the neccesary setup these days and probably I find a solution for those "wiki-alike issues".

Again many thanks

Joerg

[Victor Zorin, modificado hace 15 años.]

Glad to hear, and by the way, in internal software code and database 'community' entity is called 'group', which is more appropriate.

In terms of something sharing between communities, there are probably things which can be extended within liferay. I am trying to stick to whatever is available right now, it gets the job done much faster.

[Petros Giakouvakis, modificado hace 14 años.]

Joerg Mauz:

You made up my day and opened my eyes ! ;-)

still one issue remains which I think could only be solved by adding inter-community permissions to some portlets.
As an example I want to mention again my document library thing:
Lets say my Marketing department is working at a new company brochure. Somewhen the work on this document is finished and it should be only accessable to all our employees. This is no problem because our Marketing department stored that document at the employee community document library. Now we want to officially launch that document, so Marketing staff have to manually add this new brochure to the public community document library rather than grant only view permission to the public community.
The same goes for other types of information such as wiki entries. Some of the entries may contain internal technology secrets other might contain more public information. So all employees who enter data to our wiki have to enter these data twice (or even more).
Joerg

An option that you may want to look into is the fact that roles can be made dynamic and the membership can depend on the community where the role is assigned. E.g. think of a role called "community-readers". In the community "marketing" this role might consist of all the members of the HR community and the community sales. In the HR this could eg be limited to the memberss of the community sales. All the while you have only added ONE role.

Permissions can be granted on roles from the control panel to all portlet resources. This would allow to define ONE security model.

community members: VIEW
community coordinators: VIEW, UPDATE, PERMISSION

And when some content needs specific security you change the permissions for that content only.

[Peter Hovens, modificado hace 15 años.]

Hi there,

Probably stupid question but i guess i'm overlooking something very easy here completely..:
Where's this my_places portlet shown so it can be added to the page, instead of only visible through template in the dock?

An answer, maybe with example of necessary code would be highly appreciated. This is an excellent thread btw!!
Thanx in advance!
Regards,
Peter

[Victor Zorin, modificado hace 15 años.]

Where's this my_places portlet shown so it can be added to the page

No you did not overlook, this is a custom made portlet. The following thread will show how to build one yourself.
It is struts-based, but I hope it makes the logic clear and you can make one using tools you have at hand. The other way is to create a journal article with hard links, not flexible but good enough for prototyping.