Liferay 7: Sharing Content - liferay

I am new to Liferay and was wondering if the following use case is possible:
Use Case:
Share a piece of content in Site A with Site B.
- No Parent Child relationship between sites
- No Global Content
- The content to be shared is in Site A.
- Site A is set up to share content at the site level.
- Want to add content to a page in Site B, not a site admin or site owner. Regular user. Page is set to be customized.
Have found ways to share some content with placing content in the global space, users having site admin role on both sites, subsites showing parent site content, but nothing that enables our use case to work.
Is this possible to achieve? If so, how?

Not OOTB! The purpose of site is exactly to group (and eventually protect) content and pages. Unless you explicitly share the content (which is what global site is for) it is only available in the site it is defined. There are some other sharing options you've already discovered like parent-child sharing or site admin role sharing but no random sharing between sites.
That said, you can always extend Liferay and do this yourself, taking into account all the security issues and management overhead in introduces. If the content is public (or the user viewing it has the right permissions), you can use IFrame or call the respective jsonws service to get the content and display it.

Related

Liferay Page Administrator

I need that each page is administered by one person or group of persons.
Do I need to create one role each for every page I have to administer(Page1 administrator, page 2 administrator) or can I just create one generic role named "Page Administrator" and have some thing like a user having Page Administrator role can manage only page1 and similarly another user having the same "Page Administrator" can only manage "page2"? This is to avoid creating as many roles as there are pages in the system.
it depends... The easiest and most maintainable way to assign permissions in Liferay is through roles per site. If you have 1 page per site, you're good to go with a site role. You can build the navigation from many different sites, an example is this POC app by yours truly.
If you create roles (or teams) per page, be aware that page management is a different beast than content management: All of the pages of one site share the same content. Thus it might be hard to solve, if you also want the page administrators to maintain the content.

Sharepoint 2010: Move button disappears in site content and structure

I have a sub-site (http://mysite/documentcenter). My user is in Site Collection Administrators, so I can see and click the move button in site content and structure of sub-site.
But the other users, who has contribute access to all documents, can't see the Move button - it completely disappeared, it's not greyed out.
How can I make the move button display for the other users?
I know this question is a bit old but, you need to have the following Permission Level enabled or Move is not available.
Manage Web Site - Grants the ability to perform all administration tasks for the Web site as well as manage content.
I would be very careful assigning this permission though as it adds a whole slew of additional access for the user(s).
Make sure Add and Customize Pages permissions is present. There could be a Deny mask coming in from User Policy from central admin, which can overwrite Site Collection admin permissions.

Why can't users in the "Visitors" group access my SharePoint 2010 publishing site. It works when i promote them to the "Members" group

When I place a test AD account in the Visitors group they are unable to view any pages on my new intranet site. The users receives the "Error access denied" sharepoint screen and indicates that the account was able to authenticate, but that some authorisation rule is permitting it from viewing the page.
When i remove then and place them in the Members or Owners groups they are able to view the pages as well as perform the expected functions like editing content and creating subsites.
Interesting, while in only the Visitors group, users can view the "All Site Content" page that is located here: /_layouts/viewlsts.aspx but not /pages/default.aspx.
Has anyone experienced this before?
Environment info:
1 Web application, 1 Site collection using the Publishing Portal template. A few custom master pages, lots of custom page layouts and user controls. All deployed via features.
Sharepoint 2010 Standard edition, 64bit running on Windows Server 2008 against SqlServer 2008 Enterprise Edition. Authentication is against AD, not any other forms auth providers etc.
One likely reason for such behavior is that it tries to access a resource on a page which might not have been published to a major version. For example, if versioning was turned on on images library and an image's version is 0.1, if that image was used on version 1.0 (published) of the page, the server would deny access to the visitor and ask for credentials.
Make sure following:
At least one major version of the page exists (page was published at least once)
All resources (images, movie files etc) used on the page are published (to major version)
You can use "Draft Check" button on Page Tab of the Page's ribbon to check the unpublished resources that are used by the page.
I had the same issue and I've finaly found out how to do this:
If you check OOB group access, you can find that Visitors group has limited number of pages where it has granted access.
Navigate to /yourweb/_catalogs/masterpage. Here you'll find many
.aspx files (including default.master).
Open this default.master`s permissions and you see it inherits from
Master Page Gallery.
Click this permissions inheritance and you can see that Master Page
Gallery permissions are not inherited from site collection
permissions.
Give here the Contribute permissions to Style Resource Readers (or
modify it as you'd like) and all users will have access to this web
with no permissions to edit etc..
I had a similar issue and the thing I noted in your Environmental comments was the custom master pages. Go to your Site Settings and ensure that your custom master pages have been published. If you need to publish them also check the corresponding html pages after they have been published as they may need to be republished also.
This worked for me.

Changing the default page based on security group in SharePoint

We have a SharePoint site collection. In this site collection we have a home site and 6 other sites. Each of these sites belongs to a department in our company. Right now if you are a member of department A security group you would see homepage and your department site/tab when you navigate to the site. What they want me to do is to redirect the users directly to the department site/tab whenever they navigate to the site.
Is there any way to do this without coding or with coding?
With coding, you could write a very simple web control and include that on the home page. It would test which group a user belongs to and then redirect accordingly.
There are various ways to check if a user belongs to a group. One method is to get a reference to each SPGroup object and use SPGroup.ContainsCurrentUser.
You might also like to consider creating a custom list that maps SPGroup name against department URL, so you can manage behaviour of the control through the SharePoint UI.

What are the best practices for permissions on a publishing site within MOSS 2007 Standard?

Here's the scenareio:
I have a single site collection, with the publishing infrastucture feature activated. Seveal levels below this I have a publishing site with the publishing features turned on. I also have unique permissions for this site.
The problem is that no one except site collection administrators can "Create Page". I have given the individuals everything including full control, and they still can not create pages. They can edit pages, but not create.
Am I doing something wrong? What is the proper way to set up the taxonomy of a site? I am trying to create a hierarcy to match my organization and mostly am using unique permissions on each site/subsite. This is working ok, until i needed a publishing site, but I don't want him to be a site collection admin. I would appreciate any help or ideas with how to make the publishing site work as I have it, or guide me on the proper way to lay out the site.
The fact that you are using Publishing features shouldn't have an effect on permissions. Publishing (for the most part) really has more of an effect on how edits are handled - i.e. immediately deployed or checked in and published at a later point. That's oversimplifying it - but back to your question.
Most likely - what is happening is that you have not given the user permission to the library where the template is that they need access to in order to create the page. I'm 99% sure that is what is happening here. Makes sense - they have the rights to the site - and permissions to edit the pages that exist - but creating a page requires them to access a new file - in a different library. If they don't have permissions to that template library - you get the access denied error.
When your user tries to create a page, they get an access denied error page correct? Copy the URL of that page, and examine it closely. It should reveal the location of the template folder they are trying to access but don't have permissions for. Read-only access to that template library should get your user the access they need.
One other recommendation - check out the access checker web part in Codeplex. http://accesschecker.codeplex.com/. This web part is loaded as a solution and allows you to display a hierarchical list of the sites that a specific user has permissions to. VERY helpful in confirming that you have given the permissions you thought you had.
Finally - in terms of permissions best practices - I think you are doing fine. You've gotten a little frustrated because you took a different path on a site (i.e. publishing) and it's behaving differently. But nothing is wrong. I've been there:) You really have two options w/ SP permissions - SP based groups (visitors, members, owners etc) or pulling in AD groups. Either way, you'll be making the same decision regarding unique or inherited permissions. You either use the same permissions as the parent site - or use unique permissions. HTH

Resources