Is it possible to set VIEW only permission to a single document library file (DLFileEntry) to the users of a different site.
Example : DocumentA exists in SiteA and I want to set view permissions to all the users of SITEB only to this document.
Thanks for reading.
-Mike
You'll need some kind of indirection: Permissions in Liferay are handled through roles (teams behave as roles as well), not by other arbitrary groups of users. If you assign all the users to a user group and make that user group member of the site in question, as well as assign them to a role that you create for this purpose.
Related
I am using version 6.1. I want to create a user who has most admin capabilities. However I do not want them to have access to creating user groups, users etc. I want them to have access to products etc. Is there a functionality in Backoffice to restrict users from adding users. Is there a way to hid this function in the navigation tree?
THanks
Use Hybris access rights, for example to give read permissions to user group mygroup for item type User (this can be executed as an Impex query):
$START_USERRIGHTS;;;;;;;;;
Type;UID;MemberOfGroups;Password;Target;read;change;create;remove;change_perm
UserGroup;mygroup;;;;;;;;
;;;;User;+;-;-;-;-;
$END_USERRIGHTS;;;;;
I need to give permissions to edit/create/destroy pages in a node to a group of users.
I've created a group and added a test user to that group.
I can't seem to give permission to the Pages application so see if i can see the node.
I also added game this role permissions at the node level too.
Ideally this editor role would be able to create new sub pages, which also means being able to upload media.
Your new user must have editor privilege level (you can edit user in Users application). If you want to provide ability to see content in Pages app you have to grant the user with Browse tree and Read permission (content module). To satisfy your scenario you need to grand user with Modify and Create permissions, too (maybe Design?).
Just FYI: The approach provided by Brenden (cloning the role) is very handy but there a is chance you grant the user with permission you don`t want to provide (inappropriate permissions for original role).
I've found the most efficient method is review the out of the box roles provided by Kentico and clone the one which fits closest to your needs. Then modify your cloned role to add/remove abilities and permissions.
If you're unsure of what each role can and cannot do, create a new test user with one of the roles assigned to them and log in as them. Do the same for all the roles you want to test until you find the one closest to what you're looking for.
I have created a 'Site User' role which is appropriate for users who will be Viewers on every available portlet. For example a user with this role should be only allowed to view documents in Documents and Media portlet but not allowed to add a new document or edit an existed.
I have defined the proper permissions in my Site role, however users with this Site role are still able to create events or add documents etc.
All these users are also assigned with the Social Office User role but as I'm seeing there is no such permission granted from this role.
I'm wondering if this is a normal behavior or the only solution is to modify portlets in a way that they won't allow users without the 'Site Admin' role to perform certain actions.
They're most likely still assigned to the "User" role (portal wide), or gets the permission from being a "Site Member". As you can't remove permissions, only add them through roles, check these roles for their bundled permissions.
They're assigned as default to Site Member role as Olaf stated. Look this file:
https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/resource-actions/documentlibrary.xml
As Site Member you have :
<site-member-defaults>
<action-key>ADD_DOCUMENT</action-key>
<action-key>ADD_FOLDER</action-key>
<action-key>ADD_SHORTCUT</action-key>
<action-key>SUBSCRIBE</action-key>
<action-key>VIEW</action-key>
</site-member-defaults>
as default action permissions.
I have a SharePoint site which contains a root site and site collection in it. Now there are some sites that inherits permissions from their parent site and some site has their own permission module. Now a user from owner group of root site browses site collection but there are few site which doesn't allow user to view the content of it.
Now what I want is general recommendation on when creating a new site in SharePoint what is best possible approach to set site permission.
In what case we can inherits permissions from parent site..?
In what case we can we us unique permission for a site..?
If a site has unique permission set then is it possible to creat a group at root level which has access to all site collection irrespective of site permission model?
I want a general recommendation based on above scenario.
Any help will be appriciable.
Thanks
Sachin
In many cases we can't inherit permission in all subsites/ lists. And if we are not inheriting it we can't create a new group which have same permission in all sites/lists. But we can overcome it with the following way.
Create some common permission group with deferent permission level. And create site with inheriting permission and remove user groups from new sites except the common group.
If a new user wants access in all sites/ list you can add this user in appropriate common group.
I would like to create a folder that users who do not have privileges to view the rest of the site can see. This user group would be granted access to the site, but I only want them to be able to view one particular page.
Is this possible to do without going to every single page and removing the new user group's access?
yeah, you should be able to create a new group and add the users to that list/subweb/whatever and just that. This is assuming that you didn't grant access to all users somewhere. If you did, then hopefully the default access is granted to a default user group (like sharepoint visitors) and you can alter that group to exclude the users you only want to access the limited part of the site.
If created correctly the new group shouldn't have access to the rest of the site.
If you are getting thrown off by the fact that the user/group is listed as having "Limited Access" on the ACLs on, say, the parent site/web. That's just a placeholder SharePoint uses to make sure people have access to at least the bare minimum set of objects (e.g. theme and other UI files and the parent web itself) to get to the list or item you actually want them to have access to.
As long as the group only has access on a single list, you should have to worry about them having access to anything else.