Hopefully this is a short term workaround. If you watched my SharePoint Power Hour today, you may have noticed that I was surprised when the DataSourceInfo function did not give me accurate permission information about the currently logged in user’s access to a certain list in SharePoint.
I did demonstrate a couple of other things, like how to determine if the currently logged in user is a member of a certain Office 365 group, or if they are a member of a certain group in Azure Active Directory. But I was still frustrated about not being able to tell if the currently logged in user has read versus write or anything about what they can do in the given SharePoint list.
Here is a workaround that I just figured out. First of all, you need to turn on the new, experimental feature called “Formula-level error management” in the app’s advanced settings.
Basically, the concept is that I’ve created a dummy, test list, and when the app opens, it immediately tries to patch a new item to that list. If there is an error, that’s how you can determine if the logged in user has edit permissions in that list or not. So, you’ll have to create an extra list in your site, with the same permissions as the main list that you are using in your app, so that it mimics the permissions the person would have normally in that app. Add that list as a data connection in your app.
I tried out this new IfError function, and it turns out that it does let you take a different action depending on if there’s an error or not, which is good, but it also still shows an error at the top of the screen. I want to set a variable called varReadOnly to true if the person doesn’t have access to edit the list. That way, I can use that variable in many places in my app, to hide and show the right things depending on whether they can edit or not.
Here’s the solution. My test list is called Test. Since the error still shows with the IfError function, I decided to just cover it up with a Notify.
Notify(“Welcome to our app“,NotificationType.Information); Set(varCanEdit,false)
Then, anywhere in the app where you want to do logic based on the user’s permission, you can use the variable. In this example, I have a button that takes me to a form to add new items to the list. I don’t even want people to see that button if they don’t have permissions to add things in SharePoint, so:
I set the visible property to be the value of the variable. So if varCanEdit is true, that means the person can edit the item.
Here’s the video from today’s Power Hour:
PowerApps IfError function reference