We just created a rather complex power app which will be used by numerous users (in the company). Although there will be a small team who will handle over viewing the inputs from these users.
The goal is to restrict the users to go into the sharepoint site and delete or edit any records which them or others created. We cannot use any other datasource only sp lists.
I tried creating permissions for specific groups but they don't seem to be working properly.
thank you for your help in advance
Take a look at item level permission on SharePoint, I believe this is what you need
In addition Take a look here as well.
Follow below process:
Create two groups in SharePoint site - Admins and Normal users
On item creation in SharePoint list, run a Power automate flow which will grant Full control access to Admins and only Read permissions to normal users (or just the user who created list item - as per your requirements).
Follow below article for setting permissions for individual list items using power automate: Set Item Level Permission in SharePoint List using Power Automate
Related
I administer our Power BI offering. A user came to me with this problem:
While viewing a list in SharePoint:
Microsoft Lists
Integrate
Power BI
Visualize the list
After clicking on "Visualize the list" he gets the message,
Something went wrong. You don't have permission to view the data in this list. Please reach out to the owners of the list to get access.
Given that message, can I safely assume this is not really a problem for me as the Power BI administrator?
He is the owner of the list. He has "Full Control" permission. What else would he need?
One piece of information that may be important: We're using Microsoft's government cloud for Power BI (app.powerbigov.us) and maybe other apps. For example, we're using sharepoint.com, but I'm told it's GCC. But we may be using some features from the commercial cloud.
Update #1: Random permissions
After nothing changing, the user can now generate the Power BI report. When he clicks "publish" it reports success, but the report is nowhere to be found.
Users need to have at least Read permission on SharePoint lists that they want to access wherever they access them, via PowerBi or SharePoint UI or other.
If the user has been the owner of the list, he should be able to access the content. Please double-check his permissions on the list and also check if he could access the content successfully via SharePoint UI.
I'm currently working on migrating a big company's data from DropBox to SharePoint and i can't quite decide on how to structure the whole SharePoint environment.
So as you may know DropBox has an admin section where you add your members, groups and content to share and it is pretty straightforward on how to implement simple things and by that, i mean that you get your members on some groups and then you share specific folders (from your content) to that group directly.
As of SharePoint now, i found out that it has more or less the same functionality but it really gets pretty inconvenient on how to implement this. I created a new site, then i created my groups and added some users to them, then i created as many document libraries as my shared folders were on DropBox, i stopped inheritance from the site and added groups directly to the document libraries. All that, took me quite a while, more than 8 hours, for 30 document libraries and 20 groups mostly due to the back and forth i had to go through settings, permissions, libraries etc.
Would it be, let's say, more practical or rather make more sense to create a new site for every shared folder i have on DropBox and add members directly from the site's homepage?
What would you do for such a case?
Thanks in advance
PS. The migration tool that SharePoint admin center provides it comes pretty handy and it works good, but transfers data quite slowly.
TLDR: Use sites, not libraries, for different user groups.
SharePoint makes the following things easy:
Sharing a whole site (by inviting people as members (edit) or visiors (read))
Sharing a single file (with a person that you don't want to have access to the other stuff on the site)
SharePoint makes the following very hard:
sharing specific libraries with distinct groups of people. This requires a lot of setup work and is a maintenance nightmare. You also need to be an administrator of the each site and know where in the depth of the SharePoint settings you can find the switch to break permissions and invite other people to a library.
It is not recommended practice to share libraries like that.
In your scenario, you would be served better with individual team sites using O365 groups. Then add members via the home page sharing button. The site should be the permission boundaries and these permissions should not be broken for any site content.
If the need arises to break permissions for certain content, it's time to move that content to a separate site with its own membership groups.
Using O365 groups, any site membership can then be viewed, managed and audited in the SharePoint admin portal and the M365 admin portal. No SharePoint knowledge or SharPoint site access is required for admins to manage membership. Membership assignment can also be automated with various tools like PowerShell or Power Automate.
Users can see only the sites they have access to, and will not suffer the bad user experience of clicking a library, only to get an error message for "You do not have access".
Is it possible, in SharePoint 2010 Foundation to find out when a user was added to a particular user group? I have full admin privileges as a site owner. I can find this information out through Audit Log reports but unfortunately I did not turn these on from day one so am looking for another method. I assume that SharePoint must be storing this information somewhere.
You can achieve this using Powershell, use the repadmin command. Like below
repadmin /showobjmeta dc1 'CN=Domain Admins,CN=Users,DC=rivendell,DC=com'
For more detail check this post
I am looking to set up a new security group called Head Company which will include existing security groups on my SharePoint like Child Company 1, Child Company 2 etc. This is to allow say the Company Group CEO manager access to all the Companies the Head Company owns.
Unfortunately SharePoint does not seem to allow it ?
Error: SharePoint Groups cannot contain other SharePoint Groups. Remove the SharePoint Group from the Users box and try again.
Is this something you guys have done on SharePoint, or something perhaps you have been able to work round?
This problem messes up my master plan in terms of how I was going to set this up ! Double drat !
SHAREPOINT 2010
If you could switch to using AD groups then you can put AD groups within each other however this also has drawbacks trying to manage it all.
A restructure may be time consuming but would make it easier to manage in the future. And i am sure you can move sites within subsite fairly easily now Check this out
http://movesites.codeplex.com/
Can i program custom base permission level? There are many available in SPBasePermissions like
UseRemoteAPIs Use SOAP, WebDAV, or Microsoft Office SharePoint Designer 2007 interfaces to access the Web site.
ViewFormPages View forms, views, and application pages, and enumerate lists.
ViewListItems View items in lists, documents in document libraries, and view Web discussion comments.
However i want to make a custom one, something like:
EditItemsAssignedToMe + ViewItemsAssignedToMe + view/edit items i created.
Still finding my way out to allow users view and edit items created by them or assigned to them.
OOTB you don't have the fine-grained control and can only assign a certain set of permissions as defined on technet and this blog article.
However programmatically you can create a new SPRoleDefinition and assign it the appropriate permissions based on the SPBasePermissions enumeration as per this blog article. You might also want to read this short guide on the basics of SPBasePermissions.
If you want to go even further though and emulate the OOTB behaviour with your own custom permission set try Implementing Custom Security Rights in SharePoint.