I am running into a problem where I am using the WSAPI to add a project to a person's TeamMemberships collection. When I add a project to this collection I get a 'you lack permissions to view Project XXXXXXXXXX' but I am NOT even trying to view that project.
I also get that same error when i put the _ref of that project in the URL bar, so i definitely lack permissions to view this project.
My question is: do i need viewer access to all items in a collection to add an item to that collection?
In general, editor access to all items in the collection is needed to update a collection. Viewer access is not enough.
In a specific case of a collection update when TeamMemberships collection is modified, editor access is not enough because this action requires administrative privileges, minimally Project Admin rights.
Since a Workspace Admin has access to all projects in the workspace, we don't need to consider that scenario.
Here are the details. Let's start with a more general collection update, e.g. defects collection on defect suite.
Let's say there are two sibling projects Child1 and Child2.
Some user A has editor rights to Child1, and no access to Child2.
Assuming that there is:
a defect suite /defectsuite/444 with an empty defects collection in Child1,
two defects /defect/111 and /defect/222 in Child1,
a defect /defect/333 in Child2
User A successfully adds /defect/111 to the defect suite using this curl command:
curl --header "zsessionid:_abc123" -H "Content-Type: application/json" -d"{\"CollectionItems\":[{\"_ref\":\"/defect/1111\"}]}" https://rally1.rallydev.com/slm/webservice/v2.0/defectsuite/444/defects/add
Next, some other user B who has editor rights to both projects Child1 and Child2 adds /defect/333 to /defectsuite/444. Now the defects collection on this defect suite consists of two defects, one of which exists outside of User A's access.
Next, User A tries to add /defect/222 (which exists in Child1 project to which Editor A has full access) using a curl command similar to the one above, and gets an error:
"Could not add artifact to collection", "Could not read: Not authorized to read object Defect 333"
If at this point User A is given Viewer access to Child2 project and tries again the error will be different:
"Could not add artifact to collection", "Could not set value for Defects: Not authorized to update:DefectSuite 444"
To update the collection that contains defects from two projects User A needs to be an editor in both. Upgrading this user's rights to Editor level in Child2 project allows this action to complete successfully.
Now let's consider two scenarios in a TeamMemberships update.
Editor: Attempt by a user with editor rights to all projects in a workspace to update TeamMemberships collection for another user, /user/777 results in error:
"Could not add artifact to collection", "Could not set value for Team Memberships: Not authorized to update:User 777"
Project Admin: This is a minimal level of permissions that may work. Here is a scenario:
User A has project admin rights to /project/111 and /project/222 and their child projects, and no access to /project/333 and its child projects in the same workspace.
Note that at this point the /user/777 whose teammemberships User A tries to update has no membership in any projects in this workspace. This command successfully updates TeamMembership for /user/777
curl --header "zsessionid:_abc123" -H "Content-Type: application/json" -d"{\"CollectionItems\":[{\"_ref\":\"/project/111\"}]}" https://rally1.rallydev.com/slm/webservice/v2.0/user/777/teammemberships/add
The returned JSON includes:
"TeamMembers": {"_rallyAPIMajor": "2", "_rallyAPIMinor": "0", "_ref": "https://rally1.rallydev.com/slm/webservice/v2.0/Project/111/TeamMembers"
Next some other User B updates the teammembership collection of /user/777 with /project/333 to which User A has no access.
Next, User A tries to update update teammembership collection of /user/777 with /project/222 where User A is a project editor.
This results in error:
"Could not add artifact to collection", "Could not read: Not authorized to read object Project 333"
At this point if User A is given Viewer or even Editor rights to /project/333 the same curl command will fail with this error:
"Could not add artifact to collection", "Could not set value for Team Memberships: Not authorized to update:User 777"
Project editor rights for /project/111, /project/222 and /project/333 will be needed in this case.
Related
I want to restrict users from seeing the content of a list when they navigate to "site/Lists//AllItems.aspx". All I want them to see is the message "There are no items to show in this view of the "" list." I've already checked permissions but everything is set properly. We are not using audience targeting.
Configure the list view to use a filter that returns no result. For example, if the smallest ID in the list is 9, set the filter to show ID equals 8
Such hacks will not prevent savvy users from viewing the data though. Access and permissions should be configured properly. Consider removing user access to that list entirely, so only administrators can see it.
First break permission on your list or library by "Stop Inheriting Permissions"
Go to the list, library, or survey and open it.
Go to the Permissions page using the steps in the previous section.
To break permissions inheritance from the parent, select Stop Inheriting Permissions.
Assign unique permissions in SharePoint 2019, 2016, or 2013 server
You must break inheritance from the parent site before you can grant unique permissions. Once you've broken inheritance using the steps in the section above, follow these steps to grant unique permissions:
Go to the list, library, or survey and open it.
Go to the Permissions page using the steps in the previous section.
Select Grant Permissions on the Permissions tab.
Delete Unique Permissions button
Note: If the list or library is inheriting from the parent, you won't see Grant Permissions.
In the Share... dialog box, make sure Invite people is selected, and then type the names of the people or group you want to grant access to in the Enter names or email addresses... box.
Share dialog box
Add a personal message if you like.
Check or uncheck Share everything in this folder, even items with unique permissions. This will grant or restrict access to items you already set unique permissions for. (This option is only available for folders.)
The permission level granted is set to Edit by default, which means the people you invite can make some changes to the list, library, or survey. If you want to grant a different permission level like Read only, click Show options and change the selection in the Select a permission level box.
An email message will be sent to everyone in the Invite people box. If you don't want this to happen, click Show options, and uncheck Send an email invitation.
When you're done, click Share.
Hope this can solve your issue:
https://support.microsoft.com/en-us/office/customize-permissions-for-a-sharepoint-list-or-library-02d770f3-59eb-4910-a608-5f84cc297782
After adding other users from my organization as Project Editor and Viewer the projects aren't showing up in their Google Cloud Console project list, nor are they visible in gcloud projects list.
However if I give them a link directly to some resource inside the project they can navigate to it just fine,
and they can also use commands like gcloud container clusters list with the --project= set to the new projects and see the resources inside the project.
The documentation for the gcloud projects list (https://cloud.google.com/resource-manager/docs/creating-managing-projects#listing_projects) specifies it should list all projects on which you have resourcemanager.projects.list (which Project Viewer and Editor both grant) or any children under a parent on which you have resourcemanager.projects.list.
So maybe if I grant resourcemanager.projects.list on the organization level it would fix it, but I don't really want to grant the users such a broad access...
As mentioned by John Hanley :
In order for a user to list projects in an organization, they need resourcemanager.projects.list at the organization or folder level.If a user has access to a project, allowing them to list projects should not be an issue unless revealing the names of projects is not desired. In that case, just provide everyone with the Project ID and they can manually use that to access resources.
Note: The level (project, folder, organization) determines what users can access. You could create folders, move projects under folders and allow users to only list projects in their folders
For more information you can refer to the Serverfault Answer related to a similar issue and Documentation where creation and management of the Folders has been well explained.
Here is how to replicate:
As an admin create a "newProject990055" under an existing organization, select it and navigate to the IAM menu.
Add a user with just the role "Logs Viewer" for "newProject990055".
Login with such a user and try to select project "newProject990055". Expected: User won't see "newProject990055"
because the user has no access to list all projects, and
"newProject990055" is new, and the user has never visited it before.
With such a user hit https://console.cloud.google.com/logs/query?project=newProject990055.
Expected: User will see the logs for the "newProject990055" project
and user will be notice that such a project is selected.
Logoff and login back with such a user, click on the dropdown for projects. Expected: User should be able to see project
"newProject990055" because even though the user has no access to list
all projects, and "newProject990055" is new, the user has already
visited it before.
I have Created the SharePoint custom List with 3 views(Ex.test1,test2,test3).
I want to assign 3 views to 3 user,one should not have permission to view other's view.
Any help would be appreciated.
As far as I know, this is simply not possible, i.e. assigning views to a certain user. You can have 'Public' views (visible to everyone with access to the list as the name implies) and 'Personal' views (visible only to the user who created them, the user must have the relevant permission enabled for this). Personal views cannot be shared.
Also, if it is critical that data is only visible to certain users and not others, a user can look at items not in their View by simply changing the ID in the Item View in the URL so View filtering is not a good way to go about this.
Could you please elaborate on what exactly are you trying to achieve, i.e what is the difference between the views etc.?
UPDATED:
Here you can get another good solution.
https://sharepoint.stackexchange.com/questions/253723/restrict-list-view-to-role-sp-o365
It is really good solution because you need only admin rights and no code.
You need to create folders, break role inheritance and add permissions on folders.
My OLD answer:
From my experience It is depend on what is your expectations from solution, your limits, what you want to get and what things you can sacrifice and in some cases what SharePoint edition you are using.
Note: SharePoint does not have out-of-box fully customizable list item permissions.
I can say about some expectations, some details, some solutions and workarounds and how to implement this.
You can try to get something that applied to you:
.1. You want to disallow users to see other users views. But:
users with specific permissions can create their own views and therefore they can create views with all fields and all list items data from other disallowed views,
users can get data about all fields in list items and all list items from REST API, JSOM API and other SharePoint out-of-box web services,
users can open any list item, change URL item ID to another and see any data from other list item.
To achieve this you can:
.1.1. Open list under each user and create its own Personal View.
Personal Views displayed only for individual users.
.1.2. Create Public View and set its Target Audience.
Open view page -> in right corner click Gear icon -> Edit Page -> on the page click arrow icon on list view web part -> Edit Web Part -> Section "Advanced" -> Field "Target Audiences".
If you does not have this option then enable target audiences.
List Settings -> Audience targeting settings -> Enable audience targeting.
In audiences you can specify SharePoint users or groups who has permissions to see this web part.
Here you can see different uses of audiences and how to enable it on list or library: https://support.office.com/en-us/article/target-content-to-specific-audiences-33d84cb6-14ed-4e53-a426-74c38ea32293
.1.3. Create Public View, open its page, edit page, delete List View Web Part, add Content Query Web Part and set its Target Audience.
Here you can see info about Target Audiences:
https://support.office.com/en-us/article/target-content-to-specific-audiences-33d84cb6-14ed-4e53-a426-74c38ea32293
But I didn't perform this by myself.
.1.4. Add javacript to list view page.
This javascript will check user permissions and hide view or redirect user to some other location or will make other actions.
.2. Users cannot see other users created list items from any source (any list views, any API and web services).
.2.1.
Note: this is limited. User can only read, edit list items which created by him. You cannot apply this on other users created list items.
To achieve this you can:
List Settings -> Section "Advanced settings" -> Block "Item-level Permissions" -> "Read items that were created by the user" and "Create items and edit items that were created by the user" options.
.2.2. Create different lists for different users with different permissions.
.2.3.
Note: this is limited by SharePoint unique permissions limits.
You can create SharePoint workflow that run on list item creation. This workflow will break list item role inheritance and set new permissions for this items by some conditions.
This is may be good but here some limits exists. SharePoint limit list to have more than some limit number of list item unique permissions.
.2.4. I don't know if SharePoint has some limits to this but you can try and I don't know if you can perform this from public API but you can try to investigate.
You can create SharePoint workflow that run on list item creation. This workflow will set Target Audiences on list item.
Here you can see info about Target Audiences:
https://support.office.com/en-us/article/target-content-to-specific-audiences-33d84cb6-14ed-4e53-a426-74c38ea32293
.2.5. If you use SharePoint On-premise edition then you can add:
.2.5.1. List event receiver that run on list item Create event and perform following actions:
- break list item role inheritance and set new permissions for this items by some conditions
OR
- set Target Audiences on list item
.2.5.2. Create Timer job, deploy, schedule it in SharePoint Central Administration.
This timer job will be check newly created list items periodically and:
- break list item role inheritance and set new permissions for this items by some conditions
OR
- set Target Audiences on list item
.2.6. You can create Console Application (c# language) that connect to SharePoint, check newly created list items periodically and:
- break list item role inheritance and set new permissions for this items by some conditions
OR
- set Target Audiences on list item.
This console app can be scheduled on any server in your company through Windows Task Scheduler.
.2.7. You can write Powershell script that connect to SharePoint, check newly created list items periodically and:
- break list item role inheritance and set new permissions for this items by some conditions
OR
- set Target Audiences on list item.
This Powershell script can be scheduled on any server in your company through Windows Task Scheduler.
.2.8. You can create Windows Service (c# language) that connect to SharePoint, check newly created list items periodically and:
- break list item role inheritance and set new permissions for this items by some conditions
OR
- set Target Audiences on list item.
This windows service can be installed on any server in your company.
.2.9. May be you can create some other periodically running code (like Workflow, Console App, PowerShell script, Windows Service) in any server.
This code will:
- break list item role inheritance and set new permissions for this items by some conditions
OR
- set Target Audiences on list item.
I think code wrapper not limited to any implementation.
I think this ways is applicable to many cases.
If you want more customizable control, or you have some limits in implementation, then you can create many workarounds by many ways. Workaround can close many permissions holes but may be not all holes:
.1. You don't want user can create views from list view page UI.
You can add javascript to hide ribbon, buttons or some other UI elements to disallow user to create its own view or to switch to another user view.
If user is smart he can avoid this by using REST API, JSOM or web services to get neccessary list item data.
.2. You don't want user can see any list item data changing URL list item ID to another.
.2.1. You can add some javascript on default form pages.
On New Item form page, on Display Item form page and on Edit Item form page.
This javascript will be check user permissions and hide data or redirect user back to list view page or somewhere.
.2.2. You can create HttpModule that intercept web requests and check user permissions and redirect him to another page if he don't have permissions.
HttpModule must be added to IIS and SharePoint web config.
.3. You can try to disallow REST API, JSOM using but I didn't do that.
I think you can add HttpModule to IIS that will intercept web requests and check user permissions and return bad request HTTP status codes and error messages.
But I didn't yet try this by myself.
Here you must know all API endpoints to close access to them.
May be here exists many other different workarounds but I don't remember about them now.
Try something from what I said. May be it help you.
I'm using Sitecore 7.2 and trying to allow a user to set things like datasources and some custom parameters on sublayouts in page editor mode. The user is a member of sitecore\Designer and sitecore\Author, but when that user tries to edit the component properties, the fields appear grayed out/disabled.
I am able to enable these options by setting a user as an admin, but don't want to grant quite that much power to this particular user.
Here is how tried it and it works on Sitecore 7.2
Create a new user called cbarnes (and in your case if there are other content editors)
Create a new Role - call it say SP Content Editor Authoring
Make that role a member of sitecore\Author and sitecore\Designer. This way it inherits everything from those two roles.
Make the user cbarnes one of the members of that role.
Lastly go to the security editor and give Write permission on the item after selecting the SP Content Editor Authoring Role under Roles and Users section.
Login as cbarnes user and check if it work!
Let us know if this works for you. Happy Sitecoring!
I actually ran into this same issue today on a 7.2 project. While my user had both the sitecore\Designer and sitecore\Author roles as a part of a client-specific author role I created, they were not able to edit rendering parameters.
By default, users in these roles have read-only access the Sitecore\Templates folder. Within this folder I had an additional folder named "Rendering Parameters" where I stored all my rendering parameters templates. I added Write access to the client-specific role for my "Rendering Parameters" template folder and users in that role can now edit and save rendering parameters without elevated permissions.
Use "Access Viewer" tool from Sitecore start menu to define why your user does not have required rights.
By default both roles sitecore\Designer and sitecore\Author have field read and field write access to Layout template section fields. But, it seems that roles have only read access to item that you are trying to edit. You can add write access to that item.
For more details look at Security Administrator´s Cookbook
I'm building a lightweight web interface to SSRS where web app users are mapped to web app roles, which in turn are mapped to SSRS users.
The reason for this convoluted scheme is not up for debate: In short, AD groups can't be used, the site uses Forms auth and there are a fixed number of roles.
Web Role | SSRS User
Admin | AdminUser
Supervisor | SuperUser
User | BasicUser
Guest | GuestUser
The goal is to enumerate all reports a user has permission to view, and allow the user to view the report with the ReportViewer control.
More importantly, it's to simplify the UX for users, both admins and the rest: preventing admins from having to use the Report Manager website (ie, selecting checkboxes rather than hand-typing which web-role-users have access to which reports), and providing a simple UI from which users can see and execute all their reports.
Everything works OK when the user is the AdminUser.
However, I'm having difficulty calling the web service when the user isn't included in a Policy on the Home/Root folder with at least the Browser SSRS role. (The permissions granted to user 'computer\username' are insufficient for performing this operation.)
This is problematic for a couple reasons:
If every user must be a Browser to connect to the web service and enumerate reports they have access to view/execute, then all users will have access to all new reports/folders by default. (Children automatically inherit new permissions)
If a report exists in a nested folder that does not inherit permissions and the user is not a browser of, but the user is a Browser on the nested report, ListChildren() will not return that report.
It seems this leaves me with 2 less than ideal options:
Don't call the web service with the different users. Instead, enumerate reports with ListChildren() using only the admin user. Then, for each report, call GetPolicies(), and from that collection of policies, determine what reports the user is able to view.
Make the call with different users. Live with the pitfalls of newly-published reports being accessible to everyone by default, until permissions are changed. Also live with the pitfalls of nested reports not showing unless the user has access to that path. If an admin wants a nested report within a folder with explicit permissions to be available to a user who can't see that folder, the policies on all ancestor folders and their children must be modified.
#1 is obviously very unwieldy and inefficient. But #2 has significant drawbacks and becomes just as onerous & inefficient when setting permissions in certain situations.
Is there a better way? Have I missed something obvious?
[edit]
A 3rd option is to query the ReportServer database directly using a query like this. This has the benefit of returning everything the user has access to, regardless of whether or not it exists in a subfolder the user cannot access (aka, cannot use the web service's ListChildren method to retrieve). However, if using AD groups, I would have to know which groups the user is a member of, whereas the web service would do this for me. This option feels like a bit of a hack to me, but it could work.
As it turns out, we ran an end-route around this issue by dropping the requirement to restrict report access by web role, and made the path we query in the web service a web.config setting that can change, thus allowing report authors to 'hide' reports in a parent folder if the need arises in the future.
The best solution would have been to query the ReportServer database directly.
However, the client changed their mind & didn't want to restrict reports based on web user role in the end, so problem solved!