I basicall do not understand the privileges of a reader and a contributor. Whats the difference.
Any authenticated user(added to the list) is a reader or a contributor?
In a system engineer-manager scenario, who will be the reader and who the contributor
A reader has read only rights, a contributor usually have crud access (create, read, update and delete) but cannot administer settings.
Contribute and Read are default site roles in SharePoint
Read grants the rights to view list items\document, open list items\document, View versions of list items\document, View Pages, browser user info, view form pages, use client integration (open documents from directly from sharepoint), Create certain kinds of sites, and use remote apis.
Contribute grants all those rights plus:
Edit list items\documents, add list items]\documents, edit their own user info, create Alerts, Update personal web parts, add/delete private web parts, browse directories, and manage personal views.
Neither of these permissions map directly to an engineer-manager scenario - rather I would say it would be better to model it as producer - consumer. If the manager only needs to consume what the engineer produces, the manager should have read, and the engineer contribute. If the engineer only reads what the manager produces you can reverse the relationship.
Related
I am running Kentico 11. I have a section of the site that requires user login to read and download some hidden content.
Those users are stored in the Configuration -> Users table. I have a custom Role that these users are assigned to so they can login and view the content & download files. We have an external (CRM) system that is integrated with Kentico. This CRM automates the User account creation & Role assignment based on yearly training records. So the user accounts do not get manually created. CRM manages the creation & deactivation. This is working as intended with 1,000s of users.
Business requirements have changed and now requires two levels of access. Will require a 2nd Role be created. First tier will allow basic access to content. A new 2nd tier (additional Role) will allow access to the file downloads.
The first tier will remain managed by the 3rd party integration from CRM (account & 1st role assigned). The 2nd tier will have to be manually controlled. Someone will have to login to Kentico, Configuration -> Users. Search for the user and add the 2nd Role.
To avoid putting the burden on the programmers I need to allow some of my non-technical team (customer support, product management) to be able to manage the Users.
These non-technical do not have Kentico CMS accounts. I do not want to make them Administrator and give them "keys to everything".
My question is specific to Configuration -> Permissions -- can I give my non-technical team the Read permission to "CMS Basic User" and Manage User Roles "Contractor" (and my custom role 1st ) and expect that they will be able to login to Kentico, navigate to Users and maintain my Contractors.
This is expected to allow them to view my contractors, and add them to a new 2nd role "Contractor Download". Take bob.smith#someemail.com for example. Bob is a contractor, the CRM tool added him to the Users Table with the roles Authenticated, Everyone and Contractor. Bob has completed some training and now needs the Contractor Download role.
Is the appropriate best-practice in Kentico to give my non-technical staff the CMS Basic User role & Contractor Role so they can manage our contractors? Is there a risk to this configuration? Will they be able to manage other roles? I do not want them to be able to edit content management, ecommerce or any other configurations.
It can be hard to give permission to manage one role but not the other. Usually in terms of UI permissions, you either have permission to the entire operation or you don't.
While using Kentico's back end UI would be beneficial, and giving them an account with limited administrative roles I think would be fine, what i would do is create a custom User interface and give them access to that UI, and all that UI element would be would be a drop down of available users to assign to the role, and a button that would use Kentico's API to assign them.
You can make the entire thing using the Custom Control webpart and point to your ascx, don't need anything particularly fancy.
the API to assign the role is pretty simple:
UserRoleInfoProvider.AddUserToRole(ValidationHelper.GetInteger(ddlAvailableUsers.SelectedValue, 0), RoleInfoProvider.GetRole("ContractorDownload").RoleID);
Make the drop down a list of (UserID, UserFullName) using the following dataset:
int[] UserIDsInContractorRole = UserRoleInfoProvider.GetUserRoles()
.WhereEquals("RoleID", RoleInfoProvider.GetRole("Contractor").RoleID)
.Select(x => x.UserID).ToArray();
int[] UserIDsAlreadyAssigned = UserRoleInfoProvider.GetUserRoles()
.WhereEquals("RoleID", RoleInfoProvider.GetRole("ContractorDownload").RoleID)
.Select(x => x.UserID).ToArray();
ddlAvailableUsers.DataSource = UserInfoProvider.GetUsers().WhereIn("UserID", UserIDsInContractorRole).WhereNotIn("UserID", UserIDsAlreadyAssigned).Columns("UserID, FullName").OrderBy("FullName").Result;
ddlAvailableUsers.DataValueField = "UserID";
ddlAvailableUsers.DataTextField = "FullName";
ddlAvailableUsers.DataBind();
I have created multiple apps in SPEAK UI and placed all quick access shortcuts on the Sitecore Launchpad.
Now, how can I restrict access for some applications while creating Users, because we have Content Area in Access Viewer?
There are a couple of ways to do this. First you need to open the desktop and switch from the Master to the Core database.
If you just want to restrict access to the shortcuts on the Launchpad - you can do this by setting access rights on the shortcut items:
Create a role that should have access to the users and give that role Read access to the button item.
Another option would be to allow access to the application. If you look at the Path Analyzer you can see that some roles are denied and some granted access:
So add security rights to roles for your SPEAK apps.
Finally when you create users make sure you give them the correct roles to match what they are able to view.
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 a Sharepoint library that is too large for a central administrator to manage permissions on all items, so I want to designate a few other people who are able to allow or disallow read/write access for arbitrary items in the library to users or groups. However, I don't want to give those few people total "manage permissions" ability because I don't want them granting themselves or others full control or design permissions, etc.
Is there a way to grant "manage only read/write permission"? Or is there a better way of accomplishing what I'm trying to do?
Thanks!
This question pops up all the time, and I haven't been able to find an answer that immediately makes the asker happy.
I usually suggest that you stay away from item-level permissions, and instead create libraries pretty much mapping to groups. make a library for your Company X accountants, make a "Accountants at Company X" group, give them rights to that library. You should be able to trust them enough that they get to manage their own document library. If not, keeping the permissions on a per-library basis will make the workload much less, and the site administrator(s) can most likely handle the permissions on these libraries. If you want to make it easier for them, just create a formal workflow where a user can apply for access and an administrator grant it.
There are other ways, of course, but you're pointing at one of the major reasons you should stay away from item-level security. It's just a can of worms that you need to avoid opening if at all possible.
Maybe you can try the third party tool: SharePoint Permission Manager by SharePointBoost. You can search, analyze, manage and backup SharePoint users or group permissions on a centralized platform.
I don't think there is a specific permission that meets your needs for one site. I think your best option may be to split into sites or libraries you can allow others to manage for your central administrator.
Here's a related excerpt from the TechNet article, [Plan Permissions][1], that may help you more:
Users or groups are assigned a
permission level for a specific
securable object: site, list, library,
folder, document, or item. By default,
permissions for a list, library,
folder, document, or item are
inherited from the parent site or
parent list or library. However,
anyone assigned a permission level for
a particular securable object that
includes the Manage Permissions
permission can change the permissions
for that securable object. By default,
permissions are initially controlled
at the site level, with all lists and
libraries inheriting the site
permissions. Use list-level,
folder-level, and item-level
permissions to further control which
users can view or interact with the
site content. You can return to
inheriting permissions from a parent
list, the site as a whole, or a parent
site, at any time.
My team implemented a UI to assign/revoke permission levels to users on a certain SharePoint list. The UI supplies an "undo" feature to restore the rights the user had before they were changed through our UI.
Now there is a problem if the user had the "Limited Access" permission level: This permission level is removed when you do a change over the UI. When trying to Undo, the permission level should be added again, which leads to a
You cannot grant a user the limited access permission level.
SharePoint grants that permission level automatically when a user gets access to some entity beneath the site. It cannot be granted manually. This permission level is then inherited by all lists in the site. However, after breaking inheritance on a list, I can revoke the right manually, only, I cannot re-grant it afterwards.
So SharePoint treats that permission level quite particularly and I'm wondering how to work around that in our undo feature.
My questions:
Did I get it right that this "limited access" is granted by SharePoint on the site level only, and all the lists beneath only contain that accidentally through inheritance?
Does that permission level have any effect at all on a list, or does it only apply to the site itself?
So, would it be save to just remove it from a list and do not add it anymore when the user clicks "undo", since it has no effect anyway?
I dare to answer my own question just for reference for future readers:
According to Microsoft's article Permission levels and permissions,
The Limited Access permission level
cannot be customized or deleted.
and
(...) Windows SharePoint Services 3.0
automatically assigns this permission
level to users and SharePoint groups
when you grant them access to an
object on your site that requires that
they have access to a higher level
object on which they do not have
permissions. For example, if you grant
users access to an item in a list and
they do not have access to the list
itself, Windows SharePoint Services
3.0 automatically grants them Limited Access on the list, and also the site,
if needed.
In practice this means that:
If you can delete it, that's only because it has been inherited and has no meaning on that certain list.
If later on a user is granted some permissions to a certain list item, so that he needs the Limited Access on the list, SharePoint will take care of adding it again.
Summarized: No concerns to remove and not re-add that access level.
Removing a user with Limited access on the top level site should not actually remove their explicit access on the list or library below (with broken permissions) but MS do say in the above mentioned article:
However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
This suggests that the user's Limited access should be declared on the site permissions. I think its always best to do a test on your site first before making any assumptions.